Every time an AI assistant wants to query your database, read a file, or run an action, until recently it needed a bespoke API for each service. The Model Context Protocol (MCP) was born to end that Tower of Babel: a single open protocol that teaches models to talk to any tool.
What MCP is and why it is needed
MCP is an open protocol built on JSON-RPC 2.0, a remote procedure call format that encodes requests and responses in JSON. Anthropic proposed it in November 2024, and today it is an open standard with implementations in dozens of languages. Its goal is that a language model does not need to know how each service works: it only needs a common language to ask for things.
Before, integrating an assistant with a tool meant writing a specific adapter for every model-service pair. With MCP, a tool’s server is written once and any compatible client can use it. It is the same argument that made USB popular: one universal connector instead of a different cable for every device.
The architecture: host, client, and server
MCP defines three clearly separated roles. The host is the application that hosts the model (an editor, an agent, an IDE). The client keeps a one-to-one connection with a server. And the server exposes the capabilities of a specific tool or data source. A single host can open several clients, each connected to a different server, and the model can switch between them without changing language.
This separation is key: the model never connects directly to the tool. There is always a client in between that translates the model’s requests into the protocol and the server’s responses back to the model.
The three primitives: tools, resources, and prompts
The protocol defines three kinds of capabilities a server can offer. Tools are functions the model can invoke, described with a JSON Schema, a standard for declaring the shape of input and output data. Resources are data the application exposes to the model, such as files, database rows, or code snippets. Prompts are reusable templates that structure how a task should be requested.
The distinction between tools and resources is subtle but important: a tool performs an action (send an email, run a query), while a resource only delivers information (the content of a document). The model decides which to use depending on what it needs at each moment.
How a call travels through the protocol
The flow is always the same. First, the server announces its tools to the client, each with its JSON schema. When the model decides it needs to run one, the client sends a tools/call request with the arguments. The server performs the real action and returns a structured result. The model does not execute anything: it only asks, and the server is the one that acts.
That separation is the basis of security. The model has no direct access to the system; it can only request operations the server has decided to expose. If a tool is poorly designed, the damage is limited to what that tool allows.
Transports: from local processes to remote servers
MCP supports two transports, the physical channels over which messages travel. The first is stdio: the server runs as a local process and communicates with the client through standard input and output pipes, ideal for tools installed on the same machine. The second is streamable HTTP, which allows connecting to remote servers using HTTP requests and streaming responses. In earlier versions there were two separate HTTP transports (one with Server-Sent Events); they were unified into a single one to simplify things.
Sampling and authentication
The protocol also covers sampling, an inversion of control: the server can ask the model to complete some text and return the result. This lets a tool use the model itself for tasks such as summarizing or classifying data, without the host orchestrating everything.
For remote servers, authentication relies on OAuth 2.1, the standard for access delegation, and authorization is managed per concrete resource. This way, a server can allow reading a document but not modifying it, and consent is requested explicitly.
Why it matters and what it still lacks
MCP standardizes the integration of AI with the real world: a single protocol for thousands of tools, interoperability between clients and servers from different vendors, and a model that does not need to know the implementation details of anything. It is the piece that turns an assistant into an agent capable of acting, not just conversing.
But it is young and has risks. Prompt injection —when malicious data inside a resource manipulates the model into performing unwanted actions— is a real threat that forces designing tools with least privilege. The latency of remote calls and permission management remain open challenges. Even so, the protocol is already the de facto standard for connecting models with tools, and its adoption keeps growing.
