Twelve months ago MCP was a spec people argued about on GitHub.
It is now the default way agents reach enterprise systems — 10,000+ public servers and roughly 97M SDK downloads a month.
The wiring question is settled
That adoption curve ends the debate about whether to standardise agent-to-tool connectivity. You should, and the standard exists.
What it doesn't settle is the meaning question. MCP defines how a request travels. It says nothing about whether two agents on the same wire agree what revenue means, or whether either was entitled to ask.
Enterprise adoption splits in two
| Track | Status at most organisations |
|---|---|
| Connectivity | Largely solved, increasingly commodity |
| Comprehension and control | Barely started |
Teams that treat MCP as the finish line build a very efficient path to inconsistent answers. Teams that treat it as transport — with a governed semantic layer behind it — get agents that actually ship.
Why it became infrastructure so fast
Because the alternative was N×M integrations. Three agent frameworks, four data sources, twelve brittle connectors, and someone renames a column and three agents break at once.
MCP collapses that to one server per source. That's a real engineering win and it explains the curve.
The part to plan for now
The protocol is commoditising, which means it will stop being a differentiator within a year. What sits behind your MCP server — schema or semantics — is the decision that persists.
Expose the schema and every connecting agent infers meaning independently. Expose the semantics and they all compile through the same versioned graph, with the same proven joins and the same policy.
Same protocol. Same effort to connect. Completely different answers.
The full breakdown — the adoption data, what changed in the ecosystem, and how to plan the layer behind the server — is here:
👉 Enterprise MCP Adoption: Why the Model Context Protocol Became Infrastructure
Originally published at colrows.com/blogs/mcp-enterprise-adoption
Top comments (0)