Before MCP, connecting an AI application to a tool meant writing an integration for that specific pairing. A different application wanting the same tool wrote its own. The work was duplicated across the industry thousands of times, and none of it was portable. MCP is the boring infrastructural fix for that — and boring infrastructural fixes are usually the ones that matter.
What it is
The Model Context Protocol is an open standard, introduced by Anthropic in November 2024, that defines how AI applications talk to external tools and data sources.
A tool implements the protocol once as a server. An application implements it once as a client. Any client can then use any server, with neither having been written with the other in mind.
The N x M problem
The situation MCP was designed for is one every integration ecosystem eventually hits. You have N applications that want tools, and M tools that want to be used. Connecting them pairwise means N x M separate integrations.
The saving looks modest at these numbers and becomes decisive at real ones. With 50 applications and 200 tools, pairwise integration is 10,000 pieces of work that nobody will ever do; the protocol approach is 250.
💡 The Language Server Protocol precedent
This exact problem was solved once before, for editors. Every editor needed language support for every language — N editors x M languages, each combination hand-built and none reusable.
Microsoft's Language Server Protocol (2016) collapsed it: a language implements a server once, an editor implements a client once. MCP is openly modelled on LSP, borrows its client-server shape and even its JSON-RPC foundation. If you know why LSP mattered, you already know the argument for MCP.
The architecture
Three roles, and the distinction between the first two catches people out:
- Host — the application the user interacts with. It holds the model, the conversation and the permission decisions.
- Client — a connector inside the host, one per server, maintaining a single stateful session. Clients are isolated from each other by design: a server sees its own client and nothing else.
- Server — the program exposing capabilities. Usually small, often a single file, frequently wrapping an API that already exists.
The one-client-per-server isolation is a deliberate security property, not an implementation detail. A server you installed for database access has no visibility into your filesystem server's session, and cannot enumerate what else is connected.
Three primitives, three controllers
MCP servers expose three kinds of thing. The useful way to tell them apart is not by what they contain but by who decides they get used.
| Primitive | Controlled by | Example |
|---|---|---|
| Tools | The model | Run a query, send a message, create a file |
| Resources | The application | A file's contents, a schema, a record |
| Prompts | The user | A slash command, a review template |
Tools are the primitive people mean when they say MCP. The model reads their descriptions, decides one is relevant, and calls it. This is also why tool descriptions matter enormously — they are the entire basis on which the model chooses, and a vague description produces a tool that never gets used or gets used wrongly.
Resources are read-only context the host pulls in — identified by URI, attached to the conversation because the application or user chose to, not because the model asked. The separation matters: data the model can read is a different risk category from actions the model can take.
Prompts are user-triggered templates. They exist so that a server can ship a well-crafted workflow rather than hoping each user reinvents the phrasing.
Transports and the wire format
Underneath, MCP is JSON-RPC 2.0 — a long-established, deliberately dull request/response format. The protocol's contribution is the vocabulary on top, not the encoding.
Two transports carry those messages:
- stdio — the server is a subprocess; messages travel over standard input and output. Local, no network, no ports, no authentication needed because there is no remote party. This is how most desktop integrations run.
- Streamable HTTP — for remote servers, using HTTP POST with optional server-sent events for streaming. It replaced the earlier HTTP+SSE transport, which required two endpoints and handled resumption poorly.
The practical consequence: a local stdio server has your local privileges and no network exposure, while a remote HTTP server needs real authentication and is reachable by whoever can reach the endpoint. Those are very different security postures wearing the same protocol.
What a session looks like
Connections are stateful, which is what makes capability negotiation and change notifications possible.
Step 3 is the part that makes the whole thing work. The client does not need to know in advance what the server offers — it asks. That is why an application can support a server written after the application shipped, which is the entire point of a protocol.
What you accept when you install a server
MCP's convenience and its risk are the same property: you have given a model the ability to make things happen outside the chat. Three failure modes are worth understanding before you install anything.
🚨 A server runs with your privileges
A local MCP server is an ordinary process on your machine, started by your AI application, running as you. It can read the files you can read and reach the network you can reach. The protocol adds no sandbox.
"Install this MCP server" is therefore the same trust decision as "run this program", and deserves the same scrutiny — who wrote it, can you read the source, what credentials are you handing it. The friendly framing as a plugin makes it feel lighter than it is.
Prompt injection through tool results. A tool returns content, and that content enters the model's context. If it came from somewhere an attacker controls — a web page, an issue tracker, an email — it can carry instructions. The model has no reliable way to distinguish a tool's data from a tool's instructions, which is prompt injection arriving through a new door. An agent with one server that reads untrusted content and another that can act is a system where the first can drive the second.
Over-broad credentials. The path of least resistance is to give a server an admin key because scoping is fiddly. The model then has admin, permanently, mediated only by its own judgement. Scope credentials to the narrowest role that works, and prefer read-only wherever the task allows.
⚠️ Tool descriptions are model-facing instructions
A tool's description is not documentation — it is text injected into the model's context to influence its behaviour. A malicious server can write a description that instructs the model to do something unrelated to the tool, and the model reads it with the same weight as anything else.
This makes a third-party server's descriptions part of your prompt. Read them, and be wary of servers whose descriptions are longer or stranger than their function requires.
When MCP is the right answer
| Situation | Use MCP? |
|---|---|
| Integration reused across several AI apps | Yes — this is the case it exists for |
| Sharing a connector with other people | Yes — portability is the payoff |
| One tool, one app, no reuse planned | Direct function calling is simpler |
| Fixed sequence of API calls, no model choice | No — write the code |
| Latency-critical hot path | Weigh it — you are adding a process hop |
The last two deserve emphasis, because protocol enthusiasm tends to overshoot. If your model never chooses whether to call the thing — if the sequence is fixed — you do not need tool calling at all, let alone a protocol for it. That is a workflow, not an agent, and code expresses it better than a model can.
Working with JSON schemas and tool definitions?
Format, validate and inspect JSON entirely in your browser — nothing is uploaded to a server.
Open JSON Formatter →Summary
- MCP turns N x M integrations into N + M by standardising how AI apps and tools talk.
- It is openly modelled on the Language Server Protocol, which solved the identical problem for editors.
- Three primitives, distinguished by who controls them — tools (model), resources (application), prompts (user).
- JSON-RPC 2.0 over stdio or Streamable HTTP. Local and remote are very different security postures.
- Discovery at runtime is what lets a client use a server written years later.
- A server runs with your privileges. Installing one is a trust decision, not a plugin choice.
- Tool descriptions are injected into your model's context — treat a third party's wording as part of your prompt.
- If the model never chooses, you do not need a protocol for choosing.
Frequently Asked Questions
What is MCP?
The Model Context Protocol, an open standard introduced by Anthropic in November 2024 for connecting AI applications to external tools and data. It defines a common way for an AI app to discover what a tool can do and to call it, so that any compliant application can use any compliant integration without either side writing code specifically for the other.
What problem does MCP solve?
The N x M integration problem. With N AI applications and M tools, connecting everything meant writing N x M bespoke integrations, each one duplicating work someone else had already done. MCP makes each application implement the protocol once and each tool implement it once, turning N x M into N + M.
What is the difference between MCP tools, resources and prompts?
Tools are actions the model chooses to invoke, like running a query or sending a message. Resources are data the application pulls in as context, like a file or a database record, controlled by the app rather than the model. Prompts are templates a user deliberately triggers, like a slash command. The distinction is about who decides: the model, the application, or the person.
Is MCP only for Claude?
No. Anthropic created and open-sourced it, but the specification is not tied to any model or vendor. It has been adopted across a range of AI applications, editors and agent frameworks, and a server you write works with any client implementing the protocol.
Is it safe to install an MCP server?
Treat it exactly like installing any other software that runs with your privileges. A local MCP server is a process on your machine with whatever file, network and credential access you give it, and the model decides when to call it. The realistic risks are an untrustworthy server, over-broad credentials, and prompt injection reaching the model through content a tool returns.