Every SaaS Will Ship an MCP Server Within Two Years

Here's a prediction I'm fairly confident in: within two years, shipping an MCP server will be as standard for a SaaS product as shipping a REST API is today. Not a differentiator. Table stakes. The companies that don't have one will look the way companies without an API looked in 2015 — like they're not serious about being part of how work gets done.

I'll explain the reasoning, because "AI is big so MCP is big" is not an argument.

The shift in who the user is

For twenty years, the user of a SaaS product was a human clicking around a UI. Everything followed from that. You optimized onboarding, you designed dashboards, you measured time-in-app. The interface was the product, almost.

That assumption is cracking. More and more, the thing trying to use your product is an agent acting on a human's behalf. The human says "reconcile last month's invoices" or "find customers at risk of churning," and an agent goes and does it across whatever tools it has access to. In that world, your beautiful UI is not an asset to the agent. It's an obstacle. The agent doesn't want to click. It wants to call.

A product that an agent can only reach by driving its UI is a product that's hard to include in automated work. A product with an MCP server is a product the agent can just use. That gap is going to matter more every quarter.

Why MCP specifically, and not just "an API"

The obvious objection: lots of SaaS already have APIs, isn't that enough? Sort of, but not really, and the difference is the part people miss.

A REST API assumes a developer reads your docs and writes integration code in advance. That works when a human is doing the integrating. It breaks when the "developer" is a model encountering your product at runtime with no prior knowledge. The model needs to discover what your product can do, understand each capability from a description, and decide what to call, live, in the middle of a task.

That's exactly what MCP standardizes: tool discovery, structured descriptions, a calling convention every AI client already speaks. You can bolt a model onto a raw REST API, and people do, but you end up reinventing the discovery layer per integration. MCP is that layer, agreed on once. The reason it'll win isn't that it's better technology in the abstract. It's that it's the format the agents already understand, and the agents are the new users.

The distribution argument

There's a colder, more commercial reason this happens, and it's the one that'll actually drive adoption.

Right now, getting your product into a customer's workflow means convincing a human to choose it, learn it, and open it. Once agents are the ones composing workflows, being usable by the agent is being in the workflow. If a user asks their assistant to "pull the numbers and draft the report," the products with MCP servers get pulled into that task automatically. The ones without it get left out, not because they're worse, but because the agent couldn't reach them.

That's a distribution channel, and distribution channels are how products live and die. The first time a competitor's tool gets invoked inside an agent's workflow and yours doesn't, the MCP server stops being a roadmap item and becomes a fire.

What I'm less sure about

I'll hedge where I should. I don't know if MCP specifically is the protocol that wins, or if something supersedes it. Protocols get replaced. But the function it serves — a standard way for agents to discover and use a service — that's not going away, because the underlying shift (agents as users) isn't going away. Whether we call it MCP in 2028 is a detail.

And I don't think every product needs to expose everything through it. Some capabilities are genuinely human-only and should stay that way. The point isn't "agent-ify the whole product." It's that the parts of your product that are useful inside someone else's automated task need a door the agent can open.

For us, the relevant version of this is databases. A database with an MCP server in front of it (with the guardrails to make that safe) is one an agent can actually work with, which is the whole reason QueryBear exists. But zoom out and it's the same story everywhere. The user changed. The interface has to follow. It always does.