DEV Community

Anil Kurmi
Anil Kurmi

Posted on

MCP just walked into enterprise SaaS like it belonged there, and most people missed it

The quietest big AI shift of 2026 happened this week, and almost nobody noticed.

On May 14, Freshworks shipped Freddy AI Agent Studio and an MCP Gateway inside Freshservice. It sounds like another "we added AI" product update. It isn't. The MCP Gateway is doing the load-bearing work, and an ITSM vendor — an ITSM vendor — is the one productizing it for mainstream IT operations.

Here's the position I'll defend: MCP has already won. Most people just haven't noticed yet. In two years we're going to talk about MCP the way we talk about LSP for editors — the layer everyone forgot was a fight, because one side simply won.

Why this launch is the bigger signal

For a year, MCP discourse lived in developer Twitter and framework communities. Cool protocol, neat demos, occasional skepticism about whether the abstraction would survive contact with enterprise reality.

Then Freshworks dropped it into IT service workflows — pulling context from Notion, Linear, ClickUp into Freshservice — and packaged it with governance language and outcome metrics (xLAs + AI Insights, in their framing). No press circuit. No "this is the future" keynote. Just shipped.

This is the threshold that matters for any standard: it goes from "developer-conference favorite" to "load-bearing piece of a paid SaaS product an enterprise IT director already pays for." LSP did this. Kubernetes did this. SAML did this. Most standards that don't do it die in the developer-tools layer and never become infrastructure.

MCP is doing it. Right now. Without anyone declaring victory.

What's actually under the hood

Freshworks bundled three things:

  1. Agent Studio — no-code and prebuilt agents for service workflows. Fine. Necessary. Not the interesting part.
  2. MCP Gateway — the context bridge to third-party tools without bespoke per-integration code. This is the interesting part.
  3. xLAs + AI Insights — outcome metrics tying agent performance back to experience signals so teams can prove or disprove the agent's value.

Stack them and you get: build the agent fast, wire it into real context fast, then measure whether it actually helped fast. That's the loop most enterprise AI projects can't close. Pilots stall at the "wire it into real context" step. MCP at the gateway layer makes that step shorter.

The opinion I keep arguing with people about

I get this counter a lot when I say MCP has won: "Protocols don't matter until enterprises actually adopt them. Talk to me when Salesforce ships MCP, not Freshworks."

I disagree with this and I want to lay out why.

Standards don't win because the biggest player blesses them. Standards win because the cost of using the standard becomes lower than the cost of building your own glue, and that crosses a threshold for an integrator somewhere in the middle of the stack. The middle of the stack is where it always starts. LSP didn't win because Microsoft anointed it; it won because individual editor maintainers couldn't justify writing N×M integrations anymore. Same shape here. Freshservice doesn't need to be the biggest enterprise SaaS for the math to flip. It just needs to be a credible proof that the gateway pattern works at production scale for someone real.

Once the gateway pattern is normalized, every adjacent product manager looks at their backlog of "integrate with X tool" tickets and thinks, "We could write 20 connectors, or we could put an MCP gateway in front and ship 100." The math is not subtle.

If you're building agent infrastructure today and you haven't picked your MCP posture — server, client, gateway — you have already lost a year of compounding integrations. I'll defend that strongly. Tell me why I'm wrong.

Where the optimism gets uncomfortable

I want to be honest about the part of this that bothers me, because the "MCP solves enterprise AI" framing has obvious failure modes.

The abstraction can hide data lineage. "No custom code" feels great until something leaks across a permission boundary and the trail of how the model got that data is buried three protocol hops deep. Governance has to keep up with adoption speed, and right now it isn't.

Semantic alignment is harder than connectivity. The protocol problem (how do tools talk?) is mostly solved. The ontology problem (what does "high priority ticket" mean across four systems?) is not. I think the next integration war is going to be semantic, not API-level. I don't have a confident answer for how it gets won.

No-code doesn't remove engineering. It moves it. It moves it into identity, audit, policy, rollback, and incident response. Which is more engineering, not less, just in places most "no-code" pitches avoid talking about.

Where they all agree: the integration layer now decides enterprise agent success more than the model layer does. That's not in dispute. The question is whether protocol standardization makes the integration layer easier or just trades one class of pain for another.

What this changes if you're a developer

A few uncomfortable shifts that are happening whether you're ready or not:

  • Integration skill is core AI skill now. Data contracts, permission models, workflow boundaries, audit trails. If you optimize your career around prompt tuning in 2026, you're optimizing for the wrong layer.
  • Protocol literacy is no longer niche. Understanding MCP's actual semantics — what a tool description means, how schema negotiation works, where authentication sits — is production knowledge in 2026, the way HTTP semantics were in 2008.
  • Observability is mandatory before scale. If you can't trace which tool fed which context into which decision, you cannot safely scale a Freshservice-shaped agent in production. Most teams don't have this yet.
  • Governance work pays more than it used to. The people who can write a defensible audit trail for an agent's actions are about to become very expensive.

The honest counter-position

I should acknowledge the strongest counter to my "MCP has already won" claim. It goes: standards have died at this stage before. Adoption inside one vendor doesn't mean ecosystem lock-in is broken. Maybe MCP fragments — vendor-specific extensions, incompatible gateways, the usual.

That could happen. The history of standards has plenty of "won the demo, lost the war" stories. I just don't think it's the most likely path here, because the gateway pattern (one component absorbing all third-party connections) is exactly the architectural shape that makes standard divergence painful. The economic incentive to stay compatible is stronger than the political incentive to fork.

But I could be wrong. If you think MCP fragments by 2027 — into "Anthropic-MCP" vs "OpenAI-MCP" or a Salesforce-flavored fork — I'd like to hear the argument.


if you've shipped a real agent integration this year, did MCP make it easier, or did it just add a layer? I'm taking the "easier" side. Show me the case where it was the wrong call.

Further reading

Top comments (0)