How MCP Got Here So Fast
When Anthropic released the Model Context Protocol in November 2024, the initial reaction from many engineers was polite skepticism — another vendor spec trying to become a standard. Six months later, the picture looks substantially different. Block, Replit, Sourcegraph, and Zed have all shipped MCP integrations. Cloudflare added remote MCP server support. Microsoft’s Copilot Studio announced MCP compatibility. OpenAI — Anthropic’s most direct competitor — quietly added MCP support in its agents SDK, which is about as clear a signal as the industry sends that a spec has escaped its origin story. When the company whose own function-calling format is the main alternative starts implementing your protocol, the standardization debate is largely over.
The protocol itself is not particularly exotic. MCP defines a client-server architecture where a “host” (your agent or LLM application) connects to “servers” that expose tools, resources, and prompts over a standardized JSON-RPC interface. What made it stick where others failed is a combination of timing and pragmatism. It arrived exactly as teams were discovering that bespoke tool integration — writing custom parsers for each model’s output format, maintaining separate adapters for every API — was becoming a genuine engineering tax. MCP offered a way out that didn’t require betting on a single model provider, which is precisely the kind of optionality that enterprise buyers and platform companies find appealing.
What This Does to Teams Already Committed Elsewhere
The uncomfortable question is what this momentum means for the significant number of teams that built their tool-calling infrastructure around OpenAI’s function calling spec, which has been the practical standard since GPT-4’s release in 2023. The function calling approach — where you define tool schemas in JSON, pass them in the API request, and receive structured tool-use responses — is deeply embedded in production systems. Frameworks like LangChain, LlamaIndex, and AutoGen all have substantial abstractions built on top of it. The honest answer is that these teams are not in crisis, but they are carrying growing technical debt that wasn’t visible twelve months ago.
OpenAI’s function calling spec and MCP are solving adjacent but distinct problems. Function calling is a model-level capability — a way to get a specific model to emit structured output that maps to a tool invocation. MCP is an infrastructure-level protocol — a way to define, discover, and invoke tools across different models and runtime environments. This distinction matters because it means the two aren’t always in direct competition. You can, and many teams will, use OpenAI models with MCP servers by going through OpenAI’s own MCP support layer. The issue arises when your internal tooling was built to be tightly coupled to the function-calling format itself: custom schema validators, proprietary tool registries, response parsers that assume a specific JSON envelope. That code doesn’t translate cleanly, and the migration cost is real.
The Custom Infrastructure Problem Is Worse
Teams that went further and built entirely custom tool-calling systems — often because they were working with open-source models like Llama or Mistral before those models had mature function-calling support — face a sharper version of this problem. These systems typically involve prompt engineering hacks, output parsers with fragile regex logic, and retry mechanisms built to compensate for inconsistent structured output. They work, often surprisingly well, but they work by solving a problem that MCP is now solving at the protocol level with community tooling, SDKs in a dozen languages, and model providers actively optimizing for it. The question isn’t whether these custom systems are good engineering — many of them are — but whether continuing to maintain them represents a worthwhile allocation of engineering time when an interoperable alternative is gaining critical mass.
What Actually Matters When Deciding What to Do
The decision isn’t binary. Before treating MCP adoption as an urgent migration project, it’s worth being precise about what you actually need from your tool integration layer. A few questions sharpen the analysis quickly:
- Are you model-locked by choice or by circumstance? If your system is intentionally built around a single model provider and you have no plans to change, the portability benefits of MCP are largely theoretical for you today. The cost of migration may not be justified by optionality you don’t intend to exercise.
- Do you have external tool authors? MCP’s value compounds dramatically when the tools are being written by people outside your team — third-party integrators, customers building on your platform, or open-source contributors. If all your tools are internal, the discoverability and interoperability story matters less.
- How many tools are in your registry? Teams with fewer than a dozen internal tools can absorb a migration relatively painlessly. Teams with hundreds of tools built around proprietary schemas are looking at a multi-quarter effort, and should think carefully about whether a hybrid approach — wrapping existing tools as MCP servers without rewriting their internals — makes more sense than a full migration.
The wrapper approach deserves more attention than it typically gets in these conversations. Because MCP servers are just processes that speak JSON-RPC over stdio or HTTP, you can expose almost any existing tool implementation as an MCP server without touching its business logic. A team with a mature internal tool library built on OpenAI’s function calling format can write a thin translation layer that accepts MCP requests and dispatches them to existing tool handlers. This is not a permanent architecture — it accumulates its own abstraction costs — but it buys time without requiring a full commitment to either abandoning existing infrastructure or ignoring a standard that is clearly gaining traction.
The Ecosystem Bet Underneath the Technical Question
There’s a strategic dimension here that pure technical analysis tends to underweight. MCP winning means that the tool ecosystem around it will compound. Pre-built MCP servers for common integrations — GitHub, Slack, databases, browser automation — are already proliferating on GitHub. Anthropic has been curating a reference list; the community is building faster than any single team can track. This is the same dynamic that made npm and Docker so hard to argue against even when technically superior alternatives existed. The question stopped being “is this the best design?” and became “is this where the tooling will be?” For MCP, that question is increasingly answered.
Teams that wait for the dust to fully settle before moving are making a reasonable bet, but they should be honest that the dust has mostly settled already. The more useful posture is to stop treating MCP as a future consideration and start treating it as the baseline assumption — which means new tools get built as MCP servers, existing high-value tools get wrapped first, and the proprietary glue code gets deprecated on a timeline that reflects actual maintenance burden rather than optimistic roadmap planning. That’s not a dramatic migration. It’s just accurate accounting of where the industry has already moved.
