If you followed the last two videos, your Claude Code setup already knows your project (CLAUDE.md + rules) and has workflows it can point at (skills) with enforcement running outside the model (hooks). And yet — every time a task touches something outside the repo, you're back to being the middleman. Claude wants to check what's in Redis? You paste the CLI output. It needs the current Airtable records? Screenshot. Deploy status on Fly.io? You run fly status and copy the result back into chat.
Every paste is you doing I/O for a model that's perfectly capable of doing its own — and every one of those round-trips burns your Claude Pro usage on ferrying data instead of judgment.
That's what this final layer fixes. MCP servers give Claude direct contact with your tools. Agents give it delegation — scoped workers that carry their own context, their own tool access, their own rules. Connect once, delegate forever.
New to this series? Start with CLAUDE.md & Rules and then Skills & Hooks — everything below sits on top of those layers.
Quick recap: the stack so far
The project is still PortfolioPulse, my Go service that snapshots Trading212 portfolio data into Redis and Airtable. Two videos in, the layers look like this: CLAUDE.md and rules define what Claude knows, skills are workflows I point at instead of re-prompting, and hooks enforce lint, build and commit format deterministically, at zero token cost.
What's missing is reach. All of that operates on the code. PortfolioPulse in production is code plus an Upstash Redis cache, an Airtable base, and a Fly.io deployment — and until now, Claude could only see those through my copy-paste.
MCP: giving Claude hands
An MCP server is a standard way to hand Claude a tool with its own API access. The setup cost is one command per service — literally once. In the video I wire up three, each a slightly different flavor of the same flow:
Upstash (Redis) — straight from the terminal:
claude mcp add --scope <scope> upstash \
-- <email> <api-key>
You create the API key in the Upstash console, pass it once, done.
Fly.io — the CLI bootstraps it for you:
brew install flyctl
fly auth login # paste the code from the auth page
fly mcp # registers the MCP server
Airtable — I did this one differently, through Claude Desktop's connector/plugin system rather than the CLI. Same result: the model gets direct contact with the base — reading records, altering fields — no browser tab involved.
One caution, same spirit as the skills warning from last time: an MCP server runs with real credentials against your real data. Scope the API keys, prefer read-only where the service offers it, and know exactly what a server can touch before you add it.
The live test
To prove it's not just plumbing, I ask Claude to read the Airtable base — the records already filled in from the previous videos. It pulls them without me opening Airtable at all.
Then the write path: rename a column to "stock name," clean up fields I don't need. Watching the base update itself — a field I never touched, changed correctly, confirmed by a refresh — is the moment MCP clicks. This data used to be export-blocked screenshot material I'd feed to another model for analysis; now it's just… queryable.
Two honest observations from the demo, because they matter more than the happy path:
- Claude read the base through plain REST before even reaching for the MCP. Models are resourceful — MCP isn't always required for reads. What it standardizes is authenticated, structured, bidirectional access that doesn't depend on the model improvising an API call.
- The delete was refused. Rename worked, delete didn't — permissions drew the line. That's not a failure; that's exactly the boundary you want visible.
Agents: delegation with scope
MCP gives Claude hands. Agents decide which hands to use, for what — without you dispatching every move.
An agent in Claude Code is a markdown file in .claude/agents/: a name, a description of when it should be invoked, the tools it's allowed, and its own instructions. The main Claude session acts as the parent and routes to them. For PortfolioPulse, I create three, each with one delegated job:
ai-broker — read-only against the live Trading212 account. Tools: Bash, Read, Grep, Glob — nothing more. Its file pins down the credentials (HTTP Basic Auth from .env), the base URL, and one hard rule: the only endpoint you need is GET /equity/portfolio. The API key itself is scoped read-only — Portfolio/Account only, no Orders. Nothing that talks to a live brokerage account gets write access, at the agent level and the key level.
data-agent — owns the historical/cache layer: Airtable (permanent history) and Upstash Redis (hot cache), via the MCP servers from part one. Look at its tools list in the screenshot: alongside the basics it gets the specific Airtable MCP tools — list_tables_for_base, get_table_schema, create/update/delete_records — not blanket MCP access. Its file also spells out the base ID, table, and snake_case field names, so I never re-explain my own schema again.
deployment-agent — the Fly.io specialist for the PortfolioPulse app. It carries the deploy commands, the machine tooling, the tunnel checks, and nothing else.
The detail that makes routing actually work is in the description fields. Each one defines its job and deflects its siblings' jobs: ai-broker's description literally says "Do NOT use for historical/point-in-time questions — that's data-agent. Do NOT use for deployment questions — that's deployment-agent." The parent routes by reading these descriptions, so negative boundaries are as load-bearing as positive ones.
The pattern to notice: each agent is scoped to its own tools and its own MCP servers. The broker agent can't touch the deployment. The deployment agent has no path to the brokerage. Least privilege, but for delegation.
Read the files it writes
Claude generates these agent files, and it's tempting to accept them and move on. Don't. Read them through before you start building on top — the description field is what governs when the parent invokes each agent, and the instructions are your guardrails. Five minutes of moderation here beats debugging misrouted delegation later. (Case in point from the video: agents can also be told to invoke specific skills in a specific order — a connection I only caught, and tightened, because I read the generated file.)
This is also where the whole series composes into one loop: rules route to skills and agents, agents carry their own MCP access, hooks enforce the output. You can see it in data-agent's file: "follow the /airtable skill's tool-call order: search_bases → list_tables_for_base → get_table_schema → read/write." An agent invoking a skill, through an MCP server, under rules — all four layers in one line. I ask one question — "does Airtable match with Trading212 live right now?" — and the parent invokes the right agents on its own.
All three at once
The final demo fires all three agents from a single prompt. ai-broker reports positions and downside. deployment-agent checks the fly tunnel, notices Docker was altered, runs the status checks — nothing to deploy, guards confirmed. data-agent reconciles against Airtable.
Not flawless — the deployment check surfaced real issues, on camera — but that's the point. Three scoped workers found them in parallel while I watched, instead of me pasting outputs between terminals for half an hour.
The complete stack
Here's where the series lands after three videos:
| Layer | What it does | Cost profile |
|---|---|---|
| CLAUDE.md + Rules | What Claude knows | Loaded once per session |
| Skills | Workflows you point at | Loaded only when relevant |
| Hooks | Enforcement outside the model | Zero tokens |
| MCP servers | Direct access to your tools | Connect once |
| Agents | Scoped, parallel delegation | Invoked only when routed |
The mental model for this last layer: MCP replaces you as the data courier; agents replace you as the dispatcher. What's left for you is the part that was always the actual job — deciding what should be built, and reading what your tooling reports back.
I think this is the new way to run a project: set the layers up front, before writing any code, and then stop being infrastructure for your own AI.
The whole setup is in the repo:
https://github.com/Mozes721/PortfolioPulse
Watch the build end-to-end:
https://youtu.be/Ze-JEvDE_7E
Top comments (0)