MCP Became the Default for AI Tool Access. Here's What That Means If You're Buying an Agent.

The integration problem MCP actually solves

Before MCP, connecting an LLM to your own systems meant writing bespoke glue code for every combination of model and tool. If you wanted Claude to query your database and also wanted GPT-4 to do the same thing, you wrote two integrations, because each model vendor had its own function-calling format, and every data source — Postgres, Slack, a filesystem, an internal API — needed its own adapter on top of that. Add a second tool and a third model and the integration count grows as N models times M tools. Every team building agentic features was solving the same wiring problem from scratch, usually badly, usually with integration code that lived nowhere near the model's actual reasoning about when to use the tool.

Anthropic published the Model Context Protocol as an open spec in November 2024 to collapse that grid into a line: one client-server protocol that any model can speak to any tool, provided both sides implement MCP once. A database gets one MCP server. A model host gets one MCP client. From there, any compliant model can use any compliant tool without either side knowing about the other in advance. That's the whole pitch, and it's the same pitch USB-C made for cables — not a smarter connector, just one everyone agreed to use.

Why it actually caught on

Plenty of "open standards" from a single AI lab go nowhere. MCP didn't, and the adoption curve is the actual story. OpenAI adopted MCP across its products in March 2025, including support in the ChatGPT desktop app, and extended it to ChatGPT's apps platform in September 2025. Google DeepMind built MCP support into the Gemini API in mid-2025. Microsoft and Salesforce shipped support inside the same rough window. In December 2025, Anthropic handed governance of the spec to a new Agentic AI Foundation under the Linux Foundation, with Anthropic, Block, and OpenAI as co-founders and AWS, Google, Microsoft, Cloudflare, and Bloomberg joining as platinum members — the point at which a protocol stops being "Anthropic's thing" and becomes shared infrastructure nobody can unilaterally change.

That matters for a buyer, not just a spec-reader. If a vendor pitches you an "agentic AI system," MCP is very likely the plumbing underneath it now, whether they say so or not. Knowing that changes what you should ask them.

What you're actually buying when a vendor says "MCP-based"

MCP standardizes three things a model can get from a server: tools (functions the model can call — send an email, run a query, create a ticket), resources (read-only context the model can pull in — a document, a schema, a log), and prompts (reusable instruction templates the server exposes). The protocol doesn't make the model smarter, doesn't make its tool choices more reliable, and doesn't validate that the tool it's calling does what its description claims. It's a wire format, not a judgment layer. That last part is where the risk actually lives, and it's the part sales decks tend to skip.

The failure mode nobody puts in the pitch

An MCP server's tool description is plain text the model reads to decide when and how to call that tool — and it's an unsanitized input. Security researchers (Invariant Labs first documented this in 2025) demonstrated Tool Poisoning Attacks: a malicious or compromised MCP server embeds hidden instructions inside what looks like ordinary help text for a tool, and a connected agent will follow those instructions because it has no way to distinguish "developer's description of what this tool does" from "attacker's instructions to the model reading this." Related variants include "MCP Rug Pulls," where a server's tool description changes after a user has already approved it, and shadowing attacks that hijack one tool's behavior through a second, unrelated tool's description.

This isn't theoretical. CVE-2025-49596 was a remote-code-execution vulnerability in the official MCP Inspector tool, caused by accepting unverified inputs. CVE-2025-54136 ("MCPoison") exploited the fact that some IDEs bind a user's trust approval to an MCP server's name rather than its actual contents, so a server could be swapped out after approval without triggering a new review. Independent audits of thousands of public MCP servers have found large percentages vulnerable to command injection and path traversal through file-handling tools. None of this means MCP is a bad idea — it means MCP moved the trust boundary from "which model do I trust" to "which server, and whose tool descriptions, is my agent reading," and most teams adopting agents haven't updated their threat model to match.

What this means if you're evaluating an agent vendor

If a vendor tells you their product uses MCP to connect to your systems, the right follow-up questions aren't about the protocol — they're about what sits around it: Where do tool descriptions come from, and are they reviewed before an agent can act on them? Does your approval process re-verify a server when its tools change, or only on first connection? Is the MCP server pulling from a third party you don't control, and if that party is compromised, what can the agent be tricked into doing on your systems? A vendor with good answers here is telling you they've actually operated agents in production, not just wired one up for a demo.

MCP is the right default now — it's not worth avoiding, and rebuilding bespoke integrations instead of using it would be its own kind of waste. The mistake is treating "we use MCP" as a security answer instead of an architecture choice that still needs one.