Learn · Model Context Protocol
MCP, answered plainly
A small library of genuinely good explainers about the Model Context Protocol. Each starts with a question and a direct answer, then goes deep — written to be useful to a person and legible to an answer engine.
- What is MCP? Tools vs prompts vs resources MCP (the Model Context Protocol) is an open standard that lets an AI agent connect to external servers and use what they expose. A server can expose three core primitives: tools (functions the model calls), prompts (templates a person selects), and resources (readable content the app loads). The difference is who's in control — the model, the user, or the application.
- What can an MCP server see about you? Surprisingly little. An MCP server can see its own tools, prompts, and resources, the protocol version it negotiated, the transport, and per-request arguments — plus whatever the host chose to surface at initialize (like the client's name). It cannot see your other connected servers, their tools, your model's identity, your context window, your working directory, or your active skills. That panoramic view belongs only to you, the agent.
- Tool annotations explained — and why so few tools declare them MCP tool annotations are optional hints on a tool definition — readOnlyHint, destructiveHint, idempotentHint, openWorldHint, and a human title — that tell a host how a tool behaves before it's called, so the host can auto-approve a read but confirm a write. Very few tools in the wild declare any of them, which means a tool that writes durable data can look, on the wire, identical to one that only reads.
- Elicitation, sampling, and roots: MCP's server→client capabilities Most MCP primitives flow from client to server, but three flow the other way. Elicitation lets a server pause a tool call to ask the user for input. Sampling lets a server ask the client's model to generate text. Roots let the client advertise its workspace folders to the server. All three require an interactive, stateful session and are advertised by the client at initialize — a stateless HTTP server cannot use them.
- Stateless vs stateful MCP transports (what each can and cannot do) A stateful MCP transport keeps a session alive across messages, so the server can hold context, push notifications, and do mid-call back-and-forth like elicitation, sampling, and roots. A stateless transport treats every request independently — it's simpler and scales trivially, but it can only report those interactive capabilities, never use them. If you want an interactive MCP server, statefulness is a gate, not an option.
- How big is your context window — and what do 178 tool definitions cost? Your context window is the total number of tokens your model can hold at once — often 200K for a current frontier model. Every connected tool spends part of it before you type a word: each tool's name, description, and input schema are serialized into the model's context. A heavily-connected agent with ~178 tools can burn roughly 30–45K tokens — 15–25% of a 200K window — purely on tool definitions.
- MCP protocol versions and capability negotiation MCP is date-versioned as YYYY-MM-DD. At initialize, client and server negotiate the highest revision both support, and the server echoes the agreed version back. Alongside the version, each side advertises its capabilities — the server its tools/prompts/resources, the client its sampling/elicitation/roots — and each side uses only what the other declared. Notable revisions include 2024-11-05, 2025-03-26, and 2025-06-18.
- What is an MCP App (ui:// / SEP-1865)? An MCP App is a small, self-contained HTML interface a server ships alongside a tool so its result renders as a real UI — a rectangle in the host — instead of plain text. The server publishes the interface as a ui:// resource and links a tool to it via _meta, and the host renders it in a locked-down iframe. It's the proposal tracked as SEP-1865, and the security model is the interesting part: the iframe makes no external requests.
- Is my agent environment safe? Reading an introspection report An introspection report is a snapshot of everything your agent can see — servers, tools, capabilities, context cost — read for the things that carry risk. The three highest-signal checks: shadow writes (tools that can change state but declare no destructive hint), name collisions (two servers exposing the same tool name), and tool-poisoning (injection-style text hidden in a tool's description). None alone means "unsafe," but together they tell you how much of your setup is trustworthy by evidence rather than by assumption.
Machine-readable index: llms.txt · llms-full.txt · RSS feed