MCP, plainly: what the Model Context Protocol actually standardizes

The Model Context Protocol has reached the stage where everyone references it and fewer people can say in one sentence what it does. Here is mine: MCP is a standard way for an AI application to discover and call capabilities that live somewhere else. That is the whole idea. Everything else is detail — useful detail, but detail.

The problem it solves

Before a shared protocol, connecting a model to a tool meant writing an integration for that model in that application. Five applications and twenty tools is a hundred integrations, each with its own schema format, its own auth handling, its own way of returning errors. Tools built for one assistant did not work in another.

MCP replaces the N×M mess with N+M. A tool is wrapped once as an MCP server; any application that speaks the protocol — an MCP host — can connect to it. The analogy people reach for is USB, and it is a fair one: the port is standardized so that the devices do not have to know about each other.

The pieces

Term	What it is	Example
Host	The application running the model and managing the conversation	A desktop assistant, an IDE, a custom agent runtime
Client	The host's connection to one server	One per server; handles the session
Server	A process that exposes capabilities over the protocol	A wrapper around your ticketing system, a database, a filesystem
Tool	A callable action with a JSON schema for its arguments	create_ticket(title, priority)
Resource	Readable data the host can fetch into context	A file, a record, a document by URI
Prompt	A reusable, parameterized instruction template the server offers	"Summarize this incident for the status page"

Under the hood it is JSON-RPC messages over a transport — a local process via standard input/output, or HTTP for remote servers. The host asks a server what it offers; the server answers with a list of tools, resources, and prompts, each with a schema; the host passes those to the model; when the model wants to call one, the host forwards the request and returns the result. That handshake is the protocol.

What it standardizes, and what it does not

It is worth being precise here, because most disappointment with MCP comes from expecting it to do things it never claimed to.

Standardized: how a host discovers capabilities, the shape of a tool definition, how a call and its result are exchanged, how resources are addressed, how a session is set up and torn down. If you build a server to the spec, compliant hosts can use it without custom code.

Not standardized: what the model decides to do with the tools, how good your tool descriptions are, how the host decides which calls need a human's approval, the business logic of authorization inside your server, or the quality of what comes back. The protocol moves bytes reliably. Whether the agent does the right thing with them is still your job — the same job it was before, with less plumbing.

Put another way: MCP makes integration cheap. It does not make it safe or correct. Those are design work.

Three pitfalls from production

1. Tool sprawl

Because connecting a server is easy, teams connect all of them, and the model ends up choosing from eighty tools on every turn. Selection quality drops; the model picks a plausible-sounding tool over the right one, or calls three when one would do. The fix is curation: expose the tools a task needs, not every tool you have. Hosts are starting to support introducing tools mid-conversation, which helps — give the model the search tools during research and the write tools during execution, not all of them all the time. Write tool descriptions the way you would write documentation for a new hire: what it does, when to use it, when not to.

2. Injected results

A tool result is text, and the model reads text as if it might be instructions. If a server returns a document, a web page, or a ticket body that a third party wrote, that content can try to steer the agent — "ignore your previous instructions and…" — and sometimes succeed. Treat every tool result as untrusted data. Separate it clearly from instructions in the context, strip or escape anything that looks like a directive, keep high-consequence actions behind approval regardless of what the model "decided", and log the result that preceded any surprising action. The permission policy I describe in Human-in-the-loop by design is the backstop here.

3. Over-broad scopes

The quickest way to wire a server is with a credential that can do everything. Then the agent can do everything, including the things nobody intended. Give each server the narrowest credential that covers its tools, split read and write into separate servers where the risk justifies it, and make the server — not the model — enforce the boundary. A model can be talked into trying something; a server with a read-only token cannot be talked into writing.

A production checklist for an MCP server

• Each tool does one thing, with a schema that rejects malformed arguments before any side effect.
• Descriptions say when to use the tool and when not to. The model only knows what you tell it.
• Idempotent where possible, and explicit about it. Agents retry.
• Narrow credentials, scoped per server; read and write separated when it matters.
• Structured errors. "Ticket 4821 not found" lets the model recover; a stack trace does not.
• Results marked as data, with anything directive-looking neutralized.
• Every call logged with arguments, result size, latency, and caller — the trace you will need the first time something goes wrong.
• Version pinned. The protocol evolves; your server's contract with its hosts should change deliberately.

Why it matters anyway

After all those caveats, I still think MCP is one of the more important things to have happened to applied AI, because it changes who can build the integration. Before, connecting a tool meant someone who understood both the model's API and the tool's. Now the tool's owner can publish a server once and be done, and every host picks it up. That is how ecosystems form. The pitfalls above are not reasons to avoid it; they are the shape of the work once the plumbing stops being the hard part.