Why 22 MCP servers is worse than one workflow

A developer on Hacker News recently announced a complete suite of 22 MCP servers to boost productivity. The replies were a mix of admiration and quiet dread, because anyone who’s run software in production did the same mental math: that’s twenty-two things to authenticate, twenty-two things to monitor, and twenty-two things to update the next time a vendor changes an endpoint. The count looks like capability. It’s actually overhead wearing a capability costume.

The reframe that fixes this is short. The right number of MCP servers isn’t the number of tools your agents need - it’s the number of processes you want them to take part in. That distinction is most of how AI actually slots into the systems a company already runs, and almost nobody designing agent stacks gets it right on the first pass.

Count the servers, then count the upkeep

Each MCP server is a small standing service, and standing services have a fixed tax no matter how trivial the tool inside them. It needs an identity and credentials. There’s logging to wire up, or you’re blind when something misfires. There’s a deploy and a place to run it. And it gets patched every time the API underneath it moves. None of that is about the tool the server wraps. It’s the price of running a server at all, and you pay it per server, every server, forever.

So twenty-two single-purpose servers isn’t twenty-two times the power. It’s twenty-two auth setups, twenty-two log streams nobody fully reads, and twenty-two update cycles that drift out of sync the moment one of them gets behind. The first one feels clean. The tenth is a chore. By the twentieth, the upkeep is the project, and the actual work the agent does is a rounding error against the maintenance.

Watch how the tax shows up in practice. A vendor ships an API change on a Tuesday. Now somebody has to figure out which of your twenty-two servers wraps that vendor, update it, redeploy it, and confirm the three agents that depend on it still work. That’s a half-day, and it lands again next month from a different vendor. Meanwhile a token rotates and one server starts silently returning auth errors that nobody catches until an agent run fails downstream, because who’s reading twenty-two separate log streams? The single-script-per-tool trick that felt elegant for the first connection becomes a standing maintenance rota the moment there are twenty of them, and nobody on the team raised their hand to own it.

Here’s the question worth sitting with before you spin up server number three.

Did you add capability, or did you just add another thing to keep alive at 2am?

A mesh is a symptom, not a cure

The ecosystem already noticed the pain, and its first instinct is telling. Within a year of MCP launching, people started building tools whose entire job is managing the other tools. One Show HN introduced MCP Mesh, pitched plainly as “one endpoint for all your MCP servers.” Docker shipped an MCP Toolkit and Gateway because, in their own words, “running MCP servers locally creates operational friction” - configuring each server for every application, managing untrusted code, handling updates by hand. Their fix is centralized management: set it up once, point every client at it.

Read that carefully and the lesson inverts. A meta-layer that exists to corral your servers is proof you made too many servers. The mesh is a real and useful patch, the same way a load balancer in front of forty microservices is useful. But it’s a patch on a sprawl problem, not a reason the sprawl was a good idea. You can spin up a gateway to herd twenty-two servers, or you can not have twenty-two servers to herd. One of those is architecture. The other is cleanup.

And the gateway isn’t free either. It’s another standing service - one more thing to run, secure, version, and debug at 2am when an agent can’t reach a tool and you’re now tracing through a routing layer on top of the twenty-two servers it fronts. You added a component to hide a complexity problem, which is a fine trade when the complexity is genuinely irreducible, and a bad one when you created it yourself by slicing too thin. The teams that reach for a mesh early are usually solving the wrong problem with real effort. The cheaper fix is upstream, in how many servers exist in the first place.

A gateway manages the sprawl without ever undoing the decision that made it.

This is the same shape as the middleware that AI is steadily making obsolete: a layer that only justifies itself because an earlier choice multiplied the number of connections somebody has to maintain. The honest move is to question the multiplication, not to get better at managing it.

Pick the unit: a tool, or a process?

So if not “one server per tool,” then what? Group by the process the agent is actually doing. A real piece of work - onboarding a vendor, closing the books, handling a support escalation - isn’t a single tool call. It’s a sequence of related ones that share context, run in an order, and answer to the same owner. That sequence is the natural boundary for a server, because the tools inside it already belong together.

Take vendor onboarding. The agent might need to read an intake form, check the vendor against a watchlist, create a record, request a document, and notify an approver. That’s five tools. You could publish five single-tool servers and then write glue to make them cooperate, or you could expose all five through the one server that already represents the onboarding process - where they share the same identity, the same log, and the same definition of what “done” looks like. The process supplies the context that loose tools lack, which is exactly the gap that makes a bare agent improvise instead of execute.

The split-by-tool version doesn’t just cost more upkeep, it loses the thread. When those five capabilities live on five servers, nothing holds the run together: the watchlist server has no idea which onboarding it’s serving, and the approval server can’t see what the intake step found. You end up rebuilding, in glue code, the shared state the process already had for free. Now picture a support escalation instead - read the ticket, pull the customer’s history, check entitlements, draft a response, open an incident if it’s severe. Same story. Those five steps are one process with one context, and splitting them across servers means every server gets a thinner, blinder slice of the picture. Group them by the work and the context travels with them.

A question that keeps coming up when teams show us their agent stack is some version of “why does this feel so heavy?” The answer is almost always that they sliced by capability when they should have sliced by process. Tools grouped by the work they belong to need one auth story and one audit trail. The same tools scattered across a dozen servers need a dozen of each, plus a mesh to pretend they’re one thing again.

One server, many tools, one place to govern

Does the process-as-unit model actually hold up in production? Tallyfy’s own setup says yes. The authenticated MCP server it runs exposes 100+ tools through a single endpoint, grouped by the workflow areas they belong to rather than scattered across a hundred standing services. It’s listed as a live, production server on the official registry, and an agent connecting to it gets one identity to manage, one place where every call is logged, and one surface to secure. That’s not luck. Turns out, when the tools live inside a workflow platform, the workflow was the organizing unit all along.

Notice what that does to the upkeep math from earlier. When a capability changes, there’s one server to update, not a hunt through twenty-two to find which one wraps it. When a security review asks what an agent can touch, the answer is one scoped surface with one audit log, not a spreadsheet of services nobody fully maps. The hundred-plus tools didn’t vanish - they just stopped each demanding their own standing service, because the process they belong to carries them.

One server, one identity, one log is the upside here, not a limitation.

One thing to keep straight, because it trips people up. The authenticated mcp.tallyfy.com server, with its 100+ tools, is a different thing from the four small read-only tools the tallyfy.com website exposes to in-browser agents - search a template, explain a template, schedule a demo, explain pricing. Those website tools are deliberately tiny and need no login. The authenticated server is the real surface where an agent does work on your behalf, and it’s the one that proves the point: a single governed server can carry a lot of tools when a process holds them together. Collapsing the auth and the logging into one surface is also what makes the per-tool authorization that most deployments miss tractable - you can’t enforce least privilege across twenty-two scattered servers nearly as cleanly as across one.

Fewer servers also shrinks the attack surface. Every standing endpoint is a door, and twenty-two doors is twenty-two things to keep locked, which is the kind of math that turns into the security gaps that show up within weeks. One server, scoped to a process, is one door with one lock and one log of who came through.

How many servers do you actually need

Stop counting tools and start counting processes. Walk your real operations and list the workflows you want agents to take part in - the recurring, defined ones with an owner and a sequence. That list, not your tool inventory, is roughly how many MCP servers you should be running. Most teams find the number is small, because a handful of processes covers the bulk of the work agents are actually trusted with.

Run the exercise honestly and it’s almost deflating how short the list gets. A mid-sized operations team might want agents in vendor onboarding, support triage, invoice handling, and maybe employee provisioning. That’s four processes. Four servers, each a coherent surface, each with its own clear owner and audit trail. The 22-server version of that same scope took every tool those four processes touch - the CRM read, the ticket write, the ledger lookup, the directory call, all of them - and gave each its own standing service. Same capabilities, five times the surface to keep alive. The process list is the natural ceiling, and it sits far below the tool count almost every time.

The contrast with the 22-server approach isn’t subtle. Tools grouped by process give you a few servers, each one a coherent surface you can secure and audit as a unit. Tools split by capability give you a long list of single-purpose services, a mesh to manage them, and an auth-and-logging tax that compounds with every addition. The reframe is the same one behind running MCP inside a defined workflow rather than as raw tools: the protocol stays small and the process carries the weight.

None of this means MCP is the problem. The protocol works exactly as designed. The problem is treating every tool as if it deserves its own server, when the thing that actually deserves a boundary is the process. Count your processes. That’s your server count. Everything past that is sprawl you’ll be paying for long after the demo that justified it.