What the Model Context Protocol actually does

Every new protocol gets the same treatment in its first year: half the internet treats it as the answer to everything, the other half assumes it's just a rebrand of something they already use. MCP is going through that phase right now. Here's what it actually does, what it doesn't, and where it sits relative to the things it gets confused with.

The Model Context Protocol is a JSON-RPC-based wire protocol for letting language models talk to external systems through a uniform interface. That's the whole headline. The interesting part is which decisions the spec makes for you, and which it deliberately leaves on the table.

The four primitives

Most of what feels new about MCP is really just a clean separation of four things that production code usually conflates. Once the primitives stop sharing a namespace, a lot of architectural decisions write themselves.

Tools

A tool is a callable function exposed to the model. It has a name, a JSON-Schema input, and a structured response. This is the part that overlaps with OpenAI/Anthropic function calling — but unlike those, the contract is the wire, not the SDK. A tool defined on a Python server is identical in shape to a tool defined on a Rust one.

Resources

A resource is a piece of context the server can hand the model: a file, a database row, an API response, a screenshot. Resources are addressed by URI and can be subscribed to — the server pushes a notification when they change. Think of resources as the read side of MCP, where tools are the write side.

Prompts

Prompts are reusable templates the server publishes — typically wired to a slash command or quick action in the host. The server owns the prompt; the client just lists and invokes them. This keeps prompt engineering out of the client and close to the data it depends on.

Sampling

Sampling is the most under-appreciated primitive. It lets a server ask the client to run an LLM completion on its behalf. This is what makes agent-style servers possible without each server shipping its own model credentials. The host stays in control of which model is used, what it costs, and what the user has consented to.

What MCP isn't

MCP is regularly described as “the USB-C of AI”, which is catchy but misleading. A more honest comparison is HTTP: a thin transport contract that says nothing about what you put on top of it. The spec deliberately avoids opinions on identity, billing, rate limiting, retries, idempotency, or content moderation. Every one of those gets pushed to the layer that actually has the context to decide.

• MCP is not RAG. It doesn't index, embed, or rank anything. It just gives a server a way to surface resources by URI.
• MCP is not an agent framework. There's no planner, no memory, no loop. Those are host concerns.
• MCP is not function calling. Function calling is a model-vendor surface; MCP is a server-side protocol that happens to expose tools in a way function-calling models can consume.
• MCP is not a permissions model. It defines a handshake; what counts as 'permitted' is up to the host.

The wire, briefly

Every MCP exchange is a JSON-RPC 2.0 message. A client sends initialize, the server responds with its capabilities, and from that point both sides can issue requests and notifications. Tools are listed via tools/list and invoked via tools/call. Resources are listed via resources/list and read via resources/read. The shape is so small you can read the entire base spec in an afternoon.

The transport layer is also intentionally boring. Stdio for local processes — the host spawns the server as a subprocess and pipes JSON-RPC over stdin/stdout. HTTP for remote — server-sent events for the response stream, regular POST for everything else. No new framing, no exotic encoding, no brokered queues.

Why the boring decisions matter

It's tempting to read the spec and conclude that MCP isn't doing very much. That impression is the point. The protocol's value is interoperability — a server written today against the v1 spec will work against any compliant client for years, because the spec resists the urge to bake in answers to questions that aren't its business.

The places where MCP does take a strong position — JSON Schema for tool inputs, capability negotiation up front, structured rather than streamed responses by default — are the places where ambiguity would have made the ecosystem unworkable. Everywhere else it gets out of the way.