Day 2 · Lesson 3 — Agent Tools & MCP
Build a tool once; let any model use it.
Lessons 1–2 were about a single tool. Now the scaling problem: connect many models to many tools without hand-building a connector for every pair. That's the exact problem the Model Context Protocol exists to solve, and knowing its shape tells you where governance can hook in later.
From Lesson 2: a good tool should encapsulate —
A single task. Hold that: an MCP server is just a standard way to publish a set of those task-tools so any model can discover and call them.
Integrating an LLM with an external tool has usually meant a custom, one-off connector for every pairing. Add models (N) and tools (M) and the number of connectors grows like N×M, the "N×M integration problem."1 Anthropic introduced MCP (November 2024) as an open standard to collapse that: build each tool once as an MCP server, and any MCP-speaking model can use it. The explosion becomes N+M.
WITHOUT a standard WITH MCP
N models × M tools N models ─┐
= a custom connector ├─ one protocol ─┤
for every pair M tools ─────────┘
(grows N×M) (each side speaks MCP once → N+M)It's the same move as USB for peripherals, or the Language Server Protocol for editors: standardise the interface, decouple the two sides, and let an ecosystem grow.1
MCP is a client–server model. Three components, each with a job worth memorising, because two of them are where security lives:1
| Component | What it is | Its job |
|---|---|---|
| Host | The AI application | Manages clients + UX, orchestrates tools, enforces security policy & guardrails |
| Client | A connector inside the Host | Holds one connection to one Server; manages the session |
| Server | An adapter/proxy for a tool, API, or data source | Advertises tools (discovery), executes calls, returns results; in enterprise, also security & governance |
Under the hood: JSON-RPC 2.0 messages
(requests · results · errors · notifications) over one of two transports:
stdio for a local subprocess, Streamable HTTP for remote.
MCP defines six primitives: server-side Tools, Resources, Prompts and client-side Sampling, Elicitation, Roots. But adoption is wildly lopsided:1
Tools ████████████████████ 99% ← the core driver of MCP value
Resources ███████ 34%
Prompts ██████ 32%
Sampling ██ 10%
Elicitation █ 4%
Roots █ 5%The practical lesson for a builder: build on Tools. Treat the other five as experimental. Some (Prompts, Elicitation) also carry security concerns the paper flags for later. Don't architect around a primitive almost no client supports.
An MCP server is just the harness's tools component (Day 1 L2), standardised and made shareable. But note what MCP does at runtime: to know which tools exist, the Host loads every server's tool definitions into the model's context window (L4). Connect many servers and that metadata balloons, the "context bloat" problem that's the headline of the next lesson.
Two roles are natural governance seats. The Host is defined to "enforce security policies and content guardrails," and the Server is where enterprise security and governance sit. A single point of enforcement is exactly what VERDICT's V Validation gates and E Evidence logging want. So MCP's shape provides the hooks for governance.
But the hooks are empty. The base protocol ships thin native security (no standard identity, authorization, or observability), so the enterprise must add them (the whole point of the next two lessons). Ladder read: a central, policy-enforcing Host/gateway that inventories every server and every tool is precisely the L1→L3 climb; the raw protocol alone leaves you at L1 Unseen.
Package a genuinely reusable tool as an MCP server rather than a one-off connector, and build on Tools rather than the barely-supported primitives. Know which Host your agent runs in, because that's who enforces policy.
Standardise on MCP for shared tools so the team stops re-writing connectors. The N+M win is a team win. Agree which servers are approved and where they're hosted.
Route MCP traffic through a central Host/gateway as the single enforcement point, the architectural seat for identity, allowlists, and audit. The protocol offers the choke point; the org has to staff it.
Recall, don't re-read.
MCP turns the N×M connector problem into —
N+M: each side speaks MCP once. Build a tool as a server and any MCP model uses it, instead of a custom connector per model–tool pair.
Which MCP component advertises and executes the tools?
The Server: it exposes a tool/API/data source, advertises tools for discovery, and runs the calls. The Host orchestrates and enforces policy; the Client holds one session to one Server.
Of MCP's six primitives, the one broadly supported in practice is —
Tools sit near 99% client support; Resources/Prompts ≈ a third; the client-side trio in single digits. Build on Tools; treat the rest as experimental.
For one integration you maintain as a custom connector, ask: would an MCP server let other agents reuse this without a rewrite? And whichever Host your agents use, is it actually enforcing any policy, or just passing calls through? The answer previews the next two lessons.
The MCP introduction and the architecture spec are the canonical references; the client-support table comes from modelcontextprotocol.io/clients.
Up next → Day 2 · Lesson 4: MCP For and Against. The honest trade-off: dynamic tool discovery and a reusable ecosystem on one side; context bloat and missing enterprise-grade auth, identity, and observability on the other.
Related: Glossary · ← Day 2 L2: Designing Tools · Day 1 L4: context · Course home