Model Context Protocol: The Plumbing Standard That Let AI Agents Actually Do Things

01 The Integration Problem: Every Model Times Every Tool

For most of the past decade, giving a language model the ability to touch the outside world was artisanal work. If you wanted your assistant to read a local file, query a database, or book a flight, you wrote a bridge built specifically for your model and specifically for that tool. The bridge knew the model's function-calling format on one side and the tool's API on the other. It worked — and then the next team wrote their own version of the same bridge for a different model, and the next vendor shipped a plugin format that worked with nothing else.

The arithmetic is brutal. With M distinct models and N distinct tools, a fully connected world needs M×N bespoke integrations. Ten models and fifty tools is five hundred bridges, each with its own failure modes, authentication quirks, and maintenance obligations. Every new model multiplies the work for every tool vendor, and every new tool multiplies the work for every model vendor. Progress in the field was throttled not by model capability but by plumbing.

Function calling alone did not solve this. Individual vendors had their own ways for a model to request a call, their own conventions for returning results, and their own plugin marketplaces. A tool author effectively had to choose an ecosystem and accept lock-in. What the field needed was not a better bridge but a shared socket — a single interface that every model and every tool could target once.

02 What the Model Context Protocol Actually Is

In November 2024, Anthropic introduced the Model Context Protocol as an open standard for connecting AI assistants to the systems where data lives and work gets done. The premise is simple: stop standardizing the models and standardize the seam between models and tools. MCP specifies how an application reads files, executes functions, and handles contextual prompts from external sources, using a common message format built on JSON-RPC.

Because the protocol is open and vendor-neutral, it belongs to no one's plugin catalog. Any model vendor can implement a host; any tool vendor can implement a server; the two can interoperate without a bespoke agreement. The specification covers how capabilities are discovered, how structured results are exchanged, and how an application can subscribe to changes as they happen — the difference between reading a file once and watching a directory.

The design deliberately mirrors patterns that already proved themselves elsewhere. The Language Server Protocol did something structurally identical for editors and compilers a decade earlier: one protocol, many editors, many language tools, zero pairwise engineering. MCP attempts the same for reasoning engines and the tools they command. The pedigree matters, because it means the idea arrived with a known failure profile and a known success profile.

03 The Architecture: Hosts, Clients, and Servers

Strip away the acronyms and MCP is three roles. The host is the application the human actually uses — a desktop assistant, an IDE, an agent framework. The server is a small program that wraps some capability: a filesystem, a database, a flight-booking API. The client is the piece inside the host that maintains a live connection to exactly one server and translates between the two.

Messages travel as JSON-RPC: plain, structured objects with a method name and parameters, the kind of payload any engineer can read in a terminal. On startup, the client asks the server what it offers. The server answers with three kinds of things: resources, which are data the model can read; tools, which are functions the model can ask the host to execute; and prompts, which are reusable templates for common interactions. The host presents that catalog to the model, the model decides which tool to call with which arguments, the human approves the call, and the server runs it and returns the result.

Nothing in that loop requires the server to know which model is calling, or the model to know how the server is built. That mutual indifference is the entire point. One host can spawn many clients, one per server, so a single assistant can sit in front of a whole workbench of tools without any of the tools having been designed for it.

04 The Adoption Cascade

A standard nobody else adopts is a product, not a standard. The decisive test came in 2025, when OpenAI — Anthropic's most direct competitor — announced support for MCP across its offerings, and Google DeepMind followed with adoption of its own. Whatever loyalty engineers felt toward any particular lab, the calculus collapsed to self-interest: one adapter per tool now reached every major model.

The third-party ecosystem compounded the effect. Community-built servers appeared for databases, version control systems, cloud consoles, and internal APIs, each written once against the protocol rather than N times against N vendor formats. A tool author who adopted MCP inherited compatibility with an entire industry of hosts overnight. The more servers existed, the more valuable every host became, and the more valuable the hosts, the more servers appeared.

The cascade is worth noticing as a pattern, because interoperability standards tend to look unimpressive right up until rival adoption makes them load-bearing. At that point the standard stops being a differentiator and becomes pavement — unremarkable, expected, and depended on by everyone.

05 What Standardization Does to the Agent Economy

When tools speak a common protocol, they become commodities — in the productive sense. A tool server that exposes a company's inventory API is swappable for a different vendor's server exposing the same shape of capability, without touching the agent that uses either. Procurement shifts from asking which AI platform integrates with our systems to asking which systems expose MCP, and the second question gives the buyer enormously more leverage.

For small vendors this is a distribution unlock: implement the spec once and every MCP-capable host is a potential customer. For enterprises it changes the build-versus-buy arithmetic, since the integration layer no longer has to be rewritten for each new assistant. For model vendors it moves competition onto model quality and hosting experience instead of plugin exclusivity — arguably where it should have been all along.

The honest caveat is that commodity plumbing also compresses margins on the plumbing itself. The value migrates to whoever owns the best tools, the best data, or the best orchestration on top of the protocol. That is the same way USB's standardization shifted hardware profits away from cable makers toward the makers of devices people actually wanted to plug in.

06 The Honest Limits: A Standard Is Not a Safety Model

MCP standardizes the interface, not the trust. An agent that can act on your behalf can also mis-act on your behalf, and giving it a uniform way to reach more systems widens the blast radius of every mistake. A protocol can carry a permission prompt to the human; it cannot make the human read the prompt.

The specific risks are familiar to anyone who has watched agent architectures collide with the open web. Tool results can carry instructions, so a hostile document read through one server can steer the model's behavior in another. Chained servers multiply the attack surface, because output of one becomes context for the next. A misconfigured server with broad filesystem access turns a helpful convention into a liability. None of this is a flaw in the specification; it is simply outside the specification's job description.

Permissioning and sandboxing remain unsolved in general. Today, safety rests on host-level approval dialogs, least-privilege server configuration, and operator discipline — all of which are practices, not guarantees. Standardization makes capability composable; it also makes failure composable, and the industry's security posture has not yet caught up with its connectivity posture.

07 The USB-C Analogy

The closest physical-world precedent is USB. Before it, peripherals came with a zoo of connectors, and compatibility was a line item on the side of the box. After standardization, the connector question disappeared and innovation moved up the stack — to the devices themselves, because anything that fit the port worked with everything. The plug got boring, and the ecosystem got interesting.

MCP aims at the same destination for tool use. If it holds, the industry stops arguing about how agents connect and starts competing on what agents do once connected. The measure of success is the same as USB's: the plumbing becomes invisible, noticed only in its absence — when a tool does not support it, the way a peripheral without a USB-C port now feels vaguely archaic.

That is the quiet promise of a protocol nobody outside engineering will ever learn to name. The flashiest demos of AI agency — the flight bookings, the automated research, the cross-system workflows — rest on unglamorous infrastructure, and infrastructure only earns that name when everyone can build on it without asking permission first.