In 1956 a trucking executive called Malcolm McLean loaded fifty-eight identical steel boxes onto a converted tanker. The boxes weren't the innovation. The dimensions were. Once a container was the same size everywhere, a ship, a crane, a train and a lorry no longer needed to know anything about each other — only about the box. Global shipping costs collapsed, and they collapsed because of an agreement, not a technology.
The Model Context Protocol is that agreement, for AI tools. Before it, every AI application that wanted to reach your GitHub, your database or your calendar had to write a bespoke connector for each one — and every tool that wanted to be reachable had to be integrated separately by every application. MCP replaces that with a published spec: build one server for your tool, and every compliant client can use it.
It went from an Anthropic release in November 2024 to a Linux Foundation project with around 10,000 active servers in about a year. Here is what it actually defines, why it spread so quickly, and the part most coverage skips — the security problem that standardising the connection created.
The Problem Was Combinatorics, Not Capability
Models could already use tools before MCP. What they couldn't do was use your tools without somebody writing glue code first.
The arithmetic is the whole story. With four applications and four tools, bespoke integration means sixteen connectors, each written, tested and maintained by someone. Add a fifth application and you owe four more. With a shared protocol, four clients and four servers is eight pieces of work, and a fifth application costs one.
Scale that up and it stops being an inconvenience and becomes a wall. Against roughly ten thousand MCP servers now in the wild, a new AI application without the standard would be facing ten thousand integrations to reach parity. It would simply never get built.
What the Protocol Actually Defines
MCP has a deliberately narrow scope, and the narrowness is a feature. It standardises the exchange of context and nothing else — it takes no position on which model you use, how you prompt it, or how your agent loop is structured.
Three roles. The host is the AI application you actually use — a chat app, an IDE, an agent. The host creates one client per connection, and each client maintains a dedicated link to one server. A server is simply a program that provides context; it can run locally on your laptop or remotely on a vendor's infrastructure.
Three things a server can expose. This is the part worth memorising, because the names get used loosely:
- Tools — executable functions the model can invoke. File operations, API calls, database queries. This is the primitive everyone means when they say "MCP."
- Resources — data sources the application can read for context. A file's contents, a database schema, an API response. Resources are read, not run.
- Prompts — reusable templates for structuring an interaction, such as a system prompt or a set of few-shot examples.
The distinction between tools and resources matters more than it looks. A tool does something and may have side effects; a resource just supplies information. If you have built retrieval-augmented generation before, resources are the familiar half — a standard way for an application to pull in context — while tools are the half that can change the world.
One thing a server can ask of you. Elicitation lets a server request additional information from the user mid-task, or ask for confirmation before doing something consequential. Two older client-side features, sampling and logging, were deprecated in the 2026-07-28 version of the specification.
Two transports. stdio connects to a server running as a local process on the same machine. Streamable HTTP connects to a remote server over HTTP, and the specification recommends OAuth for obtaining tokens. Underneath both sits JSON-RPC 2.0, and — like the model APIs it serves — the protocol is stateless: every request carries the version and capability information needed to process it on its own.
How It Became a Standard Rather Than a Product
A protocol released by one AI lab has an obvious credibility problem: why would competitors build on a rival's spec?
MCP resolved it by leaving. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI and supported by Google, Microsoft, AWS, Cloudflare and Bloomberg. MCP joined Block's goose and OpenAI's AGENTS.md as founding projects.
The adoption figures reported at the time of the donation explain why the other labs went along with it rather than competing:
| Signal | Reported at donation (Dec 2025) |
|---|---|
| Monthly SDK downloads | ~97 million |
| Active servers | ~10,000 |
| First-class client support | ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, VS Code |
Once a standard has that much gravity, the competitive move is to adopt it and differentiate elsewhere. This is the ordinary life cycle of successful infrastructure standards, and it is the strongest available evidence that MCP is not a passing vendor fashion.
What MCP Deliberately Does Not Do
Almost every misunderstanding about MCP comes from expecting it to solve a problem it explicitly declines to touch.
It is not an agent framework. It gives an agent a standard way to reach tools; it does not run the agent loop, decide when to call something, or manage your context window. Those remain entirely your problem — and they are covered across our AI agents topic hub.
It is not a model feature. Any model capable of tool use can be driven against MCP servers, and swapping models changes nothing about your servers.
It is not an authorisation system. The protocol carries authentication, but deciding which user may invoke which tool is left to you, and — as the security section below argues — that is exactly where the hard work sits.
It is not a guarantee of quality. Ten thousand servers means ten thousand codebases of wildly varying provenance, review and intent.
The Security Gap Standardisation Created
Here is the part that deserves more attention than it usually gets. Making every tool reachable through one interface also made every tool reachable through one interface for attackers.
The specific attack class has a name — tool poisoning — and OWASP now documents it as a form of indirect prompt injection. The chain runs: an attacker publishes a server whose tools look ordinary, gets an agent to connect, and when the agent calls one, the response mixes genuine data with embedded instructions. The model reads the whole response as trusted context and acts on it.
The mechanism is subtler than the usual "malicious tool description" framing, and OWASP puts its finger on exactly why:
In OWASP's words: "Tool descriptions are reviewed once, when the agent first connects to a server. Tool responses go straight into the LLM context with no equivalent check." That asymmetry — a one-time inspection guarding a channel that carries fresh untrusted text on every call — is what they call an unguarded runtime channel.
The practical consequence is uncomfortable: vetting a server at install time does not protect you. A server that behaved perfectly during review can start returning poisoned responses at any point afterwards, and nothing in the protocol will notice.
Nor is this theoretical. A 2025 large-scale analysis of the MCP ecosystem catalogued 370 publicly available servers exposing 1,062 tools with functionality relevant to this class of attack. OWASP's recommended defences are worth stating plainly, because they are all things you implement rather than things the protocol gives you:
- Constrain tool output to a fixed schema rather than accepting free text, so there is nowhere for prose instructions to hide.
- Isolate privileged tools in separate contexts from ones that read untrusted data.
- Enforce access controls at the tool execution layer, not in the prompt.
- Maintain an allowlist of approved servers.
- Require explicit user confirmation before sensitive operations.
If your organisation is thinking about MCP seriously, this belongs in the same conversation as the rest of your security posture rather than being treated as a developer-tooling detail.
Four Things That Trip People Up in Practice
MCP credentials usually aren't your API key. Hosted MCP servers typically expect an OAuth bearer token, not the service's native integration token. A Notion integration token that authenticates perfectly against Notion's REST API will not work as an MCP credential — they are different auth systems, and the resulting error messages rarely say so.
Declaring a server isn't the same as enabling its tools. In Anthropic's implementation, listing an MCP server and granting access to its tools are two separate parts of the request; supplying only the first is rejected as a validation error. It is a small thing that costs people an afternoon.
Restricted egress breaks MCP silently. If your environment denies outbound network access by default, the MCP server's domain has to be explicitly permitted. Otherwise the connection simply fails and the tools quietly don't work, with no obvious signal that networking is the cause.
Big tool outputs get truncated. A tool that returns a very large payload will typically not be handed to the model whole. Anthropic's platform offloads responses beyond roughly 100,000 characters to a file and gives the model a preview plus a path. Design tools to return high-signal results rather than everything they know.
Common Misconceptions
- "MCP is an Anthropic product." It was created there, and it now belongs to a Linux Foundation project co-founded with OpenAI and Block. Adopting it does not commit you to any one vendor.
- "MCP makes models better at using tools." It makes tools reachable. Whether the model chooses well still depends on the tool's description and your prompting.
- "An MCP server is a server." It is any program exposing the protocol — often a local process on your own laptop, communicating over stdio with no network involved at all.
- "If I only install trusted servers, I'm safe." Trust established at install time says nothing about what a tool returns next week. The review point and the risk point are not the same moment.
- "MCP replaces RAG." It standardises how an application reaches a data source. What you do with the retrieved text — chunking, ranking, grounding — is unchanged.
The Bottom Line
MCP is the boring, valuable kind of infrastructure: an agreement about interfaces that lets independently built things work together without knowing about each other. It defines three things a server can offer, two ways to connect, and one thing a server can ask of a user — and then stops, leaving the model, the loop and the policy to you.
That restraint is why it spread. A protocol that had also tried to dictate agent design would have been a competitor to every framework rather than a substrate underneath them.
The honest caveat is that a universal connector is a universal connector in both directions. The security work MCP requires is not protocol work — it is schema constraints, execution-layer access control, server allowlists and confirmation gates, all of which you build yourself. The standard solved the integration problem completely and the trust problem not at all, and it is worth being clear-eyed about which of those you are getting.
Frequently Asked Questions
What does MCP actually stand for, and what is it in one sentence?
Model Context Protocol. It is an open specification for how an AI application connects to external tools and data sources, so that any compliant application can use any compliant server without custom integration work. Think of it as a plug standard: the point isn't the plug, it's that everyone agreed on the same shape, so a tool built once works everywhere instead of needing a bespoke adapter per app.
Is MCP controlled by Anthropic?
Not any more. Anthropic created it and released it in November 2024, then donated it in December 2025 to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg. It sits alongside Block's goose and OpenAI's AGENTS.md as a founding project of that foundation.
What's the difference between a tool, a resource and a prompt?
A tool is an executable function the model can invoke, and it may have side effects — sending an email, writing a file, querying a database. A resource is data the application reads for context, such as file contents or a database schema; it is fetched, not run. A prompt is a reusable template for structuring an interaction. The safety-relevant line is between tools, which act, and resources, which only inform.
Do I need MCP to build an AI agent?
No. You can define tools directly in your own code and never touch the protocol, which is how most agents worked before 2024 and how plenty still work. MCP earns its keep when you want to reach tools you didn't build, or expose your own tool to applications you don't control. For a single agent with three in-house tools it is overhead you don't need.
Is MCP secure?
The transport is conventional and can use OAuth, but the harder problem is what comes back through it. OWASP documents tool poisoning, in which a server's responses carry hidden instructions that the model treats as trusted context. The structural issue is that tool descriptions are reviewed once at connection while responses arrive unchecked on every call. Defences — fixed output schemas, execution-layer access control, server allowlists, confirmation gates — are yours to implement.
Can I write my own MCP server?
Yes, and it is the normal way to expose an internal system. SDKs exist for the major languages, and a server can be a small local program speaking over stdio rather than anything network-facing. The design effort goes into the tool descriptions and the output shape rather than the protocol plumbing, because those determine whether a model picks the right tool and whether its response is safe to consume.
Does using MCP lock me into a particular model or vendor?
No, and that is much of the point. The protocol says nothing about which model runs behind the client, so servers you write keep working if you switch models or applications. The lock-in risk that remains is ordinary operational dependency on specific third-party servers — the same exposure you take on with any external API.
Sources
- Architecture overview — Model Context Protocol specification
- Donating the Model Context Protocol and establishing the Agentic AI Foundation — Anthropic (December 2025)
- Linux Foundation announces the formation of the Agentic AI Foundation
- MCP joins the Agentic AI Foundation — Model Context Protocol blog
- MCP Tool Poisoning — OWASP Foundation
- Parasites in the Toolchain: A Large-Scale Analysis of Attacks on the MCP Ecosystem — arXiv (2025)
