Why Your SaaS Needs an MCP Server: It Is a Buying Criterion Now

In August 2026 Zeno Rocha, of the email company Resend, posted something on X that got 114,900 views in a few days.

"something changed in how i buy software. at work, i only pick services with an official MCP (posthog over plausible). at home, same thing. i use strava because i can ask claude about my runs."

"i used to care about features, now I care about interacting with my data. no MCP means i have to use your UI. that's a dealbreaker now."

— @zenorocha, 21 August 2026

I have seen that sentiment building for months. This was the first time I saw someone say it as a procurement rule.

So I went and checked whether the data backs it up. It does, and the shift is faster than I expected.

If you sell software and you have been treating MCP as a 2027 problem, this post is the argument for moving it up.

What Actually Changed: Features to Access

For twenty years, software was sold on features. You compared two dashboards and picked the better one.

That comparison assumed a human would be doing the clicking. That assumption is now shaky.

If I can ask an agent "which of our accounts churned last month and why", I do not care how nice your charts are.

I care whether your data can reach the agent. An MCP server is the answer to that question.

This reframes your UI as a cost rather than a feature. Every task that requires your interface is a task the buyer cannot automate.

That is the whole argument in the tweet, and it is why it resonated. "No MCP means I have to use your UI."

The Numbers Behind the Trend

Anecdotes are easy. I run a sync against the public MCP registry, so I checked the actual shape of it.

As of 25 August 2026 that registry holds 24,011 servers. Here is the part that matters for buyers:

Measure	Count	Why it matters
Servers in the registry	24,011	The catalogue a buyer checks before asking you
Publishing a remote URL	7,839 (33%)	Hosted and reachable — no install, so a buyer can try it in minutes
Dated entries, H2 2025	~4,100	The early-adopter wave
Dated entries, H1 2026	~19,900	Roughly 5x the previous half-year

A fivefold jump in six months is not a niche protocol finding its footing. That is a land grab.

One honest caveat on that last row: publish dates in the upstream registry thin out after early May 2026, so treat the half-year comparison as a floor rather than a precise rate.

The 33% remote figure is the one I would put in front of a product team. A third of the field is already hosted, not a README telling someone to clone a repo.

The PostHog vs Plausible Test

The tweet names two analytics vendors. I checked both against the registry, because a claim like that is worth verifying.

PostHog publishes an official server under its own GitHub organisation. It resolves in the registry as io.github.PostHog/mcp.

Plausible returns nothing. No official entry, no community entry under that name.

So the buying decision described in that post was not a vibe. It was a lookup, and the lookup took about four seconds.

That is the uncomfortable bit. Your absence from the registry is a fact a prospect can check without ever contacting you.

The same pattern holds across categories. Stripe, Linear, Sentry, Vercel and Figma all ship official servers. Their closest competitors mostly do not.

What Buyers Are Actually Screening For

"Has an MCP server" is the first filter. It is not the only one, and the later filters are where vendors lose.

From what I see people check, in order:

1. Is it official? A community wrapper signals the vendor is not committed to it.
2. Is it hosted? A remote URL beats "clone this repo and set twelve environment variables".
3. Does auth work properly? OAuth or a scoped token, not a static key pasted into a config file.
4. Do the tools cover write operations? Read-only servers are demos. Buyers want the agent to act.
5. Are the tool descriptions good? This decides whether the agent picks the right tool at all.

That last one is invisible in a feature list and decides everything in practice. A vague description makes a capable model guess.

We wrote a whole piece on it — tool description quality moves agent accuracy more than swapping models does.

Why a Bad MCP Server Is Worse Than None

Here is the part the trend pieces skip, and it is the reason I would not rush this.

An MCP server is a new front door to your product's data. Ship it carelessly and you have shipped an incident.

The single most common finding we see on public endpoints is depressingly simple. The server answers tools/list to anyone who asks.

No credentials, no rejection. A full inventory of your capabilities, handed to an unauthenticated caller.

The second most common is worse. Tools that accept a customer ID as a parameter with no check that the caller owns that customer.

That is classic IDOR, wearing a new protocol. It is easy to introduce, because the tool schema looks perfectly reasonable.

A third pattern: CORS configured to reflect any Origin. Combine that with cookie auth and any website can call your server as your logged-in user.

None of this is exotic. It is the same authorization work your REST API already does, applied to a surface most teams built in a hurry.

Scan your MCP server against the OWASP MCP Top 10 before it goes in a launch post.

How to Ship One That Survives Scrutiny

If you are starting from nothing, the order that works:

1. Pick five tools, not fifty. The five questions your customers ask support most often.
2. Write the descriptions like documentation, because that is exactly what the model reads.
3. Build against the current spec. Our 2026-spec build guide covers the stateless transport.
4. Host it. A remote URL is what turns a repo into something a buyer can try.
5. Test it with a real agent before you announce it.
6. Scan it for auth, IDOR and CORS problems.

Step five is where most teams get a surprise. A server that returns valid JSON can still be unusable by an agent.

Test any MCP server free, point a model at it, and read the arguments it actually sends.

How MCP Playground Helps

MCP Playground is the browser-based place to check your server before your buyers do.

Connect any endpoint, run it against 60+ models, and watch every tool call with its arguments. No install, no API key.

Then run the security scanner over the same URL to catch the unauthenticated tools/list before someone else finds it.

Frequently Asked Questions

Is MCP really a buying criterion, or just developer hype? Both, for now. It is a real filter among technical buyers and teams building agent workflows. It is not yet on a typical enterprise procurement checklist.

How long does it take to ship an MCP server? A focused five-tool server is a week of work. Making it safe to expose publicly takes longer than building it.

Do we need a hosted server, or is a repo enough? A repo counts for the registry. A hosted URL is what a buyer can actually try during an evaluation.

What if a community MCP server for our product already exists? Treat it as a warning. Someone wants your data in their agent badly enough to build it, and you do not control its auth or its accuracy.

Conclusion

The buying question has moved from "what can your software do" to "can my agent reach my data". A registry with 24,011 servers says a lot of vendors already worked that out.

The move is not to rush a server out. It is to ship a small, well-described, properly authorised one — and to prove it works before you market it.

Test any MCP server free, then scan it before it reaches a prospect.