The Problem Nobody Wanted to Admit Out Loud
For the last couple of years, I’ve watched teams struggle with the same architectural problem, though few seemed willing to name it directly. When you wanted an AI model to interact with your systems—a codebase, a database, internal documentation—you ended up writing custom integration code. Lots of it. Each model had different expectations. Each tool wanted a different shape of data. You’d end up with what I’d call “glue code sprawl,” where half your engineering effort went into translation layers instead of actual functionality.

The frustration was real because the problem was avoidable. We weren’t dealing with physics constraints or algorithmic impossibilities. We were dealing with poor standardization, the kind that slows down an entire ecosystem for years because nobody wanted to take the first major step toward compatibility.
Then Anthropic released something that, on the surface, looked like a straightforward protocol. I didn’t immediately recognize what it actually was: the moment an industry standard began to form.

The November 2024 Release and What Actually Happened
When Anthropic open-sourced the Model Context Protocol in November 2024, the announcement didn’t cause a sudden market shift. That’s not how infrastructure adoption works. Instead, it was the kind of release that gets a thoughtful nod from engineers who recognize good engineering when they see it. But the adoption curve that followed suggested something else was happening beneath the surface.
By early 2026, you could already see MCP support in Cursor, Zed, Replit, and across the JetBrains IDE ecosystem. That’s not the velocity of a niche protocol. That’s the velocity of something that solved a real problem in a way that actually made sense. The MCP GitHub repository accumulated over 28,000 stars, with hundreds of community-built server implementations covering the ground you’d expect: databases, APIs, file systems, and developer tools. The ecosystem was building itself.
What struck me most, though, was what happened next. OpenAI announced in early 2026 that it would add MCP support to its API and Agents SDK. Let that sink in for a moment. Your direct competitor’s protocol is good enough that you’re adopting it. That’s not something companies do casually. That’s a signal that the market has already decided.
How the Architecture Actually Works
To understand why MCP gained traction so quickly, you need to understand what it actually does. The protocol runs on a client-server architecture where AI models act as clients consuming structured context from local or remote servers. That’s the clean description. Here’s what it means in practice: instead of your application managing the messy details of how to connect Claude to your PostgreSQL instance or your GitHub repo, you define a server that knows how to speak MCP, and the protocol handles the rest.
This eliminates the custom API glue code that used to fill agentic workflows. I’ve written plenty of that glue code myself, and I can tell you it’s one of the least satisfying parts of the job. It’s necessary boilerplate, often fragile, and it needs rewriting every time you want to add a new data source or change how an agent accesses information. MCP standardizes that interaction pattern. It makes the glue generic instead of custom.
The Anthropic Model Context Protocol documentation lays out the specifics, but the core insight is simple: define your resources, define your tools, define how to access them. The protocol handles the serialization and the conversation flow. Your job shrinks considerably.
Enterprise Adoption and the Real Signal
Early adopters matter, but enterprise adopters matter more when you’re evaluating whether something is infrastructure or just a nice tool. Block, formerly Square, and Apollo were among the organizations Anthropic cited as early adopters. These aren’t companies that experiment with every new protocol. They’re companies that make deliberate choices about standards because they need to integrate across large, complex systems.
Block used MCP to connect Claude-based agents directly to internal codebases and documentation systems. That’s the exact problem space where I would have expected bespoke solutions for the next five years. Instead, Block standardized on an open protocol. Apollo did something similar. When enterprises start doing that, you know something has shifted in how we think about interoperability.
This is the pattern I learned to watch for during years of infrastructure work: when adoption jumps from “early adopters experimenting” to “enterprises standardizing on this,” you’re looking at something that’s likely to outlast the moment. MCP has already crossed that threshold.
The USB-C Comparison Actually Holds Up
I was skeptical of the USB-C comparison at first, but the more I think about it, the more apt it is. USB-C succeeded not because it was technically perfect—it wasn’t—but because it solved a coordination problem that was costing everyone time and resources. Before USB-C, you had fragmentation, incompatibility, and endless custom adapters. After, you had a single port that worked across devices and manufacturers.
MCP is doing the same thing for AI model integration. It’s not perfect. No protocol is. But it solved the fragmentation problem that was costing teams engineering effort and slowing down agentic development. Competitors recognized it as valid enough to adopt. And most importantly, the ecosystem voted with its feet.
The fact that we’re only in early 2026 and this level of adoption is already visible suggests we’re looking at something that will shape how AI tools integrate with each other and with business systems for the next several years. That’s not a prediction I make lightly.
If you’re building AI agents or integrating models with your systems, spend time understanding how MCP works and where it fits into your architecture. The infrastructure layer matters, and this one is solidifying faster than most. Have you implemented MCP yet, or are you still working through the traditional glue code approach? I’d be interested in hearing what you’re seeing on your end.