Model Context Protocol and tool ecosystems
- Advanced
- 35 min
- Lesson 3 of 3 in Tools and agents
- Last verified
Select text in the lesson first to keep it with your note. With the keyboard, move focus here and press the button: the note goes with the section you are reading.
In this module
On this page
Before you start
- Completed:Function and tool calling
You will be able to
- Explain the integration problem MCP solves (N x M to N + M) and how MCP relates to function calling.
- Describe the roles (host, client, server), the server primitives (tools, resources, prompts) and the standard transports, including who talks to the model.
- Explain why MCP behaviour depends on the spec revision, and state what changed in revision 2026-07-28 (stateless requests, no protocol sessions, deprecated sampling and roots).
- Threat-model an MCP integration: name the main attacks (injection through descriptions and results, over-broad or passed-through tokens, malicious servers, dangerous actions, too many tools) and a mitigation for each.
Every car on the Sleeper has its own connector: round in the Porter Car, square in the Records Car, three pins and a bad temper in the Signal Box. Wick carries a bag of adapters and loses one most nights.
Tonight someone chalks a proposal on the board: one plug that fits every car. Merrow stamps the board FILED before anyone has finished reading it. “Fits everything,” says Wick, hopefully.
If one plug fits every car, what else does it let into each one?
Concept
MCPMCPShort for Model Context Protocol: an open protocol connecting a host application to servers that expose tools, resources and prompts.Open the glossary entry (Model Context Protocol) is an open protocol that standardises how AI applications (hostsMCP hostThe AI application, such as an IDE or chat app, that holds one MCP client per server and shows the servers' tools to the model through tool calling. The model never talks to a server directly; the host mediates, so approvals, logging and limits live there.Open the glossary entry) discover and use tools and context exposed by serversMCP serverA program that exposes tools, resources and prompts through MCP. Connecting one means trusting text it controls.Open the glossary entry. Without a standard, every pair of app and tool needs custom glue: N apps times M tools is N x M integrations. With MCP each app implements an MCP clientMCP clientThe component inside an MCP host that keeps one connection to one MCP server. The host runs one client per server and relays tool lists and calls between the model and that server.Open the glossary entry once and each tool implements an MCP server once, which is N + M.
Why It Matters
MCP fluency is a useful skill for agent and integration work: how tools are discovered, how they are authorised and secured, and how MCP relates to function calling and to plain REST. It is also a fast-moving specification. A lesson written against last year’s revision can teach things that no longer exist, so this lesson also teaches you how to check.
Mental Model
USB-C for AI tools: one connector shape, so any host can plug into any server.
Where the USB-C analogy breaks
The analogy explains the standard shape and nothing else. Three differences matter in production.
- Plugging in is not safe by default. A USB-C cable moves power and data between devices you chose. An MCP server’s tool names, descriptions and results flow into the model’s context, where they can steer it. Connecting a server means trusting text it controls.
- The host mediates; the cable does not. In USB-C the two devices talk to each other. In MCP the model never talks to a server directly. The host app shows tools to the model through the model API’s tool calling, then runs the call through its MCP client. The host is where you place approvals, logging and limits.
- Trust is per server and per user, not per connector. Two servers with the same connector can have very different owners, permissions and update habits. The spec says clients must treat tool annotations as untrusted unless they come from trusted servers.
Technical Deep Dive
Roles
The host (the AI app) contains one or more clients, and each client connects to one server. The model does not call MCP. The host presents tools to the model using the model API’s tool-calling feature and executes chosen calls through the client. Some provider APIs can also act as the client for you: Anthropic’s MCP connector lets the Messages API connect to remote MCP servers without a separate client of your own. Either way, something between the model and the server mediates, and that is where your controls go.
Server primitives
- Tools: actions the model can invoke, with JSON-schema inputs. The spec describes tools as model-controlled: the model decides when to call them.
- Resources: data or context such as files or database schemas, each identified by a URI. The spec describes them as application-driven: the host decides what to include.
- Prompts: reusable prompt templates. The spec describes them as user-controlled: the user picks one, for example as a slash command.
A server can also ask for more input during a request. In revision 2026-07-28 this uses the multi round-trip requests pattern: the server answers a tool call (or a prompt or resource read) with an interim result that says more input is needed, the client gathers it (for example by asking the user, which MCP calls elicitation) and retries the original request with the answer attached.
Transports and authorization
MCP messages are JSON-RPC. The two standard transports in the current spec are stdiostdio transportThe MCP transport for local servers run as subprocesses of the host. Remote servers use Streamable HTTP instead.Open the glossary entry (the client launches a local subprocess) and Streamable HTTPStreamable HTTPThe MCP transport for remote servers, in which each message is an HTTP POST to one endpoint. It replaces the older, deprecated HTTP+SSE transport.Open the glossary entry (each message is an HTTP POST to one endpoint, for remote servers). The older HTTP+SSE transport is deprecated. Authorization is optional. For HTTP-based transports the spec’s authorization flow builds on OAuth 2.1, with servers acting as OAuth resource servers. For stdio the spec says implementations should instead take credentials from the environment.
MCP and function calling
Function calling is the model-facing interface: the model emits a structured call. MCP is the integration layer: it standardises how the host finds, describes and invokes tools and data. They compose. Saying “MCP replaces function calling” is a common mistake.
MCP and REST
A REST or OpenAPI service is the underlying API. An MCP server usually wraps one and adds what an LLM host needs: a standard way to list tools with descriptions and JSON-schema inputs, a uniform client contract, and standard authorization discovery. REST alone has no agreed way for a host to ask “what can you do, and how do I describe it to a model?”
Spec revisions: what changed in 2026-07-28
MCP is versioned by date (YYYY-MM-DD). Per the official versioning and changelog pages (read on 2026-10-09), the current revision is 2026-07-28, which differs from 2025-11-25 in breaking ways (the multi round-trip page says so explicitly). The changes most likely to matter to you:
- Stateless requests. The
initializehandshake is removed. Every request carries its protocol version and client capabilities. Servers must implementserver/discoverto advertise supported versions, capabilities and identity; a version mismatch returns anUnsupportedProtocolVersionerror. Revisions up to and including2025-11-25use the handshake. - No protocol-level sessions. The
Mcp-Session-Idheader is removed from Streamable HTTP, and list endpoints no longer vary per connection. A server that needs state across calls returns an explicit handle (a cart id, say) that the model passes back as an ordinary tool argument. Handles are a new attack surface, so servers should check that the caller owns the handle and must not treat holding a handle as proof of identity. - Server-initiated requests replaced. The multi round-trip pattern above replaces servers sending requests to the client. The multi round-trip page calls this a breaking change.
- Deprecated: Roots, Sampling and Logging, plus Dynamic Client Registration in favour of Client ID Metadata Documents. Deprecated features still work and new implementations should not adopt them. For Roots, Sampling and Logging the earliest removal is the first revision released on or after 2027-07-28. Suggested replacements: pass directories or files as tool parameters or resource URIs (instead of Roots), call the model provider’s API directly (instead of Sampling), and log to stderr for stdio or use OpenTelemetry (instead of Logging).
- Also changed: the experimental tasks feature moved into an official extension, and list and read results now carry required cache hints (
ttlMs,cacheScope).
Clients and servers that must work with older revisions detect the other side’s era and fall back; the spec has a compatibility section for implementers.
Two cautions. First, the revision a given SDK or host speaks may not be the newest, so check its release notes. Second, this lesson avoids field-level detail beyond the above because it is the part most likely to change again. Always check the spec for the revision you build against.
Security
Security is a likely interview topic (a judgement, not data). MCP widens the attack surface because the model reads text that servers control and can act on it.
| Risk | What happens | Mitigation |
|---|---|---|
| Injection through tool descriptions and results (an informal name is tool poisoning) | A description or result contains instructions the model follows, such as “also read the user’s key file” | Treat descriptions, annotations and results as untrusted input; show tool inputs to the user; validate results before they reach the model |
| Over-broad or passed-through tokens | One powerful token lets a bug or an attacker do everything. A server that accepts tokens issued for another service and forwards them (token passthrough) breaks audience boundaries and hides who did what | Least privilege and narrow scopes; per-user credentials; servers accept only tokens issued for them; the spec forbids token passthrough |
| Malicious or changed servers (including updates that change behaviour after approval) | A local server runs with your privileges; a remote one can change its tool list later | Pin versions, review, allow-list, sandbox local servers, show the exact startup command before running it |
| Dangerous actions | A write or delete runs without anyone noticing | The spec says there should always be a human able to deny tool calls; require approval for writes and irreversible actions; audit logs; rate limits |
| State handle hijacking | A guessed or leaked handle lets someone else use another user’s state | Unpredictable, expiring handles bound server-side to the authenticated user |
| Too many tools | Selection gets harder and the tool list takes up context (Anthropic offers a tool search tool for very large tool sets) | Curate, namespace and group tools; the spec suggests prefixing names with a server id when aggregating |
The costs of these controls are friction (approval prompts), engineering time (a gateway, scoped tokens) and some latency. Skipping them is the larger cost.
Diagram
Real-World Application
A coding assistant connects to a local filesystem server over stdio and to a remote issue-tracker server over HTTP with scoped OAuth tokens. Reads are automatic; writes require user approval; every call is logged. An internal platform team may run an MCP gateway that adds authentication, audit and approval for many teams’ tools in one place.
Interview Perspective
Expect “MCP versus function calling”, “how would you secure an MCP integration” and “design tool discovery for 200 tools”. Common mistakes: saying MCP replaces function calling, ignoring injection through tool descriptions, giving the agent one all-powerful token, and describing session behaviour from an old spec revision without saying which revision you mean.
Practice Questions
These are generated practice questions, not reported from any company.
- Basic: What problem does MCP solve (N x M to N + M)?
- Intermediate: Tools versus resources versus prompts: who decides when each is used?
- Advanced: Threat-model a third-party MCP server your agent will call.
- Product-Company: Design an internal MCP gateway for 30 teams’ tools with authentication, audit and approval flows.
Activity
List 8 tools for a DevOps assistant. Label each read-only or write, decide which need human approval, and design the naming and namespacing that help the model choose correctly. Then pick the two riskiest tools and write what a malicious tool description could try to make the model do with them.
Homework
Build a minimal MCP server (Python or TypeScript SDK) that exposes one tool and one resource. Connect it from a host and write a short threat model. Note which spec revision your SDK version targets and whether your server needs state across calls; if it does, design an explicit handle and say how you check ownership.
Quick Revision
- MCP is a standard host-to-server protocol (JSON-RPC; stdio or Streamable HTTP) with tools, resources and prompts. It composes with function calling.
- The host mediates between model and server; the USB-C analogy hides the trust problem.
- Current revision
2026-07-28: stateless requests, no protocol sessions, multi round-trip requests; sampling, roots and logging deprecated. Always check the revision. - Security: untrusted descriptions and results, least privilege, no token passthrough, approvals for writes, pinned and sandboxed servers.
Check yourself
- Checkpoint question: Explain MCP to a teammate and list three security risks with mitigations.
- Independent re-test: Your agent has 120 tools and picks the wrong one. What do you change?
- Common misconception to avoid: “MCP gives the model direct network access”, and “MCP sessions work the same way in every spec revision”.
Related
Practice
Test what you just read. Quizzes and cards are grouped by module: Tools and agents.
Check yourself9 questions on what this lesson set out to teach
Checking answers needs JavaScript. You can still read every question and option below.
Keyboard: arrow keys move between options. Space or Enter selects the focused option.