The Five Questions to Ask Before (and After) You Build an MCP Server

This piece includes data and commentary contributed by Kin Lane, API Evangelist.

Teams don't ask "should we build an MCP server" once and move on. Some haven't built anything yet and are deciding if it's worth the effort. Some are mid-build, because a customer asked or because everyone else seems to be doing it. And a growing number have already shipped one. Some are confident it was the right call and are looking for where to invest next. Some are still unsure whether it's earning its keep. Others are realizing they need a traditional integration underneath it to make the whole thing work.

All three groups are asking versions of the same question, even if it doesn't feel that way from where they're standing. This piece lays out a practical framework: five questions for evaluating when MCP is the right tool, when a traditional integration is, and when the honest answer is both. It works whether you're deciding, mid-build, or three months into production and reassessing. The only thing that changes is which answer you're checking against.

Check the data behind the MCP hype

The growth is real. Bloomberry tracked MCP-related subdomains across roughly 1,400 companies and found the number of live MCP servers grew 232% in six months: from 425 in August 2025 to over 1,400 by February 2026, with new servers launching at an accelerating pace each month (Bloomberry, "We analyzed 1,400 MCP servers," Feb 2026). That's faster than prior generations of integration tooling took to reach the same scale.

But the raw directory counts tell a different story. PulseMCP's server directory lists over 20,000 "MCP servers" (PulseMCP server directory). Some of that is duplicates and abandoned projects. Most of it is something more specific: a single platform wearing thousands of tenant domains, each one counted as its own server.

Kin Lane, who's spent years tracking the API industry as the API Evangelist, put real numbers on that gap for us. His team tracks roughly 6,500 MCP endpoints across the web. As of late September, only about 700 of them, roughly 11%, actually answer an agent's cold call: a real initialize and tools/list request, no credentials required. Another 21% are live but sit behind auth, so a real server is there, but an agent needs a token before it can do anything with it. That leaves close to two-thirds, 64%, as announcements, documentation links, or auto-generated pointers that have never been confirmed to respond at all. Put differently: most of the growth everyone's counting is companies launching MCPs. Something closer to one in ten of those launches is a server an agent can actually pick up and use, unprompted.

This explains the noisy directory counts. Of the live servers Lane's team could inspect closely (around 630), 58% are platform-authored: a handful of platforms, commerce checkout flows, site builders like Wix, e-commerce platforms like Shopify, documentation tooling like Mintlify, wearing thousands of tenant domains instead of something each company built. The other 42% are the provider's own design, and that share is climbing fast. It was around a quarter in late August. It's 42% a month later. First-party MCP design is catching up, just from a low base. One more number matters here: of those roughly 630 inspectable servers, only 9 include a way for the agent to send feedback, the kind of detail that separates a server built for how an agent actually works from one shipped to check a box. (These figures are a conservative floor by design. Lane's team counts a server as live only if it actually answered, so the true non-responsive share is, if anything, higher, not lower. Numbers current as of September 22, 2026.)

As Lane put it when he shared this data with us:

The question was never whether to build an MCP server — it's whether you've done the work that makes one worth building. An MCP is a new doorway onto the same house: if the API behind it is well-designed, well-documented, and scoped to a real job an agent needs to do, the MCP inherits all of that. If it isn't, you've just given an agent a faster way to reach a mess. Most of the MCP servers I see in the wild are auto-generated wrappers shipped to check a box, and they measure exactly as well as the API underneath them. So evaluate the MCP the way an agent will actually experience it: can it discover the thing, understand what each tool does, and finish a real task without a human in the loop? Presence isn't readiness — building one is the easy part. Being worth calling is the work. - Kin Lane, API Evangelist

That's one half of the story: whether what's already been built is actually usable. The other half is demand, and it's just as often assumed as measured.

Ask a room of software leaders whether their customers have asked for MCP and most hands go up. Dig into any individual case and it's often something closer to box-checking: a customer wants to know AI is on the roadmap, and "do you have an MCP server" is the easiest way to ask that question without knowing exactly what they'd do with the answer. That's not a reason to dismiss the request. It's a reason to find out what's behind it before you build anything. One useful gut-check: don't assume you know how sophisticated your own customer base is with AI tools. Teams have gone looking at their own usage data expecting one answer and found the opposite in both directions, assuming customers weren't ready for agent-driven workflows when they already were, and assuming demand was real when it turned out to be mostly hypothetical. Check the data before you build, and check it again after.

Use five questions to evaluate MCP at any stage

Saying "check the data" is easy. Doing it consistently, in a way that holds up whether you're deciding for the first time or reassessing three months later, is the actual work. That's what the five questions below are for: a repeatable way to separate a real case for MCP from an assumed one, instead of a gut check you run once and forget about.

Each question has two versions: one for deciding whether to build, one for checking whether what you already built is working. Find the version that matches where you are.

1. Who's actually driving this, and how do they work today?

Deciding: Is this a human-in-the-loop, exploratory use case, someone asking questions and pulling together a report, or does it need to run autonomously, at scale, unsupervised? Those are different problems with different tolerances for error. And not every end user wants an agent interface in the first place, regardless of what's technically possible. Plenty of workflows are still built around a person clicking through a UI.

Already live: Pull real usage data. Does it match the profile you designed for, or has usage quietly drifted toward something riskier, an exploratory tool now being used to trigger consequential actions nobody signed off on?

2. How much do determinism and auditability matter here?

Deciding: Mission-critical, regulated, or financial workflows need deterministic execution with a clear audit trail: a human or a policy layer checking the AI's proposal, not an LLM making the call directly. This is the category where a traditional, code-owned integration wins outright, no real debate.

Already live: Is your MCP layer quietly being asked to make writes or decisions it was never scoped for? That's the clearest signal something needs to move to a deterministic integration. It doesn't mean you shouldn't have built the MCP layer at all, only that it's being stretched past its design.

3. What's your actual integration surface, and who controls the client?

Deciding: If there's one internal agent you control, a full MCP server is usually more infrastructure than the problem needs. Direct tool-calling gets you there faster and with less to maintain. If multiple external AI clients you don't control all need the same capability, that's where MCP earns its value, because it centralizes auth and logic once instead of rebuilding it per client. And a sharper point worth remembering either way: MCP amplifies whatever API sits underneath it. A messy, undocumented API becomes a messy, undocumented agent tool. The protocol doesn't fix that. It just adds a layer on top of it. It's the same thing Kin Lane pointed out earlier: build the MCP on top of a well-designed, well-documented API and it inherits that. Build it on top of a mess, and you've just given an agent a faster way to reach the mess.

Already live: A high failure or retry rate is usually that same problem showing up in production: the underlying API wasn't coherent enough to begin with, and no amount of MCP polish fixes that. The fix is upstream.

4. What's your governance and stability posture?

Deciding: Weigh auth and permissioning carefully, along with how much protocol churn you can absorb. MCP is still a young, moving spec, and that has real costs for anything meant to last.

Already live: Credential sprawl, unclear scopes, or getting caught out by a spec change are maintenance signals, not evidence you made the wrong call. They're a reason to invest in hardening what you have (better scoping, better credential handling, real versioning discipline), not a reason to tear it down.

5. Is there an actual business case, or is this FOMO?

Deciding: Treat MCP like any other integration investment: it needs a business case, not just the discomfort of not having one. Separate the tactical question ("should we build this specific thing") from the strategic one ("is the way our category gets discovered actually changing because of agents"). Those are real, related, but different decisions, usually owned by different people.

Already live: Look back honestly. Did usage show up the way you expected when you built it? If it did, and for a lot of teams, it has, that's your answer: keep going, and start looking at where to invest next. If it didn't, that's useful information too, not a verdict. It tells you whether to pull back and re-evaluate scope, or whether the case was real all along and you just haven't pointed it at the right use case yet.

Turn your answers into a decision

Run through these questions and you land in one of three places. Double down, because the case is real and it's working: invest further, harden it, expand what it does. Hold steady, because it's doing its current, narrower job well and doesn't need more investment right now. Or add the deterministic integration underneath what you already have, because the workload or the opportunity has outgrown what an agent-driven layer should be carrying alone.

That third answer deserves its own callout, because it gets mistaken for a verdict against MCP when it's usually the opposite. We've heard from plenty of teams that are bullish on MCP, and they're right to be, who are still losing deals for a reason that has nothing to do with the agent layer: they don't have a reliable integration with the specific system a prospect actually needs connected. MCP earning real usage and integration coverage being a growth blocker aren't contradictory findings about two different problems. They're often the same finding. This usually isn't an either/or decision. It's a question of whether you're investing in both pieces, because leaning on one without the other is what slows growth down.

That third answer is also the most common endpoint regardless of which piece you built first. Teams that started with a traditional integration and later added an MCP layer on top for exploratory, agent-driven access tend to end up in the same place as teams that started with MCP and later had to go build the reliable sync underneath it. The steady state for most teams doing this well is both, doing different jobs. Not one replacing the other, and not one standing in as a stopgap for the other.

Design for agent experience, not just APIs and UX

Whichever mechanism you land on, you're now designing for a third kind of consumer, alongside end users and developers. End users get user experience. Developers get documentation and a well-designed API. Agents need something adjacent to both but not quite either: machine-readable schemas, discoverable capabilities, and tool descriptions written for something that can't ask a human for clarification mid-task. That's a real design discipline, not an afterthought bolted onto whichever interface you already had. It applies whether the access point is an MCP server or a well-documented API. The agent on the other end doesn't care which protocol it's using. It cares whether it can figure out what your service does and use it correctly on the first try. That's close to the same test Kin Lane described earlier: can an agent discover the tool, understand what it does, and finish a real task without a human stepping in? Design for that, and the choice of protocol becomes almost incidental.

Keep investing in the infrastructure underneath

Kin Lane's metaphor from earlier fits here: an MCP server is a new doorway onto the same house. Whichever way the five questions point for a given use case, the underlying layer doesn't change: the actual data syncing between systems, separate from whatever interface, agent or human, is asking for it. That layer doesn't get smaller or less important because an agent-facing layer exists on top of it. It gets more load-bearing, because it's now serving more kinds of requests than it was built for.

Take the report example from earlier. A customer's MCP use case is mostly "pull together a report," a good, low-risk fit for an agent-driven layer. But the report is only as good as the data underneath it. If the sync feeding that report is unreliable, runs on a stale schedule, or drops records when a field changes upstream, the agent will confidently generate a report from bad data, and nobody will know until it's wrong in front of an executive team that wants the numbers explained. The agent layer didn't cause that problem, but it will surface it faster and with more apparent authority than a dashboard would have. The same logic holds for any workflow you put an agent in front of: write operations that need to be idempotent, financial or inventory data that needs to be current to the minute, records that need to be reconciled across systems without drift. None of that gets easier because there's a conversational interface in front of it. It gets harder, because it now has to be right on demand instead of on a schedule someone's watching.

That's the case for treating integration infrastructure as something you invest in deliberately, in parallel with whatever agent-facing work you're doing. It isn't a commodity you can skip because a newer layer sits above it, and it isn't something a thin MCP wrapper can substitute for if the plumbing underneath was never solid to begin with. The teams accelerating fastest right now aren't the ones picking a side. They're the ones building both at once.

Run the same five questions at every stage

Run the five questions wherever you are: not built yet, mid-build because a customer asked and you're not entirely sure why, or months into production and meaning to check whether it's actually working. The questions don't change. Only the answer you're checking against does.