Model Context Protocol (MCP): What It Actually Solved, and Where the Hype Outruns It

Eighteen months ago, wiring an AI model into your own systems was a tax everyone paid separately. Connecting a chatbot to a Postgres database, a Slack workspace, and a Google Drive folder meant three separate integrations, each with its own auth and its own quiet way of breaking. The math was the real problem: every new model multiplied against every new data source, so a team with four AI tools and ten internal systems faced something like forty bespoke connectors, most of that glue code thrown away the moment they switched providers. The Model Context Protocol set out to collapse that grid into one standard. The short answer on whether it worked: it did, and decisively. The more interesting part is what that win actually buys you and what it quietly leaves on your plate, because the harder jobs MCP was supposed to retire — knowing which tools to trust, and what they cost to run — mostly got handed back.

The boring victory: a standard that actually stuck

Anthropic open-sourced MCP on November 25, 2024, framing it as a universal connector — its own analogy is a USB-C port for AI applications, one standard plug instead of a drawer full of adapters. Plenty of "standards" get announced with that kind of confidence and then quietly die because nobody else adopts them. MCP did not. Within months the people who would normally build a competing protocol instead signed on to this one. In March 2025 OpenAI adopted its rival's standard, with Sam Altman saying support would arrive across OpenAI's products including the ChatGPT desktop app, and Google committed to it weeks later, with DeepMind's Demis Hassabis saying MCP support would come to Gemini. Editors and agents fell in line too: Claude, ChatGPT, VS Code, Cursor, and others all talk to the same servers.

The part that signals real maturity, rather than a hype cycle, came at the end of 2025. On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation it co-founded with Block and OpenAI, where MCP joined Block's goose and OpenAI's AGENTS.md as founding projects. By then MCP had grown into one of the fastest-moving open-source projects in AI — Anthropic put it at roughly 97 million SDK downloads a month and about 10,000 active servers. Handing a project at that scale to a neutral foundation is the unglamorous move that tells you the creator wants it to outlive their own product strategy — the same instinct, in a different corner of the toolchain, behind keeping a build tool vendor-neutral after an acquisition. A protocol that a direct competitor adopts and that its author then gives away has stopped being one company's marketing and become shared infrastructure, and infrastructure winning is supposed to be dull.

What it actually standardized — and what it didn't

It helps to be precise about what MCP is, because the layperson framing ("AI can now plug into everything") hides where the real engineering sits. Underneath the USB-C metaphor, MCP is a fairly conservative piece of design: a client-server protocol carried over JSON-RPC 2.0. There is nothing exotic in the wire format; the cleverness is in the shape of the agreement it defines.

That agreement defines a client-server split. Your AI application — Claude, an IDE, a terminal agent — is the host that runs clients; the thing exposing your data or tools is the server. A server can offer three kinds of capability: tools the model can call to take an action, resources it can read for context, and prompts that package a reusable workflow. A filesystem server hands the model a read_file tool and exposes a directory as a resource; a GitHub server exposes issues and pull requests and a tool to comment on them. Build that server once and any MCP-aware client can use it, which is the whole point. This is exactly why the terminal-based AI coding agents converged on it so fast: instead of each tool maintaining its own plugin format, they all read from the same server ecosystem, and a server someone wrote for one of them works in the others. The network effect compounds quickly — every new server makes every client more capable, and every new client makes it more worthwhile to publish a server.

What MCP standardized, then, is connection and capability description. What it did not standardize is judgment. The protocol gives a model a clean, uniform way to discover that a tool exists and to call it. It says almost nothing, by itself, about whether that tool should be trusted, what it is allowed to touch, or how to tell a legitimate server from a hostile one wearing the same interface. That is a boundary of the spec rather than a defect in it, and it is the part the marketing tends to skip over.

Where the hype runs ahead: the trust problem

The gap MCP leaves is trust. It standardized how a tool is described and called; it never standardized how anyone decides a tool is safe to run. The protocol does not make a client verify what a tool's description actually says, and as Invariant Labs documented, early clients often showed the user a simplified tool while the model acted on the full, unvetted text. That gap is where the now-standard attack lives: tool poisoning. A server's tool *descriptions* — the text the model reads to decide what a tool does — can hide instructions the user never sees, so a tool that looks like a harmless calculator can quietly tell the model to read a secret and send it somewhere. In April 2025 Invariant Labs demonstrated the attack in practice, poisoning a tool description so that Cursor read a user's SSH private key and leaked it, and showing "shadowing" attacks in which a malicious server quietly rewrites how a trusted tool behaves. OWASP now catalogs MCP tool poisoning as a recognized attack pattern. The risk does not stop at a single bad server, either: a server can behave at install time and turn malicious in a later update — a "rug pull" — or impersonate a trusted tool to quietly redirect what it does, and by 2026 the pattern had its own academic threat models mapping tool-description injection across agent platforms. The root cause is mundane and stubborn: the model treats tool text as trusted context, and nothing in the protocol forces anyone to check it.

None of this means MCP is unsafe to use, and that distinction matters. The real risk is quieter: MCP moved the hard problem rather than eliminating it. Before, the friction of writing every integration by hand was, accidentally, a security speed bump — you had to understand each connection well enough to build it. A protocol that makes plugging in a new server take thirty seconds also makes plugging in a *malicious* server take thirty seconds. Picture the realistic version: a developer browsing a public registry of community MCP servers, finding one that promises to summarize Jira tickets, and adding it to a coding agent that already has read access to a private repo and a shell. Nothing about that flow forces them to read the server's tool descriptions, and nothing warns them if those descriptions quietly instruct the model to do more than summarize. That is the part the connect-everything pitch leaves out: the discipline of treating a new server the way a careful admin treats a new browser extension — assume the metadata is hostile until you verify what the thing can actually reach, and grant it the narrowest access that still does the job. It is unglamorous work, and it does not come bundled with the protocol.

There is a cost dimension here too that rarely makes the keynote. Every tool a model can reach is more context it can pull in and more calls it can make, and tokens are the meter the whole industry now runs on. An agent with access to a dozen MCP servers is an agent that can quietly run up a bill exploring them, which is why the same companies racing to connect everything are also rationing how much their AI agents are allowed to do. Every server you connect widens both what the agent can do and what it can spend, and most teams notice the spending later than the capability.

The considered take

MCP won the thing it set out to win, and that victory is genuine and durable: there is now one good answer to "how does this AI talk to that system," and the fragmented integration era is closing. But a standard winning is an infrastructure story, and infrastructure is plumbing. MCP standardized the connections, the capability descriptions, and the discovery; it left the two things that actually decide whether an agent is useful or dangerous — trust and cost — with whoever runs it. The sensible posture in 2026 is to learn MCP because it is the standard and it is not going away, and to read any product that promises "your agent, connected to everything" as a starting point rather than a finished safety story. The protocol is the easy part. Deciding which servers earn a place in your model's context window is the part that still takes a human.

The boring victory: a standard that actually stuck

What it actually standardized — and what it didn't

Where the hype runs ahead: the trust problem

The considered take

Source links