‘MCP-Ready’ Is Becoming a Procurement Question. Here’s What It Should Actually Mean.

Every AI vendor says they’re MCP-ready. Very few of them can tell you what that means.

The term went from nowhere to standard pitch-deck furniture in about a year. Ours included, to be fair. Anthropic published the Model Context Protocol as an open standard in late 2024; by March 2025 OpenAI had adopted it, Google’s DeepMind followed weeks later, and by the end of 2025 there were more than 16,000 MCP servers in the wild and Anthropic had handed the protocol to a Linux Foundation body backed by Google, Microsoft, AWS, and OpenAI (MCP anniversary, The New Stack). That’s genuine consolidation, not hype. But like every label that spreads that fast, the term has outrun its own definition. “MCP-ready” now does the job “cloud-native” did a decade ago: a box buyers tick without a shared sense of what they’re actually buying.

The gap matters. A genuinely MCP-ready system and one that bolted a single connector onto a demo are the difference between an AI deployment you can govern and one you can’t. If you’re evaluating agentic AI for production, it’s worth getting precise before the word lands in a contract.

What MCP actually is

The Model Context Protocol solves a specific, unglamorous problem: connecting AI models to the tools, data, and systems they need to do real work.

Without a standard, every connection between an agent and one of your systems is bespoke glue code. An agent that touches your CRM, your data warehouse, and your ticketing system needs three custom integrations, each maintained separately, each its own place for things to break. Multiply that across every agent and every system and you get integration sprawl that nobody owns and everybody pays for.

MCP standardizes that layer. A capability is exposed once, as an MCP server, and any MCP-compatible client can use it. The server publishes the tools a model can call and the resources it can read, through one defined interface, over a standard transport. Write the connector once, reuse it everywhere.

Think of what the shipping container did to freight. Before it, cargo was loaded piece by piece, and every ship, crane, port, and truck handled it its own way. The container standardized the interface, not the contents. Any port could move any box, and what went inside stayed the owner’s business. MCP is that container for the connections between AI systems and your stack. The interface is standard. What you choose to expose through it is not.

Why this became a buyer’s problem, not just an engineer’s

For a while, MCP was an implementation detail. It’s moving up the stack into procurement for four reasons, and each maps to a real risk on the buyer’s side of the table.

Lock-in. Proprietary tool-calling formats tie you to one model vendor. If your agent’s integrations are written against a single provider’s interface, switching models later means rebuilding them. An MCP layer keeps the integration surface model-agnostic, so the model becomes a component you can swap rather than a foundation you’re stuck on. Given how fast the frontier reshuffles, that optionality has real money attached to it.

Governance. A standardized layer is a single place to put the controls auditors and security teams ask for. Access scoping, authentication, and logging live at the MCP layer instead of being scattered across a dozen custom integrations with a dozen different conventions. One chokepoint you can reason about beats many you can’t.

Security. This is where it matters most, and where our team spends a lot of its time. I’ll come back to it, because the standard cuts both ways and the marketing never mentions the second edge.

Capability adoption. The agent ecosystem is consolidating around standards faster than most internal roadmaps move. Systems built MCP-ready can adopt new tools without re-plumbing. Systems that aren’t keep paying the integration tax every time the landscape shifts, and it shifts every quarter.

The part the pitch leaves out: a standard is also a bigger target

Here’s the honest version of the security argument, the one that doesn’t fit on a slide.

Consolidating your integrations onto one standard gives you a coherent attack surface to assess instead of a moving target. That’s real, and it’s good. But the same move concentrates authority. One MCP server can sit in front of your most sensitive systems, and the agent trusts what that server tells it. When researchers threat-modeled the ecosystem, more than 30% of over 1,800 deployed MCP servers had at least one exploitable vulnerability (MDPI).

The nastiest class is tool poisoning. An MCP server describes its tools to the model in plain language, and that description is attacker-controlled prompt context with no sanitization and no provenance. Invariant Labs demonstrated it in early 2025; it now has its own OWASP entry and its own CVEs, including MCPoiso. Supply chain makes it worse: one popular package, postmark-mcp, shipped fifteen clean versions before a later release quietly added code to exfiltrate every email the agent processed. And when a benchmark throws poisoned tool outputs at the strongest commercial agents, they take the bait roughly half the time.

None of this means MCP is a bad bet. The NSA and CISA published design guidance for exactly this surface in 2026, which is the clearest signal yet that it’s here to stay (NSA/CISA). It means “MCP-ready” is an architecture claim, not a security claim, and a vendor who treats the two as the same word is the one to worry about. Standardizing doesn’t secure your system. It just tells you where to point the testing.

What “MCP-ready” should mean in a vendor review

When a vendor says they’re MCP-ready, the claim should survive a few direct questions. Here’s what we’d want answered before treating it as real:

Are capabilities exposed through MCP servers, or is there a single connector behind the label? One integration doesn’t make an architecture. Ask how many of the system’s tools and data sources are actually reached this way.

Is there an access-control layer? Not every agent should reach every tool. Least privilege should be enforceable at the MCP layer, and the vendor should be able to show you how scopes are defined and assigned.

Is the layer observable? When an agent calls a tool, can you reconstruct what it called, with what inputs, and why? If the MCP surface is a black box, your audit trail has a hole in it.

Is it genuinely model-agnostic? Confirm the integrations aren’t quietly written against one provider’s proprietary format with MCP as a thin wrapper. The portability is the entire point.

Has the MCP surface been security-tested? A standard interface that exposes your systems to an autonomous agent is a surface worth attacking, by someone whose job is to break it, before someone else does it for free.

Where we land on it

We build MCP-ready architectures because the alternative is integration debt that compounds every quarter, and because a standardized layer is one we can actually secure and our clients can actually govern. But the term is doing a lot of marketing work right now, and not all of it is earned. The questions above are the ones we’d ask a vendor, and the ones we expect to be asked about our own work.

If you’re weighing an agentic AI investment and want to know whether the architecture under it is genuinely MCP-ready or just labelled that way, our engineering team runs architecture reviews that answer exactly that. Bring us the system and we’ll tell you where it stands, including the second edge of the standard that the pitch deck skipped.