Ask what MCP is and you will get an analogy. It is the USB-C port for AI. It is HTTP for agents. It is a universal adapter. Analogies are how people explain a thing's ambition, and the ambition is real, but you cannot make an architecture decision from an ambition. You make it from the thing itself, and the thing itself is small: a wire protocol built on JSON-RPC 2.0, a short list of message types, and three roles. You can read the interesting parts of the spec in an afternoon. This essay is the shorter version of that afternoon.

MCP, the Model Context Protocol, is an open standard that Anthropic released in November 2024 for connecting AI applications to external systems: databases, file systems, ticketing tools, search indexes, anything with an API. It has since been adopted far beyond Anthropic, by the other major model vendors and by a very large ecosystem of community servers. That adoption, not any technical novelty, is the actual story. The protocol is deliberately boring. Boring is what standards are for.

The Problem It Exists to Solve

Before MCP, every AI application that wanted to reach your calendar, your database, or your internal wiki wrote a custom integration, and every tool vendor who wanted to be reachable wrote one per assistant. M applications times N systems is M times N adapters, each with its own auth handling, its own error shapes, its own bugs. The industry has solved this exact shape of problem before, with ODBC for databases and the Language Server Protocol for editors, and MCP is a straight copy of the move: define one protocol, and M times N collapses to M plus N. Each application implements the client side once. Each system gets wrapped in a server once. Everything interoperates.

Notice what that framing implies, because it is the most useful sentence in this essay: MCP is an integration standard, not an AI technique. It makes no model smarter. It retrieves nothing by itself. It decides nothing about what your agent does. It standardizes the cabling, and cabling is valuable exactly in proportion to how many things you need to connect.

Three Parties, One Conversation

The spec names three roles. The host is the AI application the user actually touches: Claude, an IDE assistant, your internal support tool. The server is a program that wraps some capability and exposes it through the protocol. Between them sits the client, a connector object the host creates, one per server, that speaks the protocol on the host's behalf. The distinction between host and client sounds like pedantry until you build one: the host owns policy, permissions, and the model loop, while the client is just the socket. One host typically holds many clients, each talking to one server.

Transport is pleasingly primitive. A local server runs as a child process and talks over stdin and stdout. A remote server speaks HTTP. That is why an MCP server can be forty lines of code: there is no framework underneath, just messages in and messages out.

What Actually Crosses the Wire

A session opens with a handshake: the client sends an initialize request carrying the protocol version and what it supports, the server answers with its own capabilities, and from then on both sides know exactly what they are allowed to ask of each other. After that, almost everything a server offers falls into three primitives, and the differences between them are about who is in control.

Tools are functions the model decides to call: search this index, create this ticket, run this query. Resources are data the application decides to attach: file contents, a record, a log stream, addressed by URI. Prompts are templates the user explicitly invokes, slash-command style. Model-controlled, application-controlled, user-controlled. Most servers in the wild are overwhelmingly tool-shaped, but the other two exist because "the model chooses" is the wrong control model for plenty of data, and the protocol was honest enough to admit that up front.

Discovery is a single call. The client asks tools/list and gets back, for each tool, a name, a natural-language description, and a JSON Schema for the arguments:

// tools/list response, one tool shown
{ "jsonrpc": "2.0", "id": 3,
  "result": { "tools": [ {
    "name": "search_tickets",
    "description": "Full-text search over support tickets",
    "inputSchema": {
      "type": "object",
      "properties": { "query": { "type": "string" },
                      "limit":  { "type": "number" } },
      "required": ["query"] } } ] } }

Invocation is one more:

// tools/call request
{ "jsonrpc": "2.0", "id": 7, "method": "tools/call",
  "params": { "name": "search_tickets",
              "arguments": { "query": "refund dispute", "limit": 5 } } }

That is the core of the protocol. Two messages. Everything you already believe about API design still applies, which is why the quality spread between MCP servers is enormous: the protocol faithfully transports your tool descriptions to the model, and if those descriptions are vague, the model flails with standardized plumbing instead of flailing with custom plumbing. The spec moves the integration problem; the context discipline is still on you.

One production note that surprises people: the assembled tool list becomes part of your prompt on every single call. A host with six connected servers can be carrying tens of thousands of tokens of tool definitions before the user types a word. Keep the list stable and it becomes a perfectly cacheable prefix; churn it per request and you pay full price for the plumbing on every call.

The Direction Everyone Misses

The part of MCP that almost never makes it into the explainers is that the conversation runs both ways. Servers can make requests of the client. With sampling, a server asks the host's model to complete something, which means a server can use an LLM without shipping its own API key or picking a vendor. With roots, the host tells the server which directories it is allowed to care about. With elicitation, added to the spec in mid-2025, a server can pause and ask the user a structured question: which environment, which account, are you sure. Servers can also notify clients that their tool list changed, and long operations can stream progress.

None of this is exotic, but it is the difference between "a registry of functions" and "a protocol." The two-way channel is what lets a server be interactive and composable instead of a dumb adapter, and it is the part that will matter more as agents run longer and need supervision mid-task.

What MCP Is Not

Three category errors account for most of the confusion I see, and they are worth killing explicitly.

MCP is not an agent framework. There is no loop in the protocol. Nothing in MCP decides which tool to call, retries failures, plans multi-step work, or stops. All of that lives in the host. If your agent is bad at deciding, MCP will deliver its bad decisions very interoperably.

MCP is not RAG. Retrieval-augmented generation is an architecture: fetch relevant content, put it in the context, generate. MCP is how an application reaches capabilities, one of which might be retrieval. They compose; they do not compete. I wrote a full essay on this confusion because the question would not stop arriving.

MCP is not a model capability. The model never sees MCP. By the time the context is assembled, the protocol has already done its work, and what the model sees is tool definitions and tool results, exactly as if you had defined the functions directly. Function calling is the model skill; MCP is the delivery mechanism. This is also why "does model X support MCP" is usually the wrong question. The host supports MCP. The model just needs to be good at calling tools.

The Security Paragraph the Quickstarts Skip

Every MCP server you connect is code that runs with real credentials and injects text into your model's context. Both halves of that sentence are attack surface. A malicious or compromised server can carry hostile instructions in a tool description or a tool result, and the model will read them as faithfully as it reads everything else, which is prompt injection with a supply chain attached. The protocol's auth model has matured, with OAuth-based authorization in the current spec, but authorization tells you the server is who it claims to be, not that its output deserves trust.

Treat servers like dependencies: pin them, review them, prefer official ones, and give each one the narrowest credentials that still work. And scope what the agent can do, not just what it can say. The same argument I made about guardrails that gate actions instead of words applies with more force here, because MCP's whole purpose is to give the model more reach.

When You Do Not Need MCP

Here is the decision rule I actually use. Count the sides of the integration you control, and count the hosts that need it.

One application you own, talking to one system you own: define the tools directly in your application and skip the protocol. It is less code, one fewer process, one fewer security boundary, and you lose nothing, because the model behaves identically either way. A surprising amount of MCP adoption is teams adding a protocol hop between two things they both own, which is wearing a raincoat indoors.

The calculus flips the moment a capability needs to travel. The same internal search exposed to Claude, your IDE, and your support tool: that is three custom integrations or one server. A product that customers wire into their own assistants: that is a server by definition, because you do not control the host side. A company where three teams keep rebuilding the Jira adapter: one server, three deletions. The protocol earns its complexity at exactly the point where the number of host-system pairs exceeds the number of systems, which is the same point where every standard in history started paying rent.

MCP won because it was small enough to implement in a weekend and arrived when every vendor had already felt the N times M pain. It will keep winning for the same reason ODBC and LSP did: nobody loves plumbing enough to keep rebuilding it. Know what it is, read the two messages that matter, and spend your cleverness on the parts of the stack that still reward it.

FAQ

What does MCP stand for and who created it?
Model Context Protocol, an open standard released by Anthropic in November 2024 for connecting AI applications to external tools and data. It is not Anthropic-only: the major vendors and thousands of community servers have adopted it, and anyone can implement the spec.

What is the difference between MCP and function calling?
Function calling is the model capability: emitting a structured request to invoke a described tool. MCP is the wire protocol for discovering and invoking tools across process boundaries so one integration works in every host. Own both ends of one integration and plain function calling is simpler.

Is MCP the same as RAG?
No. RAG is an architecture that retrieves content into the context before generation. MCP is plumbing that standardizes how applications reach tools and data. A server can expose retrieval as a tool, so they compose.

Do I need to build an MCP server?
Build one when a capability must work across multiple hosts, when outside assistants need to reach your system, or when teams keep rebuilding the same integration. For one integration inside one application, directly defined tools are less code and one fewer security boundary.