You've probably heard the claim that MCP will replace traditional software-as-a-service. It won't, and anyone selling you that story is overselling.
What it does is narrower and more consequential for your budget: it separates the value of a software product from the value of its user interface. Once those two things come apart, a number of your vendor relationships start to look different.
Here's what it is, and what to do about it.
What MCP is, in one paragraph
The Model Context Protocol is a standard way for an AI assistant to connect to a system and use it — read a record, update a ticket, run a query.
Before the standard, every connection between an assistant and a system was custom-built. Ten assistants and ten systems meant a hundred integrations, each maintained separately. With a standard, each system publishes one connector and every assistant can use it. Ten plus ten instead of ten times ten.
That's it. It's a plug shape. The reason it matters isn't technical elegance — it's that the integration cost that has always made this kind of connection uneconomic just dropped by an order of magnitude.
Why to take it seriously rather than wait
Standards proposals appear constantly and most go nowhere. This one has an unusual profile.
It was published by Anthropic as an open standard in November 2024 and has since been adopted by OpenAI, Google, Microsoft, IBM and Amazon — a set of companies that agree on very little. Governance has moved to the Linux Foundation. Monthly SDK downloads reached 97 million by March 2026, from roughly 100,000 at launch. Over 5,800 servers and 300 clients are publicly available. Reported Fortune 500 implementation stands around 28% in under 18 months.
Competing vendors adopting a common standard is the reliable signal. Vendors only converge when the alternative is worse for all of them. That happened here, which is why this is closer to "how USB became universal" than to the usual standards-body announcement that nobody implements.
Sensible reading: this is becoming infrastructure. Not a bet on a vendor.
What actually changes commercially
Interface value and system value come apart
Most enterprise software bundles two things: a system that does something useful, and an interface for humans to operate it. You pay for both, per seat, whether or not each user needs both.
When an assistant can operate the system directly, some of that interface stops being used. The occasional user who logs in four times a year to check a status doesn't need a licence — they need an answer, and they can now get it by asking.
This doesn't kill SaaS. It compresses the low-intensity tail of your seat count, which in most large organisations is a meaningful share of spend. Your power users keep their seats and keep needing them.
Integration stops being a project
The historical reason your systems don't talk to each other isn't that nobody wanted them to. It's that each connection was a project with a business case, and most connections couldn't clear the bar.
Lower that cost by an order of magnitude and a large category of previously uneconomic integrations becomes viable. This is where the real value sits — not in replacing software, but in connecting the software you already own.
Vendor lock-in changes shape
If your systems are reachable through a standard interface, the assistant on top becomes a swappable component. You can move between model providers without rebuilding your integrations.
Conversely, a vendor who refuses to expose a standard interface is making a statement about the relationship. That's now a legitimate procurement question, and it's cheap to ask.
What to actually do
Six steps, in order. Deliberately unambitious — this is infrastructure work, and the failure mode is a large programme with nothing running.
1. Add one clause to your procurement template. Every software contract renewal from now on asks: does this vendor expose an MCP interface, and on what terms? Zero cost, and it starts shaping supplier behaviour immediately.
2. Inventory your seat spend by usage intensity. Which licences are held by people who log in a few times a month for simple lookups? That's the population where the economics change first. Most organisations have never separated this from their power-user spend.
3. Pick three internal systems and expose them. Not the ones with the highest value — the ones with the most requests for simple information. Typically: ticketing, HR self-service, and whatever people constantly ask about order or case status.
4. Sort out identity before anything else. This is where these programmes fail. An assistant acting on a user's behalf must have that user's permissions, not a service account's. Get this wrong and you build a very efficient way to leak data across departments. If your identity model can't express per-user permissions at the data layer, fix that first.
5. Log everything. Every action an assistant takes should be attributable to a person, with a timestamp and a record of what was accessed. You will need this for audit, and retro-fitting it is painful.
6. Name an owner. One person accountable for which systems are exposed, to whom, and under what controls. Without this it grows organically and becomes ungovernable, which is exactly what happened with the first wave of departmental SaaS.
Where this genuinely goes wrong
Permissions are the whole risk. An assistant with broader access than its user is a data breach with a friendly interface. Everything else on this list is a productivity question; this one is a career question.
Sprawl. 5,800 available connectors is an opportunity and a governance problem. Without an owner, you'll have forty in production within a year, installed by teams acting reasonably, with nobody able to enumerate them.
Confusing plumbing with capability. Exposing systems doesn't make them useful. If the underlying data is wrong, an assistant will surface wrong information faster and more confidently than before.
Assuming your vendors will cooperate. Some vendors' commercial models depend on seat counts and interface stickiness. Expect friction, restrictive licensing terms, or interfaces deliberately limited in what they expose. Read the terms.
The realistic timeline
Now: procurement clause, seat-spend inventory, identity assessment. Weeks, near-zero cost.
Next quarter: three internal systems exposed, with proper identity and logging. Small team, contained scope.
Next year: decisions about which seat licences you actually need at renewal, based on measured usage rather than assumption.
Not now: a large MCP programme. There isn't one to run. This is infrastructure that accumulates value quietly, and the organisations that do well with it will be the ones that started early and unglamorously rather than the ones that announced a strategy.
Sources: Model Context Protocol project documentation and 2026 roadmap; Linux Foundation governance announcement; published adoption statistics for SDK downloads, server and client counts, and Fortune 500 implementation rates, accessed 2026-07-26. Adoption figures come from third-party trackers and should be treated as directional rather than audited.
Fares runs QartMina Labs, an independent backend and AI engineering practice.