Why Every SaaS Tool Is Racing to Become MCP-Compatible

What is MCP?

MCP is the reason an AI agent can pull your CRM data, update a Jira ticket, or check a Slack thread without your engineering team writing a separate integration for every AI platform your customers use. One MCP server, built once, works with Claude, ChatGPT, Gemini, and every other MCP-compatible AI.

Here’s the problem it actually solves. Before MCP, connecting five AI models to twenty tools meant building up to 100 separate integrations — what engineers call the N×M problem. MCP collapses that into roughly 25: one connection per model, one connection per tool.

The mechanics run on a client-server setup, communicating over JSON-RPC 2.0 — the same message format family behind the Language Server Protocol that powers tools like VS Code. Three parts make up MCP’s architecture:

People call it “USB-C for AI.” Before USB-C, every device needed its own charging cable. Before MCP, every AI model needed its own way to talk to your product.

MCP’s host-client-server architecture, and how it collapses the N×M integration problem into N+M.

That distinction matters more than it sounds, and it’s exactly where the next objection comes from.

Isn’t MCP just an API wrapper?

No.

MCP isn’t just an API wrapper — it’s more than that, and the confusion is fair. Under the hood, an MCP server does call your existing API. But treating MCP as “just a wrapper” misses what actually changed.

Here’s the real distinction, and it comes down to who’s using the interface. A traditional API is built for a human developer who writes deterministic code: fetch endpoint A, map field B, POST to endpoint C.

An AI agent doesn’t work that way. It’s non-deterministic — it has to explore what’s available, read a description of what each tool does, and decide on the fly what to call and with what parameters.

MCP is built for that second reality. As Itential’s engineering team puts it, a shallow MCP server just exposes every endpoint as a tool. A properly built one exposes meaningful operational capabilities, with enough context for a model to use them safely — turning MCP into a semantic contract instead of a mechanical one.

APIs are built for deterministic developer calls; MCP is built for AI agents that explore and decide at runtime.

• APIs are for services. Deterministic, coded once, called the same way every time.
• MCP is for LLMs. Self-describing, discoverable at runtime, built so a model can figure out the “how” and “when,” not just the “what.”

That difference is exactly why simply wrapping your existing API isn’t enough. If your API returns 50 fields and the model only needs 3, you’re burning tokens and money — and risking “context rot,” where too much irrelevant data actively degrades the model’s output.

So MCP earns its own category — it’s not a rebrand of your API, and it’s not optional plumbing either. The next question is when SaaS companies actually started taking it seriously, and the timeline answers that with dates, not vibes.

When did the race to adopt MCP actually start?

The race to adopt MCP actually started on November 25, 2024, the day Anthropic open-sourced the protocol. That’s not a guess — it’s the first commit. What happened next is the part most explainers skip: the exact dates that turned one company’s protocol into the industry’s default.

Watch how fast the big names fell in line:

That’s not a slow burn. That’s five months from “one company’s open-source project” to “every major AI lab has adopted it.”

MCP’s adoption timeline, from Anthropic’s November 2024 launch to the July 2026 spec update.

TechCrunch first reported Google’s confirmation the same day, marking one of the clearest early signals that MCP was becoming cross-vendor infrastructure rather than an Anthropic-only project.

Microsoft’s own framing captures why this mattered so much, so fast. CTO Kevin Scott called MCP “the HTTP of the agentic web” — the same kind of simple, boring, universal plumbing that made the early internet actually work.

By the time Anthropic handed MCP over to the Linux Foundation in December 2025, it wasn’t a bet on one company’s roadmap anymore. It became neutral infrastructure, backed jointly by Anthropic, OpenAI, Google, Microsoft, AWS, Cloudflare, Bloomberg, and Block.

That timeline answers when. It doesn’t answer why everyone moved this fast — and that’s where the real argument starts.

What’s actually driving the race — distribution, or just efficiency?

Distribution is driving the race, not just efficiency — and that’s the part most explainers get backwards. Efficiency is real: MCP does cut integration work, but efficiency alone doesn’t explain why companies moved in months, not years.

Distribution does.

Here’s the thesis in one line: if an AI agent can’t find your product, it can’t use it — and increasingly, “can’t use it” means “doesn’t exist” to the customer running that agent. This is the same dashboard-to-agent shift reshaping how B2B software gets discovered and used in the first place.

• Distribution — Being inside Claude’s connector directory, ChatGPT’s app list, or a customer’s agent stack is a new acquisition channel, not just a technical nicety.
• Efficiency — MCP collapses custom integration work from N×M to N+M. Real, but it’s the secondary argument, not the reason the biggest players moved first.

Notion’s own engineering team put it plainly: enterprise customers started requesting an MCP server unprompted, as AI-first workflows became part of daily knowledge work. That’s demand pulling supply — not supply chasing a trend.

Stripe backs this up with a real example, not just a vibe. After launching one-click install through Claude’s Connectors, Stripe saw a meaningful jump in MCP installs — growth its own product team attributes directly to how visible Stripe became inside the AI assistant itself, not to any efficiency gain on Stripe’s backend.

Two paths out of the same SaaS product: a shorter efficiency path, and the longer distribution path that gets you found by AI agents.

So the pattern holds: efficiency gets you a cleaner codebase. Distribution gets you found. The next question is whether your product still needs its regular API once you’ve built that distribution layer — and the answer isn’t what most teams assume.

Do you still need your REST API if you build an MCP server?

Yes — you still need your REST API. Building an MCP server doesn’t replace it; MCP sits on top of it. This is the single most common misconception teams run into once they’ve accepted that MCP matters.

Think of it this way: your API still does the actual work — reading records, writing updates, running the logic that makes your product function. MCP is the layer that lets an AI model find that API and call it correctly, without your engineers hand-building a connector for every AI platform a customer happens to use.

MCP is an added layer on top of your existing REST API and business logic — nothing underneath it changes.

• Your API handles the real operation — the database query, the write, the business logic.
• Your MCP server translates that operation into something a model can discover, understand, and call safely.

VMware Tanzu’s engineering team framed it in a way that’s stuck: APIs are for services, MCP is for LLMs. Skip the API and you have nothing for MCP to wrap. Skip MCP and your API stays invisible to every agent trying to use it.

This is also why a rushed MCP build fails fast. A weekend MCP demo is easy. A production-grade MCP server — one that survives real customers, handles token expiry, paginates correctly, and doesn’t leak data between tenants — takes months, because it inherits every operational problem your underlying API already had.

That single fact — MCP is additive, not a replacement — quietly answers half the “should we even bother” objections teams raise before they’ve built anything. The bigger question is whether anyone’s actually proven this pays off yet, and that’s next.

Who’s already winning, with real numbers?

Block, Stripe, and Bloomberg are already winning, with real numbers to prove it — not vague “AI transformation” talk, but specific, attributed outcomes. That’s rare in this space.

Most MCP coverage repeats the same unsourced stats. These three don’t need to.

Start with Block. The company scaled its MCP-powered agent, Goose, to 12,000 employees across 15 job functions in two months. Within a month, 75% of engineers reported saving 8 to 10 hours a week — a number that comes directly from Block’s own account of the rollout, not a marketing deck.

Stripe’s case is about speed of adoption, not hours saved. Launching one-click install through Claude Connectors drove a meaningful jump in Stripe’s MCP installs — proof that distribution, not just capability, drives real usage.

Bloomberg took the slowest, most cautious route — and it’s the most credible for exactly that reason. Bloomberg built its own internal alternative in 2024, before switching to MCP once industry adoption made it the safer long-term bet. The result: experimentation time dropped from days to minutes.

Bloomberg’s own engineers added an important caveat worth repeating — MCP gives you interoperability, not out-of-the-box guardrails, correctness, governance, or production reliability. The trustworthiness has to be designed in.

That caveat is the bridge into a framework worth naming, because “adopt MCP” isn’t one decision — it’s four, stacked on top of each other.

The Agent-Ready Stack: four layers of MCP maturity, from basic distribution to the build-buy-wrap decision.

So the proof exists — it’s just concentrated in a handful of companies willing to publish real numbers instead of vibes. That raises an uncomfortable question the rest of this article can’t dodge: is any of this actually being pulled by buyers, or is it entirely vendors racing each other?

Is this buyer-driven demand, or vendor-side panic?

It’s both — but the honest answer is that nobody has the buyer-side data to prove it cleanly, and that gap is worth naming instead of glossing over.

Here’s what actually points to real demand. Notion’s engineering team reported that enterprise customers started requesting an MCP server unprompted, tied to AI-first workflows spreading through daily knowledge work. That’s a genuine demand signal — customers asking for something before a vendor built it.

Forrester’s forecast reads the same way from the vendor side: 30% of enterprise app vendors are expected to launch their own MCP servers in 2026. That’s a vendor prediction about vendor behavior — useful, but it’s not buyer research.

What the evidence for MCP demand actually covers — and the buyer-side data that still doesn’t exist.

• What exists: Anecdotal enterprise requests (Notion), vendor adoption forecasts (Forrester), and case studies from companies that already built MCP servers (Block, Stripe, Bloomberg).
• What doesn’t exist: Any independent, surveyed data showing how many actual buyers write “MCP compatible?” into an RFP, or reject a vendor for lacking one.

That’s a real whitespace, and most coverage papers over it. Truto’s own buyer-facing guide asserts flatly that a missing MCP server becomes a churn risk and a buying objection for prospects — a claim that’s plausible, repeated often, and still unsupported by any cited survey.

That distinction matters for how urgently you should move, which is exactly what the next section puts a number on: what happens when you race without checking the trust layer first.

Is MCP a security risk you’re not ready for?

Yes, if you’re moving fast without a trust layer — and most SaaS teams are. MCP opens a real, documented attack surface, not a hypothetical one, and racing to ship a server without addressing it is exactly how “agent-ready” turns into “breach waiting to happen.”

Start with what’s already been found and confirmed, not speculated:

These aren’t edge cases dreamed up by security vendors selling fear. OWASP now maintains a formal MCP Top 10 risk list, with tool poisoning ranked MCP03.

Four documented MCP risk categories: tool poisoning, rug pulls, prompt injection, and weak authentication.

Security platform Reco frames the risk this way: an MCP server sits at the intersection of your AI model and your backend systems, so compromising one can expose both sides at once, since the server typically holds credentials for both.

Gartner puts a number on where this is heading: by 2028, 25% of enterprise generative AI applications will experience five or more minor security incidents a year — up from just 9% in 2025. That’s not a distant hypothetical. That’s a near-3x jump inside two years, driven directly by agentic AI adoption outpacing governance.

The identity layer makes this worse, not better. Every AI agent connected through MCP becomes a non-human identity with its own access path — and unlike a human employee, an agent can silently accumulate broader permissions over days or weeks without anyone approving each step. Security researchers call this identity drift, and it happens at machine speed, not the slow pace of traditional privilege creep.

That gap is exactly why 96% of companies are running AI agents, but only 21% can control them — MCP adoption is on pace to widen that gap, not close it, and it echoes the same pattern our look at broken AI containment found elsewhere in the stack.

None of this means don’t build. It means the trust layer isn’t optional polish — it’s the difference between Block’s 12,000-employee rollout and a headline you don’t want. And that risk profile changes company to company, which explains something odd you’ve probably noticed already: some of the biggest platforms barely support MCP at all.

Why do some big vendors support MCP but still lock it down?

Some big vendors support MCP but still lock it down because supporting a standard and trusting what agents do with it are two completely different decisions — and Slack is the clearest, most documented example of exactly that gap.

In May 2026, Slack’s own developer blog announced MCP support and a new Real-time Search API in the same breath as a rate-limit cut. Slack’s words, not a third party’s interpretation: apps distributed outside the Slack Marketplace would see rate limits reduced to 15 messages per request, with up to 1 request per minute — a change Slack states plainly is meant to restrict the bulk exfiltration of data by unvetted third-party applications.

That’s not a technical failure. It’s a deliberate trade-off, and Slack drew the line in a specific place:

• Marketplace-approved apps keep their current, higher rate limits.
• Internal, customer-built apps have no new restrictions — same access as always.
• Everything else — including most third-party MCP clients — gets throttled to 15 messages per request, once a minute.

Slack’s three-tier MCP access model: full access, no new restrictions, and a throttled default for everyone else.

So “Slack supports MCP” is true. “Slack gives every AI agent unrestricted access to your workspace” is not, and Slack never claimed it would — its own rate-limit documentation spells out exactly where each tier sits.

This connects straight back to the trust layer from the last section. A platform holding highly sensitive data has more reason to slow-walk agent access, not less — which means the vendors moving fastest aren’t always the ones you should copy.

That leaves the actual decision every SaaS team reading this has been waiting for: build your own MCP server, buy managed infrastructure, or wrap what you’ve already got.

Should you build, buy, or wrap your way into MCP?

It depends on one question: is MCP core to your product, or a means to expose it? That single distinction decides build, buy, or wrap faster than any feature checklist.

Here’s how the three options actually split:

Building a production-grade MCP server from scratch is a real undertaking, not a weekend project. It means solving OAuth token lifecycle management, per-provider rate limiting, pagination normalization, and tenant isolation — the same operational problems your underlying API already has, just inherited by a new layer. Truto’s own build-vs-buy analysis puts custom MCP server costs at $50,000 to $150,000 per integration, per year — a figure worth treating as directional, not gospel, since it comes from a vendor selling the “buy” alternative and isn’t independently audited.

The part almost nobody gets right on the first attempt isn’t the server — it’s making it useful once it exists. SaasRise’s founder community reported building MCP wrappers for more than two dozen APIs, only to see adoption stay flat.

The fix wasn’t more endpoints. It was skill.md files — plain-text documents explaining the business logic and recommended sequence behind each API, not just its parameters.

APIs describe what an endpoint does. They rarely explain when or why to call it. That’s the gap an AI agent can’t fill on its own.

Build, buy, or wrap: three genuinely different paths into MCP, not a ranked list.

If build-vs-buy still feels abstract, the decision gets easier once you frame it against your own agent roadmap rather than MCP in isolation — a full cost breakdown lives in what agentic AI actually costs.

That closes the loop on the four-layer stack from the framework above: distribution gets you found, trust keeps you safe, proof gets you cited, and this — build, buy, or wrap — is the decision that determines whether you ever reach Layer 3 at all.

Conclusion

The Agent-Ready Stack ties this whole race together: distribution gets you found, trust keeps you safe, proof gets you cited, and build-vs-buy-vs-wrap decides whether you ever reach that third layer at all. Most SaaS teams stop at Layer 1 — they ship a server and call it done — which is exactly why Block, Stripe, and Bloomberg stand out for having real, attributed numbers behind their MCP investment instead of just a badge on their website.

The single most important takeaway: MCP compatibility isn’t optional polish anymore, but racing to ship it without the trust layer is worse than not building at all.

If you’re still deciding where AI agents fit into your product roadmap before you commit to MCP specifically, start with our guide to picking your first AI agent workflow.