MCP: the protocol war just ended without being fought
OpenAI in March, Google this week — Anthropic's MCP is now backed by all three major labs. What a boring-sounding protocol changes about enterprise AI strategy.
🔌 MCP: the protocol war just ended without being fought.
This week Demis Hassabis confirmed Gemini will support MCP — Anthropic's Model Context Protocol — calling it "rapidly becoming an open standard for the AI agentic era." That lands three weeks after OpenAI adopted it across their products. When the three labs that compete on everything agree on one thing, that thing is worth ten minutes of any leader's attention.
What MCP actually is, minus the jargon: an open standard for how an AI application connects to tools and data. A system — your CRM, your document store, your ticketing tool — runs an MCP server that describes what it offers: here are my tools, here is what each does, here is what each needs. Any MCP-speaking AI client can then discover those capabilities and call them, the same way, regardless of which model sits underneath. The analogy everyone uses is USB-C, and for once the analogy is accurate.
The gap it bridges is one anyone who has built agents knows painfully well: finding and calling the right API. Until now, connecting AI to enterprise systems meant hand-wiring every pair — this model's function-calling format to that system's API, schemas rewritten per vendor, glue code multiplying as N models × M systems. Worse, the finding half had no answer at all: the agent could only use tools a developer had explicitly wired in at build time. MCP standardises both halves — discovery (the agent can ask a system "what can I do here?" at runtime) and invocation (one calling convention everywhere). N×M integrations collapse toward N+M.
Why this deserves a place in enterprise AI strategy, not just engineering backlogs:
Integrations flip from cost to asset. An MCP server in front of your CRM is built once and works with today's model, next year's model, and the vendor you haven't chosen yet. Everyone who has preached model-swappable architecture finally has the connective tissue for it — your integration layer stops being married to your model vendor.
It creates the governance chokepoint we've been missing. When every agent reaches every system through one protocol, you get one place to enforce who may call what, one place to log every call, one place to audit. Scattered bespoke integrations never gave us that.
"Agent-ready" becomes an API strategy question. The systems that get MCP servers first become the systems agents can act on first. Deciding which internal capabilities to expose — and which explicitly not to — is this year's version of the API-first debate, and it belongs with architecture and security together, not either alone.
And the caution, because a standard is not a safety feature: MCP standardises the pipe, not the judgment. Tool descriptions are text an attacker can poison; a server exposed too broadly is a capability handed to every agent that connects; the protocol will move faster than its security patterns for a while. The right posture is the same one that has served all along — least privilege, agent permissions capped at the user's permissions, and an allowlist, not an open buffet.
The strategic read: everyone has spent two years asking "which model should we bet on?" A common protocol quietly makes that the smaller question. The bigger one — and the one your competitors are not yet asking — is which of your systems will be reachable by agents, on what terms. That answer will outlive several model generations.
A concrete exercise for your architecture council this quarter: name the five internal systems you would expose to agents first, and for each, write the permission sentence — an agent acting for user X may do exactly this, and nothing else. If writing those five sentences is hard, that difficulty is the real finding.