Individual AI tools are useful. Wired together, they become infrastructure.
Why This Module Matters
The previous modules covered individual tools and skills. This module is about the plumbing — the protocols, runtimes, and automation platforms that connect AI to your actual data, your actual tools, and your actual workflows.
Three technologies form the connective tissue of a personal AI stack:
- MCP (Model Context Protocol) — How AI talks to your tools
- Local LLMs (Ollama) — Running AI on your own hardware
- n8n — Automating multi-step workflows with AI nodes
Each serves a different purpose. Together, they let you build a personal AI infrastructure that’s far more capable than any single tool.
MCP — The Universal Adapter
What It Is
MCP is an open standard that defines how AI applications connect to external tools and data sources. Before MCP, every AI tool had to build custom integrations for every data source — Claude needs its own GitHub connector, its own database connector, its own filesystem connector. With MCP, a single standard interface works across any AI application that supports the protocol.
People call it “USB-C for AI,” and the analogy holds: one connector, many devices. Before USB-C, every gadget had its own cable. MCP is the standardized plug that lets any AI talk to any tool.
Why You Should Care
Without MCP, getting data into an AI conversation means copy-pasting. You open your database, run a query, copy the results, paste them into Claude, and ask your question. Repeat for every data source, every question, every session.
With MCP, Claude can reach into your data sources directly. “What were my top 5 clients last quarter?” and Claude queries your database through MCP, gets the answer, and responds. No copy-pasting. No context lost in translation.
Architecture
┌──────────────────────────────────────┐
│ AI APPLICATION │
│ (Claude Desktop, Claude Code, │
│ Cursor, or any MCP client) │
└─────────────┬────────────────────────┘
│ MCP Protocol
▼
┌──────────────────────────────────────┐
│ MCP SERVER │
│ (Translates between AI and tool) │
└─────────────┬────────────────────────┘
│ Native API/Protocol
▼
┌──────────────────────────────────────┐
│ EXTERNAL TOOL │
│ (Database, GitHub, Filesystem, │
│ Slack, Google Drive, etc.) │
└──────────────────────────────────────┘
MCP Client: The AI application you’re using. Claude Desktop, Claude Code, and Cursor all support MCP natively.
MCP Server: A small program that translates between the MCP protocol and a specific tool. One server for GitHub, one for Postgres, one for your filesystem, etc.
External Tool: Whatever you’re connecting to — a database, an API, a service.
What MCP Servers Provide
Each MCP server can expose three types of capabilities:
Resources — Read-only data the AI can access. File contents, database query results, API responses. “Read the contents of report.csv” or “Get the latest 10 issues from the GitHub repo.”
Tools — Actions the AI can execute. Create a GitHub issue, send an email, run a database query, write a file. “Create a new branch called feature/invoicing” or “Insert this row into the clients table.”
Prompts — Reusable instruction templates. Less commonly used in personal setups, but useful for standardizing how the AI interacts with specific tools.
Getting Started with MCP
Step 1: Identify what you want to connect.
Start with one or two integrations that would save you the most copy-paste time. Common first choices:
- Your filesystem (so Claude can read/write your project files directly)
- A database (so Claude can query your data)
- GitHub (so Claude can manage issues, PRs, and repos)
Step 2: Find or install the MCP server.
The MCP ecosystem has exploded — directory sites like PulseMCP and Glama now list over 10,000 servers as of March 2026. The most useful for personal setups:
| Server | What It Connects | Typical Use |
|---|---|---|
@modelcontextprotocol/server-filesystem | Local files | Read/write files without copy-pasting |
@modelcontextprotocol/server-postgres | PostgreSQL | Query databases conversationally |
@modelcontextprotocol/server-sqlite | SQLite | Query local databases |
@modelcontextprotocol/server-github | GitHub API | Manage repos, issues, PRs |
@modelcontextprotocol/server-slack | Slack | Search and read Slack messages |
@modelcontextprotocol/server-google-drive | Google Drive | Access Drive files |
For discovering more servers, browse PulseMCP or Glama — both maintain searchable directories.
Step 3: Configure in Claude Code.
Add MCP servers to your Claude Code configuration:
claude mcp add filesystem -s user -- npx @modelcontextprotocol/server-filesystem /path/to/your/projects
Or in Claude Desktop, edit the config file to add server definitions.
Step 4: Test.
After adding a server, verify it works by asking Claude to use it: “List the files in my projects directory” (filesystem) or “Show me the most recent issues in my repo” (GitHub).
What I’ve found most useful in practice: the filesystem and GitHub servers earn their keep immediately. The database servers (SQLite, Postgres) become essential once you’ve built something like the data dashboard from Module 07. Slack and Google Drive are nice-to-haves — valuable if you live in those tools, skippable if you don’t.
Building a Custom MCP Server
If you need to connect something that doesn’t have a pre-built server, building one is straightforward with the Python or TypeScript SDK. A minimal MCP server is ~50 lines of code. The pattern:
- Define what tools/resources your server exposes
- Implement the handler functions (what happens when the AI calls each tool)
- Register the server with your MCP client
This is a natural Claude Code project — you can have Claude write the MCP server for you based on your API’s documentation. Remember the spec-driven workflow from Module 03? A good spec for an MCP server practically writes itself: “Here are the endpoints, here’s the auth, here are the tools I want exposed.”
Security Notes
MCP servers have access to your real data and real tools. A filesystem server can read your files. A database server can run queries. A GitHub server can modify your repos.
Treat MCP server configuration like you’d treat SSH keys: be deliberate about what you connect, limit access to what’s needed, and review what each server can do before enabling it. The filesystem server, for example, should be pointed at specific directories, not your entire home folder.
MCP is evolving fast. The 2026 roadmap includes Streamable HTTP transport (enabling remote MCP servers, not just local processes), .well-known discoverability (so servers can advertise their capabilities), and formal governance through Working Groups. For personal use, none of this changes what you need to know today — but if you’re building MCP servers for others, keep an eye on the spec.
Local LLMs with Ollama
What It Is
Ollama lets you run open-source AI models on your own hardware. No cloud, no API costs, no data leaving your machine. You download a model, run it locally, and interact with it via command line or API.
When Local Beats Cloud
Local LLMs don’t replace Claude or GPT for hard problems. They complement them for specific use cases:
Privacy-sensitive tasks: Processing client contracts, financial documents, medical records, or anything you don’t want sent to a third-party server. Local processing means your data never leaves your machine.
High-volume batch tasks: Summarizing 500 emails, extracting data from 200 invoices, classifying 1000 support tickets. At scale, per-token API costs add up. Local processing has zero marginal cost after the initial hardware investment.
Offline work: Flights, remote locations, unreliable internet. A local model works regardless of connectivity.
Experimentation: Testing prompts, building prototypes, debugging workflows. No cost per request means you can iterate freely.
When Cloud Beats Local
Complex reasoning: Frontier models (Claude Opus, GPT-4) significantly outperform any model you can run locally on reasoning-intensive tasks — multi-step logic, nuanced analysis, complex code generation.
Large context windows: Cloud models handle 100K+ token contexts. Local models typically handle 4K-128K tokens depending on the model and your hardware, though longer contexts need more RAM.
Speed on large inputs: Cloud models are optimized for throughput. A local model on consumer hardware is slower, sometimes significantly so.
Setup
Step 1: Install Ollama
# macOS
brew install ollama
# Linux
curl -fsSL https://ollama.com/install.sh | sh
# Windows
# Download from ollama.com
Step 2: Pull a model
# General purpose + code (best sub-8B model)
ollama pull qwen3:7b
# Reasoning/thinking model
ollama pull deepseek-r1
# Multimodal (reads images, charts, screenshots)
ollama pull llama3.2-vision
# Ultra-lightweight (good for laptops)
ollama pull phi4-mini
# Larger, more capable (needs 16GB+ RAM)
ollama pull llama3.1:70b
Step 3: Use it
# Interactive chat
ollama run llama3.2
# Or via API (OpenAI-compatible)
curl http://localhost:11434/v1/chat/completions \
-d '{"model": "llama3.2", "messages": [{"role": "user", "content": "Summarize this document..."}]}'
Model Selection Guide
| Model | Size | RAM Needed | Good For | Not For |
|---|---|---|---|---|
| Qwen 3 7B | 4GB | 8GB | Code generation (leads HumanEval benchmarks), general purpose | Very long context, multi-step reasoning |
| Llama 3.2 8B | 5GB | 8GB | General purpose, good quality/speed ratio | Complex multi-step logic |
| DeepSeek-R1 | 4-8GB | 8-16GB | Step-by-step reasoning (“thinking” model), math, analysis | Quick responses (it thinks before answering) |
| Llama 3.2 Vision | 5GB | 8GB | OCR, chart reading, UI screenshots — multimodal | Text-only tasks (overkill) |
| Phi-4-mini | 2GB | 4GB | Edge devices, very fast responses | Anything requiring depth |
| Llama 3.1 70B | 40GB | 48GB+ | Near-cloud quality on many tasks | Most consumer hardware can’t run it |
For most personal use cases, Qwen 3 7B is the new sweet spot — it leads benchmarks for code tasks and handles general work well on 8GB of RAM. DeepSeek-R1 is worth pulling if you want a model that reasons step-by-step before answering (useful for analysis and math). Llama 3.2 Vision is the first genuinely useful multimodal local model — it can read screenshots, charts, and scanned documents. For quantization, Q5_K_M is the sweet spot between quality and size.
Practical Integration
Ollama exposes an OpenAI-compatible API at localhost:11434. This means any tool that speaks the OpenAI API format can use your local model — including n8n (next section), many MCP servers, and custom scripts.
The pattern for personal automation: use Ollama for high-volume, privacy-sensitive, or routine tasks. Use Claude for complex reasoning, coding, and analysis. Route each task to the appropriate model based on its requirements.
n8n — Workflow Automation
What It Is
n8n is an open-source workflow automation platform. It provides a visual canvas where you connect “nodes” — each node represents a trigger, an action, or a transformation — to build automated pipelines.
Think of it as “if this, then that” for grown-ups. Where IFTTT connects simple triggers to simple actions, n8n handles multi-step workflows with branching logic, data transformation, error handling, and — critically — AI nodes that process data through language models.
n8n raised a $55M Series B and launched n8n 2.0 in January 2026 with significantly upgraded AI capabilities — including agentic workflow support with Tool Nodes, persistent memory across workflow runs, and native LangChain integration (~70 AI-dedicated nodes). It’s no longer a scrappy open-source alternative; it’s a serious platform.
Why It Matters for Your AI Stack
n8n is the orchestration layer. It turns individual AI capabilities into automated workflows:
- Email arrives → n8n triggers → AI summarizes it → summary posted to Slack
- New invoice created in accounting tool → n8n triggers → AI extracts key data → dashboard updated
- RSS feed of industry news → n8n triggers → AI filters and summarizes → weekly digest emailed to you
- Customer submits form → n8n triggers → AI generates response → you review and send
Without n8n (or similar), you’re running each of these by hand. With it, they happen while you sleep.
Getting Started
Option 1: n8n Cloud (Fastest start)
Sign up at n8n.io. Free tier available; Starter plan at €24/month (2,500 executions), Pro at €60/month (10,000 executions). You get a hosted instance ready to use immediately. No installation, no server management.
Option 2: Self-hosted via Docker (More control)
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n
Open http://localhost:5678 in your browser. You have a running n8n instance.
Building Your First AI Workflow
Here’s a concrete example: an email digest workflow.
What it does: Every morning at 8am, it reads your last 24 hours of email, uses AI to summarize the important ones, and sends you a Telegram (or Slack, or email) digest.
The nodes:
[Schedule Trigger: 8am daily]
│
▼
[Email Node: Fetch last 24h of email via IMAP]
│
▼
[AI Node: "Summarize these emails. Flag anything urgent.
Group by: urgent, requires response, FYI only."]
│
▼
[Telegram Node: Send summary to your bot]
Step by step in n8n:
Add a Schedule Trigger node. Set it to fire daily at 8:00 AM.
Add an Email Trigger (IMAP) node. Configure with your email server credentials. Set to fetch messages from the last 24 hours.
Add an AI Agent node. Connect it to your AI provider (Anthropic for Claude, OpenAI for GPT, or your local Ollama instance). The prompt:
You are an email triage assistant. For each email below, provide: - Subject line - Sender - Category: URGENT, NEEDS_RESPONSE, or FYI - One-sentence summary Group the results by category. Put URGENT first. Emails: {{ $json.emails }}Add a Telegram node (or Slack, or email). Configure it to send the AI’s output to your preferred channel.
Test and activate. Run it manually first to verify the output looks right. Then activate the schedule.
Advanced Patterns
Branching based on AI classification:
[Incoming customer message]
│
▼
[AI Node: Classify as "question", "complaint", "praise", or "spam"]
│
├── question → [AI Draft Response] → [Review Queue]
├── complaint → [Alert to Slack] → [Priority Queue]
├── praise → [Log to CRM] → [Thank you template]
└── spam → [Archive]
Data enrichment pipeline:
[New CRM entry]
│
▼
[Web Search Node: Find company info]
│
▼
[AI Node: Extract industry, size, key products from search results]
│
▼
[CRM Update Node: Enrich the record]
Content repurposing pipeline:
[New Blog Post Published (webhook)]
│
▼
[AI Node: Generate 3 social media versions (LinkedIn, Twitter, Newsletter)]
│
├── [Buffer Node: Schedule LinkedIn post]
├── [Buffer Node: Schedule Twitter post]
└── [Email Node: Add to newsletter draft]
Connecting n8n to Your AI Stack
n8n has native support for:
- Anthropic (Claude) — direct API node
- OpenAI (GPT) — direct API node
- Ollama — via the OpenAI-compatible node (point it at
localhost:11434) - Custom MCP servers — via HTTP request nodes
This means your n8n workflows can route tasks to the right model: Claude for complex reasoning, Ollama for high-volume batch processing, GPT for anything where you want a different perspective.
The competitive landscape is worth knowing: Zapier launched Central (autonomous AI agents), Make added AI scenarios with prompt engineering interfaces, and CodeWords lets you build automations via natural language. n8n’s advantage remains self-hosting, price, and the depth of its AI node library — but the category is heating up.
Putting It All Together: Your Personal AI Stack
Here’s how these three technologies layer:
┌─────────────────────────────────────────────────┐
│ YOU (Human) │
│ Ask questions, review outputs, make decisions │
└────────────────┬────────────────────────────────┘
│
┌───────────┼───────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌──────────┐
│ Claude │ │ Ollama │ │ n8n │
│ (Cloud) │ │ (Local) │ │ (Automn) │
│ │ │ │ │ │
│ Complex │ │ Batch │ │ Triggers │
│ reason- │ │ process │ │ Routes │
│ ing │ │ Private │ │ Chains │
│ │ │ data │ │ actions │
└────┬────┘ └────┬────┘ └────┬─────┘
│ │ │
└───────────┼──────────────┘
│
▼ (MCP Protocol)
┌───────────────────────┐
│ YOUR DATA & TOOLS │
│ Files, DBs, APIs, │
│ GitHub, Slack, etc. │
└───────────────────────┘
MCP is the connective protocol — it lets any AI talk to any tool through a standard interface.
Ollama handles tasks where privacy matters or volume makes cloud costs impractical.
n8n automates multi-step workflows, routing tasks to the right AI model and connecting results to your tools.
Claude (or another cloud model) handles the hard thinking — complex reasoning, nuanced analysis, and sophisticated code generation.
You don’t need all of this on day one. Start with one piece: MCP to connect Claude to your filesystem, or n8n to automate one repetitive workflow, or Ollama to process private data locally. Add the next piece when the first one makes you wish for it.
Further Reading
| Resource | Why You’d Read It |
|---|---|
| MCP Official Site | The authoritative spec and documentation |
| How to Use MCP with Claude (Codecademy) | Hands-on tutorial with real examples |
| MCP in Claude Code: Practical Setup (wmedia) | Developer-focused setup guide for 2026 |
| DataCamp: MCP Guide with Demo Project | Build a working MCP integration from scratch |
| Ollama for Business (Arsturn) | Practical business use cases for local LLMs |
| Self-Hosted AI Models Guide 2026 (PremAI) | Comprehensive local LLM hosting guide |
| n8n: Build an AI Workflow (Official) | Official step-by-step for your first AI workflow |
| n8n Workflow Automation 2026 Guide (Medium) | Comprehensive patterns and real-world examples |
| n8n Beginner’s Guide (Passionfruit) | Absolute beginner walkthrough |
Previous: Module 07 — Data Engineering Mindset | Next: Module 09 — Project Lab