What is the Model Context Protocol?
The Model Context Protocol is a shared set of rules that lets an AI app connect to outside tools and information, much like a standard plug that fits any socket. The AI app contains a small connector, and that connector links up to separate helper programs, each of which offers three kinds of abilities the AI can use. The messages travel in a plain, widely understood format over everyday channels, which is a big reason so many people adopted it so quickly.
The three primitives are worth learning properly, because they carry different risks and get secured differently.
| Primitive | What it is | What it needs |
|---|---|---|
| Tools | Executable functions the model can call to take an action: run a query, create a ticket, send a message | Tight permissions and explicit rules on when they may run. This is where actions happen |
| Resources | Data the model can read. Documents, records, files exposed as addressable content | Access control and validation, since resources are both a leakage path and a poisoning path |
| Prompts | Predefined templates with parameters supplied at runtime | Protection from modification, because they shape behaviour directly |
Two clarifications that save confusion. MCP servers are generally thin adapters over existing APIs rather than new services: the API still does the work, and MCP standardises how an agent finds and calls it. And MCP does not replace function calling, it builds on top of it, since the model still uses function-call mechanics underneath.
Where this sits relative to retrieval. Retrieval-augmented generation makes a model more knowledgeable: it fetches information into the prompt. MCP makes a model more capable, because resources let it read and tools let it act through the same interface. That single difference, read plus write rather than read alone, is what turns a well-informed assistant into something that needs governing. See agentic RAG for the retrieval side.
What problem does MCP solve?
Combinatorial integration work. Without a shared protocol, connecting several AI applications to several tools needs a bespoke integration for every pairing. MCP reduces that to one integration per tool, reusable by any MCP-compatible application, which is the entire reason it won.
The arithmetic is the argument, and it is the same argument that carried USB and HTTP.
The consequence for a buyer is less about engineering effort than about lock-in. When every platform speaks the same tool protocol, the tools you build stop being tied to the framework you built them with. That shifts where switching costs live, and it is covered at agent frameworks: convergence on MCP moved the lock-in from the tool layer to state, memory and telemetry.
It also explains the adoption curve. A protocol that reduces work and reduces lock-in simultaneously gets adopted by vendors who normally resist standards, which is why the major agent platforms integrated it inside a year rather than after the usual standards fight.
Who governs MCP, and what has changed?
Anthropic released it in November 2024 and stewardship now sits with the Linux Foundation, through the Agentic AI Foundation, with Microsoft among the platinum members. The specification is still moving, and one recent change is not fully backward compatible with servers built earlier.
The governance transfer matters for the same reason it mattered for the Agent-to-Agent protocol: a standard controlled by one vendor is a proposal, and a standard held by a foundation is infrastructure.
Three changes are worth knowing if you are building rather than reading.
- March 2025: bespoke auth replaced by OAuth 2.1. Early implementations were doing token passthrough, which is dangerous enough that the specification moved rather than patched.
- June 2025: MCP servers classified as OAuth Resource Servers, with clients required to implement Resource Indicators under RFC 8707. That specifically stops a malicious server obtaining a token intended for a different server. Production remote connections should enforce OAuth 2.1 with proof key for code exchange.
- The 2026-07-28 specification update is not fully backward compatible with earlier servers. This one is recent enough that a lot of published guidance predates it. If you have servers built against the older stateful specification, you need a migration plan rather than an upgrade.
An official registry now exists as well, which matters because several documented incidents involved malicious servers distributed through unofficial registries. Where you get a server from is part of your threat model.
Why is every MCP connection a trust decision?
It is risky because a tool's description is writing that the AI reads, and anything the AI reads can steer what it does. So, any helper program you connect can shape your AI's behaviour just through the way it describes itself. That is how the system is meant to work, not a hole someone sneaks through. It is not a flaw or bug in the MCP; it is simply what it means to connect to someone else's tool.
This is the part of the subject that vendor material treats briefly and security research does not.
Tool poisoning
Research introduced the term for a specific manifestation of prompt injection in MCP contexts: malicious instructions embedded in tool metadata rather than in user input. A compromised or hostile server crafts a tool description that manipulates the model, for instance instructing it to forward sensitive data to an endpoint the attacker controls. The user sees a tool with a plausible name. The model sees the full description.
The measured position is not reassuring. One study built a test suite against 45 live MCP servers exposing 353 authentic tools, generating over 1,300 malicious cases across ten risk categories, and evaluated twenty agents. Attack success rates reached as high as roughly 73%, and the best refusal rate observed was under 3%. Separate threat modelling across six MCP components identified more than fifty threats and found client-side security inadequate in most implementations tested, with some reaching 100% success.
The same work notes that well-built clients do defend successfully, so this is an implementation gap rather than an unsolvable property. But it means the client you use is a security decision, not a preference.
The trust model moved from build time to runtime
This is the shift worth internalising. With a framework, you imported a library and could audit the code you shipped. With MCP you connect to a server, possibly one you did not write, whose descriptions enter your model's context, and which can change after you approved it. Documented incidents through late 2025 included poisoned editor extensions, a malicious package update reaching millions of installs, and malicious MCP servers on unofficial registries.
Two further pointers. A critical remote code execution vulnerability was assigned against Anthropic's own MCP Inspector tooling, which is a useful reminder that the tooling around the protocol is also attack surface. And in May 2026 the United States National Security Agency published a cybersecurity information sheet specifically on MCP security, alongside guidance from the Australian Cyber Security Centre on careful adoption of agentic AI services. When signals intelligence agencies publish protocol-specific guidance, the risk has stopped being theoretical.
The working assumption security researchers recommend: treat every MCP server as hostile until proven otherwise. That sounds severe until you notice it is how you already treat any third-party API that returns data into a system with permissions. The difference is that an MCP server returns data into a component that acts on text, which is why the usual input validation does not apply. The delivery mechanism is covered at prompt injection, and the structural point stands: model-layer defences reduce this and do not eliminate it.
What does MCP not do?
Three things people routinely assume it covers and it does not. It makes no decision about which agent handles which task, it carries no governance or policy across the connection, and it authenticates the caller without ever establishing whose authority is actually being exercised.
Each gap is deliberate and each belongs to a different layer.
- It is not the agent-to-agent layer. MCP connects an agent downward to tools; delegating work to another agent is a different problem with a different standard. See the Agent-to-Agent protocol, and agent interoperability for how the layers stack.
- It does not orchestrate. Nothing in MCP decides sequence, handles partial failure, or reconciles conflicting results. See multi-agent orchestration.
- It authenticates the connection, not the principal. OAuth 2.1 with Resource Indicators establishes that this client may call this server. It does not establish which human the agent is acting for, which is the attribution problem described at agent identity, including why effective permissions must be the intersection of user and agent rather than the union.
- It carries no policy. Risk classification, approval requirements and audit obligations do not travel across an MCP connection. They stay with you.
None of this is criticism. A protocol that tried to solve orchestration and governance as well as transport would not have been adopted. It does mean the surrounding apparatus is your work, and the cost of an MCP integration sits there rather than in the protocol.
How should you adopt MCP?
Layered, and with the assumption that any single control will fail. Security research on MCP converges on roughly five layers, with the observation that each layer approximately halves the blast radius and that production deployments want at least three of them.
Ordered so the cheapest and most effective come first.
-
Maintain an approved server list
Agents connect only to servers on it. This single control eliminates the malicious-registry class of incident outright, and it is a process decision rather than an engineering one. Pin versions, because a server that was safe when approved can change.
-
Isolate execution
Run servers in containers with no more network reach than the tool genuinely needs. Egress allowlisting matters more than it sounds: most exfiltration requires an outbound path, and removing the path removes the outcome regardless of whether the injection succeeded.
-
Enforce OAuth 2.1 with Resource Indicators
For any remote server, with proof key for code exchange and least-privilege scopes. Resource Indicators specifically prevent one server obtaining a token meant for another, which is the failure the specification changed to address.
-
Inspect tool metadata, not just tool behaviour
Static analysis of tool descriptions before a server is approved, and again when it changes. Since the attack lives in the metadata, a review that only tests what the tool does will miss it entirely.
-
Log every tool call, with arguments
You cannot detect a poisoned tool from an outcome alone. What you need is the call, the arguments passed, and what came back, per step, which is the observability requirement.
-
Keep a human on the irreversible
The layer that holds when the others miss. Approval gates on anything you cannot undo, and reversibility designed in where you can. Architecture survives a hijack in a way that model-layer defences do not.
One planning note that catches teams out. Internal servers are not exempt. An internal MCP server still touches real data and still gets chained into workflows nobody anticipated when it was written, so skipping the review because it is internal reproduces the external risk inside your perimeter.