Every enterprise tool that matters — CRM, database, ticketing system, spreadsheet, code repository — is deciding, right now, whether to expose a Model Context Protocol (MCP) server. This is no longer an early-adopter question. By April 2026 the ecosystem had already passed 9,400 public MCP servers, with private and enterprise-internal servers conservatively estimated at another 3–4x that — more than 10,000 enterprise servers and over 97 million SDK downloads. Anthropic, OpenAI, Google, Microsoft, and AWS have all adopted the protocol. This stopped being an experiment and became infrastructure.
MCP solves a structural problem that stayed invisible while only a handful of agents were in production: every agent-tool pairing needed its own integration. A support agent that needs to query a CRM, open a ticket, and check inventory had three bespoke integrations. Switching LLM providers meant rewriting all three. The growth was combinatorial: N agents times M tools, with no reuse — the same problem that makes orchestrating multiple agents more expensive than consolidating into one when nobody plans for connection reuse.
The problem that existed before MCP
Before the protocol, "connecting an agent to a tool" meant writing a function, describing it in natural language for the model, handling authentication, versioning the contract by hand, and repeating that for every agent-tool pair. Agent frameworks tried to abstract the repetition with their own layers — which solved code duplication, but not integration duplication: the CRM backend still had to expose a specific API for every framework that wanted to consume it.
MCP splits two roles that used to be fused. On one side, the MCP server — maintained by whoever knows the system — exposes three standardized primitives: tools (functions the agent can call), resources (data the agent can read), and prompts (reusable templates). On the other, the MCP client — inside the agent, from any framework — discovers and consumes those primitives through a common protocol, without needing to know anything about the system's internal implementation.
Before MCP, every agent had to relearn how to talk to every tool. Now the tool learns to speak MCP once, and any compatible agent already understands it.
What changes for whoever decides architecture
The practical consequence is that the marginal cost of connecting a new agent to an existing system drops — but the cost of keeping that system exposed goes up. Exposing an MCP server means accepting traffic from clients you don't individually control, with a tool contract that needs serious versioning discipline and a new audit surface.
That has already changed vendor behavior. Thirty percent of enterprise app vendors are launching their own MCP server — including CRM and data layers that today only connect through proprietary REST APIs or webhooks. When Data Cloud stops being just a CDP and becomes Salesforce's central nervous system, exposing that layer via MCP means any compatible external agent — not just the platform's native one — can query the same customer data graph, with governance on the server side, not on the side of each custom integration.
For whoever decides architecture today, the question is no longer "should we adopt MCP" — it's "which of our internal systems are worth exposing as a server, and with what access control". A system with sensitive data and high reuse value justifies the investment of exposing it well. A single-use system, with no candidate for a second consumer, doesn't justify the extra maintenance.
Does MCP replace native function calling?
No — it solves a different problem. Native function calling (OpenAI's or Anthropic's tool use) already lets a model call a function described in JSON Schema inside a single application. That's still the right layer when you control both sides: the agent and the tool live in the same codebase, with no need for dynamic discovery or reuse by third parties.
MCP matters when the server and the client are maintained by different teams or companies, or when the same server needs to serve multiple agents with different needs over time — without the server's maintainer needing to know, in advance, who will consume it. It's the difference between writing a private function and publishing a versioned API: both solve "my code calls other code", but at different scopes of responsibility.
When it's worth adopting now
It's not a binary "everyone needs this" decision. Three criteria help decide whether this is the moment to invest in exposing — or consuming — MCP:
- Real reuse, not hypothetical. Is there, today or on a concrete two-quarter roadmap, more than one agent or framework that will need to access the same system? This is the same logic as validating whether an agent is the right answer before multiplying integrations — before exposing a server, it's worth confirming the process behind it is already mature. If the answer is "just one agent, just one use case", direct integration is still simpler and cheaper to maintain.
- Governance on the right side. Exposing via MCP moves access control inside the server — who can call which tool, with what scope. If that control doesn't exist even in the current API, layering MCP on top doesn't solve the governance problem; it just moves where it shows up.
- Ability to version without breaking clients. An MCP server in production needs a stable contract. If the team responsible still changes API schema without warning, publishing that as an MCP server multiplies the blast radius — from one internal client to any external agent that discovered the tool.
Pass all three, and the investment pays off. Fail two or more, and it's worth fixing the house first before publishing that as a surface for third parties.
The pattern forming now is the one that will last
The adoption speed — from zero to 10,000 enterprise servers in a bit over a year — suggests MCP has become the common vocabulary between agent and tool, the same way REST became the common vocabulary between frontend and backend. Whoever decides to expose a system as an MCP server today is, in practice, deciding the contract that will govern agent integration for years to come. It deserves the same care any public API would — because, effectively, that's what's being published.
Questions that keep coming back
Three practical questions that show up in almost every MCP conversation — answered with what this piece already argued.
Is it worth adopting MCP now, or can it wait?
It's worth adopting now if you pass the three criteria of reuse, governance, and versioning — and worth waiting if you fail two or more. Adoption stopped being a bet: with more than 10,000 enterprise servers and Anthropic, OpenAI, Google, Microsoft, and AWS behind the protocol, the risk of backing a standard that dies has all but disappeared.
What still applies is scope discipline. If today there's only one agent and one use case, direct integration remains simpler and cheaper to maintain. The right moment is when a real second consumer shows up — or a concrete two-quarter roadmap that brings one.
Which internal systems are worth exposing as an MCP server?
Systems with high-reuse-value data and more than one candidate agent as a consumer — CRM, data layer, ticketing — are the ones that justify the investment. The rule is real reuse, not hypothetical: if nothing beyond a single agent will ever call that system, exposing an MCP server just adds maintenance.
The maturity of the owning team matters just as much. An MCP server in production is, in practice, a public API: it needs a stable contract, access control inside the server, and the ability to version without breaking clients you don't control. A system whose schema still changes without warning isn't ready to become a surface for third parties.
Do I need to switch agent frameworks to use MCP?
No — the MCP client works from inside any framework. That's precisely the point of the protocol: the server exposes standardized tools, resources, and prompts, and any compatible agent discovers and consumes those primitives without knowing anything about the system's internal implementation.
It also lowers the cost of switching LLM providers later. Before MCP, changing models meant rewriting every bespoke integration; with the protocol, the tool learns to speak MCP once and the agent consuming it can change without touching the server.