Model Context Protocol: A common language for tools

The announcement and the narrow claim

On 25 November 2024, Anthropic published the Model Context Protocol, an open standard for connecting AI assistants to the systems where data and tools already live. The narrow, documented claim is modest and worth stating precisely: MCP is not a model, a training method, or a capability that makes an assistant intrinsically more intelligent. It is a wire format and a set of conventions, a shared interface through which an application can advertise what it can do and an assistant can discover and call those capabilities. The launch shipped three concrete things at once: the protocol specification with software development kits, local server support inside the Claude Desktop apps, and an open-source repository of ready-made servers. The engineers credited with the design, David Soria Parra and Justin Spahr-Summers, framed the problem as integration rather than intelligence.

The historical significance therefore belongs to a different category than a benchmark result. A useful question is not whether MCP made any single model better on a task, but which recurring engineering constraint it addressed, which earlier ideas it borrowed, and which later decisions by other organizations depended on it. Keeping the narrow technical claim distinct from the broad ecosystem judgment is the only way to read this event without inflating it. A protocol succeeds or fails on adoption, not on elegance, and that is a very different standard of evidence than the one that applies to a new architecture or a new capability.

The integration problem it set out to name

Before MCP, connecting a capable model to an external system was a bespoke exercise repeated for every pairing. OpenAI had already demonstrated both halves of the pattern: ChatGPT plugins in March 2023 let a model call third-party services described by an OpenAPI schema, and function calling in June 2023 let developers declare callable functions inside the API request itself. Both worked, and both were tied to one vendor's interface. A team that wanted its database, ticketing system, or file store reachable from several assistants had to write and maintain a separate adapter for each one. This is often described as an M by N problem: M applications times N data sources, with each intersection a custom integration to build and keep alive.

MCP's proposal was to collapse that grid into M plus N. A data owner writes one server; any compatible client understands it. Anthropic's framing was that fragmented, one-off connectors would be replaced by a single protocol, so that models were no longer trapped behind information silos. The claim to evaluate is not that this idea was novel in the abstract, since shared protocols are an old idea in computing, but that a major model vendor published one as an open standard and shipped enough tooling for others to adopt it. That combination, not the underlying concept, is the event.

Borrowing a proven pattern: the Language Server Protocol

The design did not appear from nowhere, and its authors said so. The specification states that MCP takes inspiration from the Language Server Protocol, Microsoft's standard that lets one language server provide autocomplete, diagnostics, and navigation to any compatible editor. LSP solved an almost identical M by N problem in developer tooling: before it, every editor needed a custom integration for every programming language, and after it a language ecosystem could ship one server and reach every editor that spoke the protocol.

The analogy is precise and clarifying. LSP is deliberately unglamorous plumbing, and its influence came from adoption rather than cleverness. MCP inherits both the architecture, a client embedded in a host application talking to an external server over structured messages, and the strategic bet, that the value of a protocol is a function of how many independent parties implement it. Reading MCP as an LSP for AI tools is more accurate than reading it as a breakthrough in what models can do. It reframes the achievement as coordination, which is a genuine and difficult kind of contribution, not a lesser one. The choice to imitate a boring, successful standard rather than invent a novel one was itself a design decision, and probably a wise one.

How the protocol actually works

Mechanically, MCP defines three roles. A host is the LLM application that initiates connections, such as a desktop assistant or an integrated development environment. Within the host sit clients, the connectors that each maintain a session with one server. Servers are the external services that expose context and capabilities. Messages travel as JSON-RPC 2.0, a lightweight remote-procedure-call format, over stateful connections that begin with the client and server negotiating which features each supports.

The capabilities themselves are grouped into a small set of primitives, documented in the MCP specification. Servers can offer Resources (context and data for the user or model to read), Prompts (templated messages and workflows a user can invoke), and Tools (functions the model can execute). Clients can offer Sampling, which lets a server ask the host to run a model completion, enabling recursive or agentic behavior while keeping the server from seeing the raw prompt unless the user allows it. Around these sit utilities for progress tracking, cancellation, logging, and error reporting. The design deliberately separates who describes a capability from who decides to invoke it, and that separation is exactly what makes one server usable by many different clients without any of them knowing about each other in advance.

What shipped on day one

A specification with no implementations persuades no one, so the launch bundled working code. Anthropic released SDKs and published the reference MCP repositories on GitHub, including pre-built servers for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer, systems chosen because they are exactly the everyday tools a knowledge worker or developer already uses. Local server support in Claude Desktop meant a user could connect these without standing up any cloud infrastructure, which lowered the barrier to a first working demonstration to minutes.

The announcement also named early adopters, which matters for a standard's credibility. The payments company Block and the API platform Apollo were cited as early integrators, and Block's chief technology officer described open protocols as the bridges that connect AI to real-world applications. Development-tool companies including Zed, Replit, Codeium, and Sourcegraph were listed as working to add MCP support to their products. None of this proves the protocol was well designed; it proves only that the launch was structured to seed an ecosystem rather than to publish a document. For a coordination technology, that distinction is close to the whole game, because a protocol that no second party implements is just an internal API with ambitions.

Standardization is a social problem, not only a technical one

The strongest evidence that MCP mattered is that competitors adopted it, which is unusual for a standard published by one AI lab. Over the following months, the protocol moved from an Anthropic project toward an industry default. OpenAI documented MCP support in its own developer platform, and mainstream developer tools built it in: Microsoft shipped MCP server support in Visual Studio Code, and editors such as Cursor and Zed did the same. The MCP documentation now describes the goal plainly, comparing the protocol to a USB-C port for AI applications in its introduction: build a server once and connect it everywhere.

This adoption is the load-bearing part of the historical claim, and it should be stated carefully. Adoption by rivals demonstrates that MCP solved a shared pain point well enough to beat the alternative of each vendor maintaining its own scheme. It does not demonstrate that MCP is the best possible design, that its security model is adequate, or that it will remain dominant. Standards win for reasons that include timing, first-mover tooling, and the cost of maintaining parallel formats, not design merit alone. The interesting fact is not that MCP is perfect but that a single lab's proposal became a point around which competitors converged, which is rare and consequential in itself.

The protocol did not stand still

A protocol used in production accumulates requirements, and MCP's specification was revised substantially. The 2025-03-26 revision added an authorization framework based on OAuth 2.1, replaced the original transport built on HTTP plus server-sent events with a more flexible Streamable HTTP transport, introduced tool annotations so a server can declare whether a tool is read-only or destructive, added support for audio content alongside text and images, and folded in JSON-RPC batching. A further 2025-06-18 revision continued to refine authorization and the interaction model between server and user.

These changes are informative about the event's real nature. The initial November 2024 release was a starting point, not a finished artifact, and several of its most consequential problems, especially authentication and remote transport, were addressed only later. This is normal for infrastructure and worth stating against any narrative that a single announcement delivered a complete standard. The version dates are not pedantry: a claim about what MCP does is ambiguous unless it names a revision, because the primitives stayed stable while the security and transport story changed materially within a year of launch.

The security caveat the protocol does not resolve

The record is blunt that MCP is not a security boundary by itself, and the specification agrees, stating that MCP cannot enforce its security principles at the protocol level and that tool descriptions should be considered untrusted unless they come from a trusted server. That is not a footnote. Because a tool's description is text the model reads and acts on, a malicious server can hide instructions inside it. In April 2025, Invariant Labs documented tool poisoning attacks, in which a server embeds directives in a tool description, invisible to the user in the client's simplified interface but fully visible to the model, that instruct it to read sensitive files such as SSH private keys and exfiltrate them while narrating an innocent explanation.

The researchers also described shadowing, where one server alters how the agent behaves toward a separate trusted server, and rug pulls, where a server changes a tool's description after the user has approved it. The lesson generalizes: making it easy to connect an assistant to arbitrary tools also makes it easy to connect it to hostile ones. Consent flows, permission scoping, authentication, and provenance are the responsibility of the host application and the user, and MCP's own guidance is explicit that implementors, not the protocol, must build them. A convenient interoperability layer inherits the trust problems of everything it interoperates with, and that inheritance is now an active area of security research.

Where MCP sits among alternatives

MCP did not enter an empty field, and it is not the only way to give a model tools. The most direct alternatives were the vendor-specific mechanisms it aimed to supersede: OpenAI's function calling and the OpenAPI-described plugin model, both of which remain in wide use inside their own ecosystems. A model can also call any web service directly through conventional REST or GraphQL APIs, with the developer writing the glue by hand each time. What MCP offered over these was a single client-side implementation that works across many servers and, crucially, dynamic discovery: a client can ask a server at runtime what it offers rather than being compiled against a fixed set of endpoints known in advance.

A distinct and complementary effort is agent-to-agent communication, where the unit of connection is not a tool but another autonomous agent, addressing coordination between systems rather than between an application and its own data. Reasonable engineers still debate whether a general-purpose protocol is preferable to task-specific APIs, and whether MCP's flexibility is worth its added surface area and security burden. Presenting MCP as the inevitable answer would overstate the case. Presenting it as the option that achieved the broadest cross-vendor adoption in its first year is accurate, and that adoption, more than any property of the design, is what a reader should weigh.

How to place this event in AI history

The defensible reading is that MCP is an infrastructure and standardization milestone, not a capability milestone. Its narrow, documented achievement is a published open protocol, with reference implementations, that standardizes how an AI application discovers and calls external tools and context. Its broad historical significance, still being determined, comes from the unusual speed with which independent organizations adopted it, which nudged the industry toward a common connection layer instead of a lattice of proprietary adapters.

Two disciplines keep the assessment honest. First, separate the layers: a shared protocol changes how systems connect, not how well a model reasons, and conflating the two credits MCP with progress that actually came from models and training. Second, hold the timeline and the caveats together: the November 2024 release began a fast-moving standard whose authorization and transport matured over the following year, and whose security properties depend entirely on the applications that implement it. MCP earns its place in the timeline much as the Language Server Protocol earned its place in developer tooling, by making integration cheap enough that an ecosystem could form around it. That is a real and consequential contribution, and it is a different kind of contribution from making a model smarter.

References

• Anthropic (2024). Introducing the Model Context Protocol.
• Model Context Protocol (2025). Specification, revision 2025-03-26.
• Model Context Protocol (2025). Key Changes, revision 2025-03-26.
• Model Context Protocol (2025). Specification, revision 2025-06-18.
• Model Context Protocol (2025). What is the Model Context Protocol.
• JSON-RPC Working Group (2013). JSON-RPC 2.0 Specification.
• Microsoft (2016). Language Server Protocol.
• OpenAI (2023). ChatGPT plugins.
• OpenAI (2023). Function calling and other API updates.
• OpenAI (2025). Model Context Protocol in the OpenAI API.
• Microsoft (2025). Use MCP servers in Visual Studio Code.
• Invariant Labs (2025). MCP Security Notification: Tool Poisoning Attacks.
• GitHub (2024). The modelcontextprotocol organization.