A quiet protocol question has turned into a procurement gate. If your vendor shortlist doesn't account for it, you're buying tomorrow's integration debt today.

Two years ago, the Model Context Protocol barely came up in a vendor meeting. Now it decides shortlists.

On 12 June, CircleCI shipped an MCP server that lets AI coding assistants – Cursor, Claude Code, Windsurf, VS Code, Amazon Q Developer, and others – read its pipeline, build, log, and test data directly. No bespoke connector. No custom API glue written for each tool. An agent asks a question, and CircleCI answers in a format the agent already speaks. It was a small release in a busy week of conference announcements. It also points straight at where enterprise software buying is heading.

The question senior teams have started putting to vendors is short: "Does your platform expose its capabilities through MCP?" It has quietly joined "Does it run in our Cloud?" as a default line in the evaluation. Vendors who can't answer it cleanly are the ones now doing the explaining.

How a Protocol Went From Curiosity to Criterion

Anthropic released MCP in November 2024 as an open standard for connecting AI systems to data and tools. OpenAI adopted it in March 2025. Google DeepMind followed a month later. Microsoft and Cloudflare came on board, and in December 2025 Anthropic handed the protocol to the Agentic AI Foundation under the Linux Foundation, making it vendor-neutral and community-governed.

The adoption figures are not small. The official MCP registry held roughly 9,600 server records by late May 2026, and GitHub showed nearly 16,000 repositories tagged as MCP servers. The Python and TypeScript SDKs alone pull in around 97 million downloads a month. This is the closest thing agentic AI has to a common wire protocol – the OpenAPI of the agent era.

That changes the buying question. It stops being "will there be a standard?" and becomes "are our vendors compliant with it?" We are well past the first question.

What MCP Actually Does

Strip away the acronym and the idea is plain. Before MCP, every AI tool needed a hand-built connector for every system it touched. Ten tools and ten systems could mean up to a hundred separate integrations to build and then maintain forever. The cost climbed with every new tool you added to the mix.

MCP turns that multiplication into addition. Build one server for a system, and any compliant AI client can use it. The protocol defines a small set of building blocks: actions an agent can take, read-only context it can pull in, and reusable prompts. Build the server once, and the integration work stops scaling with the number of AI tools in play.

For a business, the payoff is less integration code to write and own, faster movement from idea to production, and the freedom to switch AI providers without rewiring every connection. The protocol is model-agnostic by design, which is exactly why it cuts vendor lock-in rather than deepening it.

Why This Is a Buying Decision, Not an Engineering Footnote

Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from under 5% at the start of the year. Forrester reckons 30% of enterprise application vendors will ship their own MCP servers. Put those two together and the conclusion is hard to dodge. The agents are arriving inside your business through the software you already buy, and they need a way to reach the data those systems hold.

If a product you buy today exposes no MCP server, your future agents can't discover or use its data. You'll be back to commissioning custom connectors, or worse, leaving that system stranded outside your agent workflows altogether.

So the procurement conversation needs sharper questions than "do you support MCP?" Three are worth writing into your evaluation template:

• Is the product MCP-compliant today, and against which version of the specification? "We support MCP" with no version attached tells you almost nothing.
• Does it act as an MCP client, a server, or both? A client consumes tools from servers; a server exposes them to clients. The answer decides how the product slots into your agent architecture.
• Which MCP servers does it ship with or integrate with natively? Native support beats "you can build it yourself" every time a budget review comes around.

A vendor who fields all three without flinching has thought about your agent roadmap. One who can't has handed you a future cost they haven't priced in.

The Part Teams Skip: Governing What the Agents Do

Here is where enthusiasm tends to outrun the planning. Every MCP server you stand up is a door into a system. An agent holding that access doesn't only read – it can act. Create the ticket. Run the pipeline. Move the data. Convenient when it goes right, and expensive when it doesn't.

This came into focus at Databricks' Data + AI Summit on 16 June. The company extended its Unity Catalog so that MCP services, models, agents, and skills are governed as first-class assets, and added a runtime gateway that applies spend limits, routing, and full tracing across all of them. The product news carried a blunt message underneath it: most organisations govern these things separately, if they govern them at all, and have little visibility into what their agents are actually doing.

That matches the production data. Stacklok's 2026 software report found 41% of surveyed software organisations already running MCP servers in limited or broad production. This is live in real businesses, not parked in a lab. Yet most enterprise AI governance frameworks were written before MCP reached that scale, so they say nothing specific about controlling it. Connecting agents to your systems without governing what they're allowed to do is how a productivity win turns into an incident report.

The Stack Nobody Designed

There's a second reason to act now. Your engineers are already assembling an agent stack, whether or not anyone signed it off. Eighty-four per cent of developers report using AI coding tools, and 51% reach for them every working day, according to this year's Stack Overflow survey of more than 49,000 respondents. They run several at once: one tool orchestrating parallel agents, a plugin running inside another, build and ticketing data piped in through MCP servers.

Nobody drew this architecture on a whiteboard. It assembled itself, tool by tool, because each piece earned its place. MCP is the connective tissue holding it all together. The choice in front of technology leaders isn't whether to have an agent stack. It's whether to govern the one you already have, or inherit its consequences later.

Q&A: Making Sense of MCP as a Buyer

Our vendor says they "support MCP." Is that enough to tick the box?
No. Ask which version of the specification they support, whether the product behaves as a client, a server, or both, and which MCP servers it ships with or connects to natively. A claim of support with no version and no detail is a marketing line, not an integration commitment.

We've already built custom API integrations. Have we wasted that effort?
Not at all. Those integrations keep working, and there's no case for ripping out something that runs. MCP changes the maths going forward by removing the need to hand-build a fresh connector for every new AI tool you adopt. Think of it as the standard you build toward next, rather than a reason to throw away what already earns its keep.

Is MCP a security risk?
The protocol itself isn't the risk. The access it grants is. Every server is a door into a system, and an agent on the other side can act, not just look. The danger is ungoverned access, and most governance frameworks predate MCP, so they don't describe the controls you now need. Treat each MCP server as a privileged integration and govern it like one.

Should we wait for the standard to settle before committing?
It has largely settled. MCP is backed by Anthropic, OpenAI, Google, and Microsoft, it sits under the Linux Foundation as a vendor-neutral standard, and it works across models. Waiting carries its own cost: while you hold off, your competitors' agents are already reaching tools that yours can't. Holding back is a decision, and it isn't a free one.

Does this matter if we're only buying software, not building our own agents?
Yes, and arguably more so. Gartner's figure of 40% of enterprise applications carrying agents by the end of 2026 means the software you buy will bring agents whether you build any yourself or not. A product with no MCP posture is a product your future agents can't fully use. The buying decision you make this quarter sets the ceiling on what your agents can reach next year.

Working Through This With Vertex Agility

The shift this article describes – from custom, point-to-point integrations to a governed agent layer connected through MCP – sits right where two of our practices meet.

Our Software Consultancy team works on the plumbing that makes this real: DevOps and CI/CD automation, microservices and API design, and custom engineering built to recognised security standards such as OWASP. That's the layer where MCP servers get built, exposed, and hardened – and where a careless implementation quietly becomes the access risk nobody owns.

Our AI Consultancy practice sits alongside it, working with teams on AI strategy, implementation, and the governance frameworks that responsible adoption at enterprise scale depends on, including the agent and access controls most organisations haven't written down yet. Keeping both disciplines under one roof means the integration work and the governance work stay joined up, which is the entire argument this article has been making.

As a delivery partner to Microsoft, AWS, Google, and Salesforce – the same vendors driving MCP adoption – we help technology leaders turn a fast-moving standard into an architecture they can actually run, across 12 delivery locations and a senior-led engineering bench.

If you want an independent read on how ready your technology operation is for agent-scale workloads, our free Future-Ready audit highlights your strengths, risks, and opportunities for acceleration in a few minutes. For a deeper conversation about your integration and governance approach, get in touch with us directly below.