The Protocol That's Quietly Becoming the TCP/IP of AI Agents
Every major technology shift eventually produces a plumbing layer that nobody notices until it's everywhere. For AI agents, that layer has arrived.
The internet as most people know it did not emerge from a single brilliant breakthrough. It was assembled from unglamorous protocols — TCP/IP, HTTP, SMTP — that nobody celebrated at the time but that every piece of connected infrastructure eventually had to speak. The companies that shaped the web earliest were the ones that grasped this dynamic first: build on the right plumbing, and your application inherits the entire network. A version of that same logic is now playing out in artificial intelligence, and the protocol at its center is one that most people outside the developer community have never heard of. It is called Model Context Protocol, and by most measures it has already won.
Why Protocols Matter More Than the Models That Spawn Them
History is consistent on this point: in platform technology, the companies that created the winning protocol rarely captured the most value from it. TCP/IP was an academic project. HTTP came out of a physics lab. Linux emerged from a Finnish student's weekend project. In each case, the inventors created the plumbing and a generation of infrastructure companies built on top of it — some of those companies, not the protocol authors, became the defining businesses of the internet era.
The same principle applies to AI agents, and it has implications both for enterprise buyers deciding how to build their AI stack and for investors looking for durable positions in the AI infrastructure market. The frontier model race — the contest between Anthropic, OpenAI, Google, and others to publish the most capable AI — captures the most attention and the most venture capital. But the value that compounds over the longest horizon tends to form in the layers underneath the models: the connectivity standards, the orchestration frameworks, the observability tools, and the access gateways that make AI usable at production scale.
What MCP Actually Does — and Why the Problem Needed Solving
Before MCP, connecting an AI model to the real world was a custom engineering problem every team solved independently. Each data source needed a bespoke connector. Each tool integration required its own wrapper code. Each external API had to be hand-wired, documented internally, and maintained by someone who typically had a dozen other things to do. The result was a fragmented landscape of one-off integrations that made enterprise AI deployment expensive to build and brittle to maintain — a tax on ambition that bore no relationship to the actual value of the intelligence layer being connected.
Anthropic released Model Context Protocol as an open standard in November 2024. The technical architecture is straightforward: MCP-compatible servers expose a standardized interface; AI model clients and agent frameworks connect to those servers through a common protocol layer. What it accomplishes is functionally similar to what the USB standard did for peripherals — a single interface that eliminates the bespoke wiring problem entirely. Once a tool speaks MCP, it works with any MCP-compatible client without further negotiation. Once an agent runtime supports MCP, it can connect to any MCP-compatible server without custom integration work.
The Rival That Said Yes
What made MCP's trajectory unusual was not the technical design — it was the competitive dynamics around adoption. Open standards typically emerge from industry consortia where no single participant dominates, or from platform operators with enough market leverage to make adoption effectively mandatory. MCP did neither. Anthropic released it unilaterally, as an open-source specification, and bet on ecosystem gravity rather than market power. The bet was large because Anthropic was asking competitors to adopt a standard it had written, named, and hosted.
The inflection point arrived when OpenAI — Anthropic's most direct competitor in the frontier model market — formally announced support for MCP. That single decision resolved the coordination problem that typically slows protocol adoption for years. A connectivity standard supported by competing model providers at both ends of the market is no longer just a specification; it is the working assumption that tool builders and enterprise buyers are forced to plan around. Every major developer tool followed. Enterprise software vendors began shipping MCP interfaces. The ecosystem became self-reinforcing faster than most comparable standards transitions, because the cost of not participating grew faster than the cost of joining.
The Protocol Adoption Model
Protocol adoption follows a logic similar to other network effects: the more participants on both sides, the more valuable the standard becomes for everyone. MCP's cross-vendor support created a self-reinforcing cycle on both the server side — tool providers — and the client side — agent runtimes and developer environments. Tool providers that built MCP servers could reach every agent runtime simultaneously, making MCP the obvious place to focus integration work. Agent frameworks that supported MCP could connect to the entire growing library of MCP-compatible tools without custom effort. Every new server made MCP more valuable for client developers; every new client made it more valuable for server authors.
The practical consequence for the enterprise AI market is a library of MCP-compatible integrations spanning productivity suites, CRM systems, data warehouses, development environments, monitoring platforms, and external APIs. For a developer building an agent, MCP represents the difference between spending weeks on integration plumbing and spending hours on it. That productivity differential compounds: developers who build on MCP ship faster, which means they continue building on MCP, which means more tooling arrives MCP-first, which means the next developer faces an even stronger ecosystem pull in the same direction. This self-reinforcing cycle is the same mechanism behind why agentic loop costs scale unexpectedly at production volume — once a standard dictates the architecture, the economics of every decision built on top of it are pulled along with it.
What This Means for Enterprise Architecture
For enterprise buyers, MCP's dominance cuts in two directions simultaneously. The clear benefit is a genuine reduction in the integration overhead that has historically made enterprise AI deployment slow and expensive. A company deploying agents across its internal tools no longer needs to negotiate custom connectors for each data source. It assembles a stack of MCP-compatible servers, connects them through a compliant agent client, and inherits interoperability as a baseline condition rather than an engineering achievement. That represents meaningful cost reduction and real acceleration in time-to-deployment for AI projects that previously spent their first months on plumbing rather than on outcomes.
The less obvious implication is that new dependencies are forming one layer above the protocol. MCP defines connectivity; it does not define discovery, orchestration, access control, or observability. Those concerns are being addressed by a new generation of infrastructure companies building on top of the standard — registries that help agents find and evaluate available tools, orchestration platforms that manage multi-agent tool use at scale, security gateways that enforce governance policies on agent API calls. As the analysis of why the AI moat now sits above the model layer makes clear, the orchestration stack is precisely where durable competitive advantage is forming — and MCP is the connectivity substrate that makes that stack possible. These are the layers where new lock-in risks accumulate. An enterprise that standardizes on a particular MCP registry or orchestration platform may find that the switching cost it eliminated at the integration layer has re-formed one tier up — just as the software-as-a-service era showed that cloud portability at the infrastructure layer did not prevent deep lock-in at the application layer.
The Investment Thesis Around an Open Standard
The investment case around MCP is not, in any direct sense, about Anthropic. The company does not charge for the protocol, and it derives no direct revenue from its adoption. The opportunity — as it always is when a protocol achieves dominant adoption — is in the infrastructure that emerges to serve the ecosystem around it. The companies that built enduring businesses around previous protocol standards were generally not the ones who wrote the specification. They were the ones who solved the hard operational problems the spec deliberately left unanswered.
Platform economics suggest that a few of these positions will become extremely defensible over the medium term. The most likely winners are companies that occupy chokepoints: the registry where agents discover tools, the gateway that enforces security policy, the observability layer that gives enterprises visibility into agent behavior at scale. These are problems that individual enterprises cannot solve well in isolation, that benefit from network scale across many customers, and that become stickier the more deeply they are integrated into production systems. The analogy from the web era is not the search engines — it is the CDN providers, the certificate authorities, the monitoring platforms: businesses nobody thinks of as glamorous but that become load-bearing infrastructure inside every production deployment.
Risks
Three risks stand out. The first is protocol fragmentation — the same risk that plagued USB before standards bodies consolidated the specification. If different vendors begin extending MCP in incompatible directions, the interoperability guarantees that make the standard valuable break down. Versioning discipline and backward compatibility are not automatic in a fast-moving open-source project, and fragmentation is how protocol wins become protocol messes that burn the enterprises who bet on them early.
The second risk is platform defection by a sufficiently dominant model provider. If a major AI company decides that a proprietary tool interface gives it a meaningful competitive advantage over MCP, it could invest in its own tooling standard and pull enough market share to create a divided ecosystem. This risk is real but meaningfully reduced by OpenAI's decision to adopt MCP — defecting from a standard you recently and publicly endorsed carries a credibility cost that reduces the likelihood of casual reversal.
The third risk is regulatory entanglement. As AI agents are used in increasingly consequential enterprise contexts — financial decisions, legal workflows, healthcare operations — governments are beginning to focus on how agent tool access is invoked, logged, and audited. An unexpected compliance requirement around agent connectivity could reshape the architecture in ways that neither the current MCP specification nor the tooling built on top of it is designed to accommodate quickly.
The Bottom Line
MCP has already done the hardest thing a protocol needs to do: it achieved cross-competitor adoption in a high-stakes market where every participant had reasons to prefer a proprietary alternative. That achievement does not guarantee its permanence, but it does establish it as the working assumption for AI infrastructure planning in 2026 and likely for several years beyond. For founders, the practical implication is clear — MCP compatibility is no longer a differentiator; it is table stakes for anything touching the agent ecosystem. For operators deploying AI in the enterprise, the protocol reduces integration friction but does not eliminate the architectural decisions about what to build one layer above it. And for investors, the value is not in the protocol itself — it is in the new infrastructure forming around it, in the unglamorous but load-bearing positions that every dominant standard eventually creates.
The pattern is familiar. What changes is the speed. The plumbing is being poured now, in real time, and the companies that understand where the chokepoints are forming will be the ones who look obvious in retrospect.
References
- Model Context Protocol specification and documentation — modelcontextprotocol.io
- Anthropic's MCP announcement — anthropic.com/news/model-context-protocol
- MCP GitHub organization and open-source repositories — github.com/modelcontextprotocol
Related
What is Model Context Protocol (MCP)?+
MCP is an open protocol developed by Anthropic that standardizes how AI models and agents connect to external tools, APIs, and data sources. It defines a common interface so any AI client can communicate with any MCP-compatible server without custom integration code.
Who created MCP and when?+
Anthropic released MCP as an open standard in November 2024. OpenAI and other major AI labs subsequently adopted the protocol, giving it cross-industry momentum that turned it into a de facto standard.
Why does MCP matter for enterprise AI?+
Before MCP, every AI integration required custom code. MCP creates a common interface layer, reducing integration overhead and enabling enterprises to connect AI systems to their existing software stack far more efficiently than the previous bespoke approach.
Does MCP create vendor lock-in?+
MCP itself reduces lock-in at the integration layer, but new forms of dependency can emerge at the orchestration and service-discovery layers built on top of it. Enterprises should evaluate the full stack, not just the protocol.
What is the investment case for MCP infrastructure?+
The most defensible positions are not in models but in the plumbing that connects them — MCP registries, orchestration layers, observability tools, and security gateways that manage agent tool access at scale.