Model Context Protocol (MCP), Explained

The Model Context Protocol (MCP) is an open standard that defines a single way for AI applications to connect to external tools and data sources. Introduced by Anthropic in late 2024 and since adopted across the industry, it’s best understood as the USB-C port for AI: one connector, any device.

It killed real busywork. Two years ago, connecting an AI model to a tool — your database, your issue tracker, your file system — meant writing a bespoke integration for every model-and-tool pairing. MCP replaced all of those with one protocol.

The problem MCP solves

Before MCP, integrations were an N×M mess. If you had three AI apps and ten tools you wanted them to use, you faced thirty custom integrations — each one a slightly different shim with its own auth, schema, and quirks. Swap a model and your integrations might break. Add a tool and you’d write it into every app by hand.

MCP turns that N×M problem into N+M. Build a tool once as an MCP server, and any MCP-aware client can use it. Adopt a new model, and it inherits every server you’ve already wired up. The integration is written against the protocol, not against a specific vendor.

How MCP works

MCP follows a straightforward client–server design, speaking JSON-RPC over a defined transport.

• Host / client — the AI application: a chat app, an IDE assistant, an agent runtime. It holds the model and opens connections to one or more servers.
• Server — a small program that exposes capabilities to the client. A server might wrap the GitHub API, a Postgres database, a Slack workspace, or your local files.

Servers offer three kinds of things:

Primitive	What it is	Example
Tools	Actions the model can call	”create an issue,” “run a query”
Resources	Read-only data the model can pull in	a file’s contents, a record
Prompts	Reusable prompt templates a user can invoke	”summarize this PR”

Connections run over a transport — typically standard input/output for a local server, or streamable HTTP for a remote one. Either way, the model sees a clean menu of tools and decides when to call them; the client executes the call and feeds the result back.

Why it took off

Standards usually win for boring reasons, and MCP is no exception:

• It’s open. No single vendor owns it, so tool authors and model providers could adopt it without betting on one company.
• It’s model-agnostic. Your tool servers don’t care which model is driving — switch from one provider to another and the servers keep working.
• It rode the agent wave. As AI moved from chat to autonomous agents that actually do things, a standard way to grant them tools became essential. MCP arrived at exactly the right moment.

The result is a fast-growing ecosystem: editors, agent frameworks, and SaaS products now ship MCP support, and there are public registries of ready-made servers for common systems.

That openness became formal governance in December 2025, when Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation. The specification is now stewarded by a neutral body rather than any single vendor — a big part of why competitors as varied as OpenAI, Google, and Microsoft are comfortable shipping native support for a protocol their rival created.

The security caveat

Handing a model real tools means handing it real power, and MCP doesn’t change the fundamentals of that risk. Two things deserve attention:

• Tool permissions. An MCP server can do whatever its underlying API allows. Scope credentials tightly and prefer read-only access until you need more.
• Prompt injection through data. If a model reads a resource (a web page, an email, a file) that contains hidden instructions, those instructions can try to hijack its behavior. Treat tool output as untrusted input, keep a human in the loop for destructive actions, and don’t let an agent both read arbitrary content and wield dangerous tools without guardrails.

MCP vs. RAG

People sometimes conflate MCP with retrieval-augmented generation. They’re complementary. RAG is about fetching relevant knowledge to ground a model’s answer. MCP is about giving a model a standard interface to tools and data — which can include a retrieval system, but also actions like sending a message or editing a file. RAG feeds the model; MCP lets it reach out.

MCP vs ARD and A2A

MCP is no longer the only acronym in the agent-infrastructure stack, and the easiest way to keep the contenders straight is by layer.

• MCP is the connection layer: how an agent talks to a tool or data source it already knows about.
• ARD (Agentic Resource Discovery) sits one level up, at the discovery layer: how an agent finds out which tools, data, and other agents exist across a company’s software estate in the first place. It’s built around machine-readable ai-catalog.json registries and backed by a coalition of enterprise heavyweights — Google, Microsoft, Salesforce, Snowflake, and ServiceNow among them — and, notably, not by Anthropic or OpenAI. We’ve broken down the ARD coalition and how it compares to MCP separately.
• A2A is Google’s agent-to-agent protocol: how two agents coordinate with each other, rather than with tools.

In principle the three are complementary — discover with ARD, connect with MCP, coordinate over A2A. In practice they’re championed by different coalitions with different commercial interests, and whether the stack converges on clean layers or fragments into rival ones is among the bigger open questions in enterprise AI.

The takeaway

MCP is the plumbing that makes “an AI that can actually use your stuff” practical and portable. If you’re building anything agentic, start by checking whether the tools you need already have an MCP server — increasingly, they do — and lean on the standard instead of hand-rolling integrations. For how the most capable models put these tools to work, see our breakdown of Claude Fable 5.