Here is the thing that should bother you about how enterprise AI has been sold: the pitch has always been about the model. Which model is smartest, which one reasons best, which one you should bet your organisation on. And that framing is wrong in a way that will matter enormously over the next few years, and MCP is why.
Model Context Protocol gets described, usually in one breath, as “better function calling.” That description is accurate. It is also roughly as useful as describing the internet as “better file transfer.” True. Misses the point entirely.
Function calling, in its original form, let a model talk to tools. You’d describe a function to the model — here is what it does, here are its parameters — and the model could invoke it. This was genuinely useful. It was also deeply coupled: the tool was described to the model, the model knew what it was calling, and the integration lived inside the model’s context. If you wanted a different model, you rewrote the integration. If you wanted a different tool, you rewrote the integration. The model and the system were tangled together at the design level.
MCP does something structurally different. It decouples the tool from the model entirely. A system exposes an MCP server — a standardised interface describing its capabilities. Any agent, running any model, can discover and compose that server without the tool knowing what is calling it, and without the model knowing how the tool is implemented underneath. The interface is the contract. Everything else is an implementation detail.
This sounds like an abstraction layer, which it is, but the consequence is not just cleaner code. The consequence becomes visible the moment you try to deploy AI seriously across a heterogeneous enterprise.
Consider a financial institution operating across a large number of markets. Each market has its own core banking system, its own data residency requirements, its own compliance constraints, its own APIs — some modern, some twenty years old and deeply eccentric. In the old world, deploying an AI agent across this landscape meant bespoke integration work per market, per capability, per model. Every combination was its own project. The heterogeneity was a development problem, and development problems scale badly.
In the MCP world, each system exposes an MCP server. The core banking system in one market has a server. The regulatory reporting layer in another has a server. The internal knowledge base, the client data platform, the document processing pipeline — all servers. An agent doesn’t need to know anything about what’s behind them. It composes freely. The integration question becomes: has this system exposed an MCP server yet? Not: how do we build a connector for this specific model and this specific system?
The heterogeneity problem becomes a configuration problem. Configuration problems are solvable at scale. Development problems are not.
The deeper implication is the one the industry hasn’t quite absorbed yet. If any agent can compose any MCP server, then the model becomes interchangeable. You can swap the model — swap the reasoning engine, swap the provider, upgrade to whatever is better next year — without touching the integration layer. The systems stay put. The agent changes. Nothing breaks.
Which means enterprise AI stops being a question of which model you’ve committed to, and starts being a question of which systems you’ve exposed. The organisation that has invested in clean, well-documented MCP servers across its core infrastructure has built something durable. The model on top of it is almost beside the point. It can be anything. It can be replaced tomorrow.
The integration layer becomes the moat. Not the model.
That inversion is what MCP actually changes. Everything else is plumbing.