Think back to the years when every phone, camera, and laptop shipped with its own charger. A drawer full of incompatible bricks, each useless for any device but the one it came with. USB-C ended that. One connector, one shape, and any cable now reaches any port.
AI tooling had the same drawer problem, badly. In early 2024, if you were building an assistant that needed to read a Google Drive folder, query a Postgres table, and open a GitHub issue, you wrote three separate integrations: custom authentication, custom data formatting, custom error handling for each. Then a colleague built a different assistant that needed the same three tools, and wrote three more from scratch. The work did not compound. It multiplied.
The Model Context Protocol is the USB-C moment for that drawer. It is an open standard for how an AI application connects to the tools and data it needs, and in the eighteen months since it appeared it has gone from one company's internal experiment to infrastructure that OpenAI, Microsoft, Google, and Amazon all build on. Here is what it is, why it spread that fast, and where it still falls short.
Origin: the M-times-N problem
Start with the arithmetic, because it is the whole reason MCP exists.
Say there are M AI applications and N tools or data sources you might connect them to. Without a shared standard, every application needs a bespoke connector for every tool it touches. Connecting all of them is an M-times-N job. Five applications and ten tools is fifty separate integrations, each with its own auth flow, its own request shape, its own quirks when a field is missing. Worse, the integrations are not reusable: the GitHub connector one team wrote for their agent does nothing for the next team's. Add one tool and you owe M new integrations. Add one application and you owe N. The cost of the ecosystem grows as the product of two numbers, and nobody owns the seam in the middle. Anthropic, which built MCP, described it plainly as an N-times-M data integration problem.
A standard collapses the multiplication into addition. If every tool exposes one connector that speaks an agreed protocol, and every application speaks the same protocol, then a tool needs exactly one integration and an application needs exactly one. M-times-N becomes M-plus-N. Five applications and ten tools is fifteen implementations, not fifty. The GitHub connector written once now works with every compliant application that exists or ever will. It is the same trade an operating system makes when it standardizes file access: a program calls one interface and never ships a driver for a specific disk.
Anthropic announced MCP on November 25, 2024, open-sourcing the specification with SDKs for Python and TypeScript. The engineers behind it, David Soria Parra and Justin Spahr-Summers, did not invent the pattern from nothing. They borrowed the message-flow design of the Language Server Protocol, the standard Microsoft created so one code editor could support any programming language without a plugin per language. LSP turned an editor-times-language problem into editor-plus-language. MCP makes the same move for agents and tools, running it over JSON-RPC 2.0, a plain, well-understood remote-procedure-call format. The idea was not novel. Applying it to AI tool access at the right moment was.
Present: how MCP actually works
MCP defines three roles. Get these straight and the rest follows.
The host is the AI application the user interacts with: Claude Desktop, an IDE like Visual Studio Code, a custom agent you built. It runs one client for each tool it connects to, and each client holds a dedicated connection to one server. A server is a program that exposes a particular tool or data source through the protocol. The Sentry server exposes Sentry. The GitHub server exposes GitHub. A host using three tools runs three clients talking to three servers. Servers come in two flavors: local ones that run on your machine and talk to the client over standard input and output, and remote ones that run elsewhere and talk over HTTP, typically authenticated with OAuth.
The connection opens with a handshake. Client and server exchange an initialize message and negotiate capabilities, each side declaring what it supports so neither wastes effort on features the other lacks. Then the client asks the server what it offers, and this discovery step is the quiet key to the design. The client does not need the tool list hardcoded. It calls tools/list and the server answers at runtime, so a server can change what it exposes and connected clients find out through a notification rather than a redeploy.
What a server exposes falls into three primitives, and the distinction between them is worth holding onto.
Tools are functions the model can invoke to do something: run a database query, open a pull request, send a message. Each carries a name, a description of when to use it, and a JSON Schema for its inputs. This is ordinary function calling, the mechanism covered in tool use and structured output, with MCP supplying the standard wrapper around it. Resources are read-only data the model can pull in for context: a file's contents, a database schema, a document. Where a tool performs an action, a resource just provides information. Prompts are reusable templates a server ships to structure a task, a vetted query pattern or a set of few-shot examples, so the knowledge of how to use a tool well travels with the tool itself.
A less-discussed half of the protocol runs the other direction: a server can ask the client for things too. Through sampling, a server can request a language-model completion from the host without bundling its own model SDK, which keeps servers model-agnostic. Through elicitation, it can ask the user a question or request confirmation mid-task. These client-side primitives are what let an MCP integration be a genuine two-way conversation rather than a one-way pipe.
The payoff is the thing developers actually feel. Build a GitHub server once and it works with Claude, ChatGPT, Cursor, any host that speaks MCP, including ones that do not exist yet. The integration stopped being throwaway glue between one app and one tool. It became a reusable component with a market.
Present: the adoption curve
Standards usually fail. Most proposed protocols never escape the company that wrote them. MCP is the rare exception, and the numbers show it.
At launch in November 2024, the MCP SDKs saw roughly 2 million monthly downloads. By March 2026, the Python and TypeScript packages together had crossed 97 million monthly downloads, nearly fiftyfold in sixteen months. The curve did not creep. It stepped up with each major adoption: roughly 22 million once OpenAI signed on, 45 million after Microsoft, 68 million after AWS, 97 million with every provider aboard.
The more telling signal is who adopted it. A standard authored by one AI lab could easily have been ignored by its rivals on principle. Instead, on March 26, 2025, OpenAI adopted MCP across its Agents SDK, its Responses API, and the ChatGPT desktop app, with Sam Altman saying people loved MCP and OpenAI was glad to support it. A direct competitor adopting your open standard is the strongest possible vote that the standard has won: the alternative, fragmenting the ecosystem with a rival protocol, was right there and they declined it. Microsoft followed, wiring MCP into Copilot Studio. Google confirmed support in Gemini. Amazon brought it to Bedrock. By early 2026 every major model provider spoke the same protocol.
Then Anthropic gave it away. On December 9, 2025, the company donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, co-founded with Block and OpenAI and backed by Google, Microsoft, AWS, Cloudflare, and Bloomberg. This matters more than it might read. A standard controlled by one vendor is always one strategy change away from serving that vendor first. Neutral governance under the Linux Foundation, the body that stewards Linux and Kubernetes, removes that risk and is what lets a competitor commit to a protocol for the long term. MCP stopped being Anthropic's protocol and became the industry's.
The server ecosystem grew to match. Anthropic counted more than 10,000 active public MCP servers by the time of the donation. Real infrastructure companies ship and maintain their own: the Sentry server lets a coding assistant pull a stack trace straight from production, and Cloudflare's wraps its API for natural-language operations. A working pattern emerged fast: an assistant inside an editor reads an error from the Sentry server, opens a matching issue through the GitHub server, patches the code, and redeploys, every step under human approval, every tool reached through one protocol.
Future and impact: what MCP changes, and what it does not
The honest version of MCP's value is narrower than the hype, and more durable for it.
What it genuinely changes is the economics of integration. A tool vendor now writes one server and reaches every AI client. An agent builder writes one client and reaches every tool. The integration layer became a shared, reusable asset instead of private glue rewritten by every team, and one industry estimate puts the saving for multi-tool agent projects at 60 to 70 percent of integration effort. That is the real prize.
What MCP does not do is worth stating too, because the protocol gets credited with things it never claimed. It does not make a model smarter or an agent more reliable. It standardizes the connection, not the reasoning, and an agent that loops badly will loop badly over a beautifully standardized protocol. MCP is also one layer of a larger stack: it governs how an agent reaches a tool, while a separate standard, Agent2Agent, governs how one agent talks to another. MCP is the agent-to-tool layer, A2A the agent-to-agent layer. Both now sit under the same Linux Foundation roof, and the "Internet of Agents" framing needs both.
The open problems are real, and a practitioner should weigh them before betting on it.
Security is the sharpest. Once a model reads a tool's description and acts on it, that description is an attack surface. In a tool poisoning attack, a malicious server hides instructions inside a tool description, text the model reads and the user never sees, telling the agent to read a private file and exfiltrate it. Security researcher Simon Willison calls the dangerous combination the lethal trifecta: access to private data, exposure to untrusted instructions, and a way to send data out. An agent wired to several MCP servers can assemble all three without anyone intending it. The risk is not theoretical. The MCPTox benchmark, testing 20 production agents against 45 live servers with poisoned tool descriptions, found an average attack success rate of 36.5 percent, climbing past 70 percent on the most capable models, which follow the malicious instructions precisely because they follow instructions well. Refusal rates stayed under 3 percent. MCP's guidance lists mitigations, allowlisting trusted servers, human approval for consequential actions, runtime monitoring, but Willison's assessment stands: there is no clean universal fix, and the safeguards are mandatory, not optional.
Server quality is the second problem. Anyone can publish a server, and most of the 10,000-plus were written by individuals over a weekend. Documentation varies wildly, maintenance is uneven, and a tool description that confuses the model produces an agent that misfires. "It speaks MCP" tells you the wiring fits, nothing about whether the tool behind it is any good.
The registry is the third, partly a knock-on of the first two. An official MCP registry launched in preview in September 2025 as a discovery layer, but it deliberately leaves trust and security assessment to others. One analysis found tens of millions of server entries mapping to fewer than 1,700 unique underlying packages, the rest duplicates from automated publishing. For now there is little between "a server exists in the registry" and "your agent connects to it and runs its code." A curated, trustworthy catalog with real quality signals is not yet solved.
There is even a live debate over whether exposing dozens of tools directly to a model is the right shape at all. Anthropic's own work on code execution with MCP has the agent write code that calls servers as APIs rather than loading every tool definition into context, cutting token cost when many tools are in play. The protocol keeps moving.
None of this undoes the core achievement. Before MCP, connecting AI to the world was an M-times-N problem with no owner. After it, the seam in the middle is a public standard under neutral governance that every major vendor has adopted. The drawer of incompatible chargers is not entirely gone, but there is now a standard port, and that is what the next decade of agent building gets to assume. For teams putting agents into production, MCP is no longer a choice to deliberate. It is the default the rest of the architecture builds around.
Council summary
This post argues that MCP matters not because it is clever but because it solved an arithmetic problem: it turned the M-times-N cost of wiring every AI app to every tool into M-plus-N, and did it at the moment the agent industry needed a shared seam. The piece traces a full arc, from the Language Server Protocol lineage and Anthropic's November 2024 launch, through the protocol's primitives, to the adoption surge and the December 2025 handover to neutral Linux Foundation governance, and it is honest about the unsolved problems of tool poisoning, uneven server quality, and registry trust. The reader's takeaway is precise: MCP standardizes the connection, not the reasoning, so treat it as the settled default the rest of the architecture builds around, and treat its security mitigations as mandatory. The candor about what MCP does not do is what makes the case for what it does credible.
Comments