What Is MCP (Model Context Protocol), Really

Every explainer wants to hand you the same line: MCP is “USB-C for AI.” It is a fine analogy for a dinner party and a useless one if you actually have to build something. So let me skip it. MCP, the Model Context Protocol, is an open standard Anthropic released in November 2024 that lets any AI application connect to any tool or data source through one shared protocol instead of a bespoke integration for each pairing.^[1] That is the whole thing. What makes it interesting is the specific problem it kills, and the specific ways it can bite you.

The way I think about it, MCP is the fix for a math problem that has haunted software integration since long before AI. Engineers call it the N×M problem, and once you see it you cannot unsee it.

The N×M Problem, and Why It Is the Real Story

Picture the world right before MCP. You have N AI applications: ChatGPT, Claude, a Cursor-style IDE, some internal agent your company built. And you have M things you want them to reach: GitHub, Postgres, Slack, Google Drive, your internal ticketing system. If every app needs custom glue code for every tool, you are on the hook for N times M integrations. Ten apps and ten tools is a hundred connectors, each one written, tested, and maintained by someone who would rather be doing anything else.

That multiplication is where integration efforts go to die. It is the same reason we standardized on HTTP for the web and SQL for databases. A shared protocol turns multiplication into addition. Each AI app implements MCP once. Each tool exposes an MCP server once. Now you are at N plus M. Ten plus ten is twenty. Write your GitHub server one time and every MCP-speaking app in the world can use it, forever, without you lifting a finger.

This is not a novel insight. It is the oldest idea in systems design. What is new is that AI models finally got good enough at tool use that the payoff was worth the coordination cost, and one vendor with enough gravity to make the first move actually made it.

Host, Client, Server: What Each One Actually Is

The three-word vocabulary trips people up because two of the words sound like the same thing. Here is the honest version, from an engineer's seat.^[2]

• Host. The AI application the user actually touches. Claude Desktop, an IDE with an AI panel, a customer support agent. The host holds the large language model and orchestrates everything. It is the thing that decides, this task needs the filesystem, let me go get it.
• Client. This is the part people miss. A client is not a separate app. It lives inside the host, and its only job is to manage one connection to one server. Strict 1:1. If your host needs to talk to three servers, it spins up three clients. The client is a connector, not a program you install.
• Server. The external program that actually exposes capabilities. A GitHub server, a Postgres server, a filesystem server. It can run locally on your machine or remotely behind an API. The server is where the useful stuff lives.

So the shape is: one host, many clients inside it, each client wired to exactly one server. That fan-out is what lets a single agent reach your local files, your database, and a web API in the same breath. Under the hood it all rides on JSON-RPC 2.0, a boring, well-understood remote-procedure-call format, over one of two transports: stdio for local same-machine servers, and Streamable HTTP for remote ones.^[2] Nothing exotic. That is a feature, not a knock.

The Three Primitives: Tools, Resources, Prompts

A server exposes capabilities through exactly three primitives, and the distinction between them is the part worth getting right.^[3]

• Tools. Functions the model can invoke to do something. Send an email, run a query, open a pull request. Tools are what give a model the ability to act in the world instead of just describing it. This is the primitive everyone actually uses, to the point where most people think MCP is only tools.
• Resources. Read-only data the server offers up as context. A file, a database schema, a config, each addressed by a URI like a web page has a URL. The model pulls a resource in to read it, not to trigger side effects. Think of resources as the server saying, here is what I know, versus tools saying, here is what I can do.
• Prompts. Reusable templates a server publishes so common tasks stay consistent. A code-review prompt, a bug-report template. This is the least-used of the three, and honestly it is the one whose value is still being argued over.

When a client connects, it asks the server what it has, and the server lists its tools, resources, and prompts. That discovery step is why you can drop a new server into a host and it just works, no hardcoding. The capability negotiation at connection time is the quiet part that makes the whole thing feel plug-and-play.

Where It Breaks: The Trust Boundary Is the Whole Problem

Here is the part the marketing skips, and it is the part I would not deploy without understanding. MCP's security model is genuinely hard, and not because the code is buggy. The trouble is structural.

When your agent runs, the user's prompt, the developer's system message, and a tool description written by some third-party MCP server all collapse into the same context window. The model cannot tell which tokens came from you and which came from a stranger's server. Whoever writes into that window is writing the model's instructions. Simon Willison flagged this in April 2025 in plain terms: an LLM will trust anything that can send it convincing-sounding tokens.^[4] That is the confused-deputy problem, and MCP hands it a bigger surface.

This shows up in concrete attacks. In tool poisoning, a malicious server hides instructions inside a tool description that the user never sees but the model reads and obeys. In a rug pull, a server passes your review looking harmless, then mutates its own tool definitions after you have approved it. CVE-2025-54136, dubbed MCPoison and found by Check Point, demonstrated exactly this against config files: commit a benign MCP config, get it approved once, then swap the payload later.^[5] You audited Day 1. By Day 7 your keys are somewhere else.

None of this makes MCP unusable. It makes MCP a thing you sandbox, scope with least privilege, and treat with the same paranoia you would give any dependency that can touch production. The protocol itself is not going to save you here. That is on the host implementation and on you.

Real Standard, or Anthropic-Shaped Hype?

Fair question, and for the first few months it was a legitimate one. A protocol released by one AI lab, adopted mostly inside that lab's own products, is a proprietary format wearing an open-source costume. So what changed my mind?

The competitors adopted it, and not quietly. OpenAI signed on in March 2025, with Sam Altman saying flatly “people love MCP and we are excited to add support across our products,” shipping it first in the Agents SDK.^[6] Think about how unusual that is. OpenAI adopted a standard built by Anthropic, its sharpest rival. Google and Microsoft followed within months, with Microsoft wiring it into Windows 11 and Copilot.^[1] When your three biggest competitors all implement your protocol rather than fork it or fight it, the network effect has already won.

Then came the governance move that actually seals it. In December 2025 Anthropic 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.^[7] That is the difference between a spec one company can change on a whim and infrastructure a neutral body stewards. The Linux Foundation has done this before, for Kubernetes, for a hundred other load-bearing projects. Handing MCP over is Anthropic saying the standard is bigger than its authorship, which is exactly what you want to see before you build on something.

The numbers back the vibe. By late 2025 there were more than 10,000 public MCP servers and 97 million monthly SDK downloads across Python and TypeScript.^[7] You do not fake that. That is real adoption, real developers, real production usage.

My Honest Verdict

MCP is a real standard now. Not perfect, not finished, but real. It solves an actual problem, the N×M integration mess, with the oldest and most reliable trick in systems design, and it has the cross-vendor buy-in and neutral governance that separate a standard from a vendor's API. If you are building anything where an AI needs to reach the outside world, learning MCP is no longer optional, in the same way you learned HTTP without asking whether it would stick.

But go in clear-eyed about the security. The trust boundary is not a rough edge that will get sanded down in the next release. It is inherent in letting a model act on context it did not author. Sandbox your servers, scope their permissions, and remember that an approved server is not a trusted one forever. The protocol won the interoperability fight. The safety fight is still yours to lose. For more on how models are getting wired into real workflows, see our take on Claude Code routines and how tool-using agents actually run.