That an AI assistant manages to “read” a PDF, query a database or run a command is not magic: it is a protocol. It is called the Model Context Protocol (MCP) and, since November 2024, it has been becoming the standard way for a language model to connect with the outside world. This article breaks down its architecture without sticking to the marketing.
The problem it solves
A language model such as GPT, Claude or Llama computes token probabilities (the basic units of text) over a continuum of billions of parameters. It can only predict the next most likely word. It cannot “see” a file or “call” an API, unless the developer hand-crafts an integration for every single case. The result was the classic wired-protocol mess: a bespoke adapter for each tool and for each model.
MCP proposes the same trick that TCP/IP borrowed for networking or JDBC for databases: define one common interface so that any model can talk to any tool without coupling to each other. It is the intermediate layer that separates “thinking” (the model) from “doing” (the tool).
Architecture: client and server
The architecture is deliberately classical. An MCP client lives inside the application that uses the model (your chatbot, your IDE, your agent). An MCP server wraps each tool you want to expose: a file repository, a database, a ticketing system. The model never talks to the tool directly: it talks to the client, and the client negotiates with the server.
The telling part is the transport. The protocol relies on JSON-RPC 2.0, a remote-call format where every request and response is a JSON document with an id, a method and params. For local connections (server and client on the same machine) a stdio stream is enough: data flows over standard input and standard output, with no ports, no network, just like a Unix pipe. For remote servers it uses Streamable HTTP, the successor to the old SSE (Server-Sent Events) transport, which supports both one-shot request-response and bidirectional streaming.
The three primitives
The protocol reduces all the power of a tool to three concepts. A tool is an executable operation: its descriptor lists a name, a description and a JSON schema defining the arguments it accepts. It is the only primitive with side effects: writing to a database, sending an email. A resource is data exposed in a controlled way, identified by its own URI, such as file:///report.pdf; it is read, not executed. And a prompt is a reusable template, with variables and structure, that the model can reuse for repeated tasks without improvising the text again.
One subtle rule betrays how recent the standard is: tool names may only contain lowercase letters, numbers and underscores or hyphens ([a-z0-9_-]). No spaces, no capitals. It is a safety constraint that prevents an arbitrary name from causing collisions or confusion with the protocol’s internal vocabulary.
Capability negotiation and sampling
At connection startup, client and server exchange their list of capabilities with the initialize message: which primitives they support, the protocol version, which model roles they accept. It is the same pattern as a TLS handshake before encrypting the channel. Only after that handshake do the real calls begin.
Perhaps the boldest detail is sampling. Normally calls flow from the model to the tool; but with sampling the server can ask the client to generate an AI response, invoking its favourite model. That is the piece that enables agent composition: a tool that, to solve your question, consults a more specialized model. The client keeps control of consent and privacy, because it decides whether that nested call runs.
One final mention of roots: the client can announce which directories or URIs of the file system it considers “its own”, so a careful disk exposure is not full access to the machine. It is the principle of least privilege applied to an assistant.
Security and limits
MCP’s security rests on the model never having a direct backdoor: everything passes through the layer of tools that each application decides to expose. The standard also defines a typed error model over JSON-RPC, with codes such as InvalidRequest, MethodNotFound or ResourceNotFound, separating protocol failures from tool failures. And tool responses are not mixed with the model’s own content: they travel over separate channels (the content protocols), which prevents a made-up text message from slipping in where a real result is expected.
Why it matters
MCP is not the first integration layer for AI, but it has the best doorway: its specifications are public, it runs on already-known infrastructure (JSON, HTTP, sockets) and, above all, it separates “thinking” from “doing” with a clean boundary. Just as nobody designs a network without the IP protocol today, the agents you are starting to use to move files and call services rest increasingly on this layer. Understanding its three primitives and its capability negotiation is, to a large extent, understanding how an agent is built.
