Dokploy Shipped 508 MCP Tools. The Community Deleted 95% of Them.

Dokploy's official MCP server exposes 508 tools across 49 categories — one tool per API endpoint, complete coverage of the self-hosted PaaS. The community's response was to delete almost all of them: rival servers cover the same API with 13 to 28 tools and measured token savings near 90%. Somebody is wrong about how to design an infrastructure MCP server, and the receipts are public.

The core of the dispute fits in one table. In August 2026, the author of a curated Dokploy MCP server measured both sides the same way — start each server, call tools/list over stdio, count the serialized schema bytes, divide by four for a rough token estimate:

A few reconciliations before anyone accuses the table of cherry-picking. The official README advertises 508 tools; the 546 figure is the live-measured count at Dokploy v0.29.14, when the OpenAPI spec held exactly 546 paths. By v0.30.2 the spec had grown to 597 paths — the mirror grows with every release, so any fixed count is stale within a version. The curated side has moved too: it now ships 28 tools at 48,452 bytes (~12.1k tokens) tracking v0.30.2.

And "deleted 95%" is the count cut (546 → 22 is 96%); the byte cut is 88%. Bytes are what drive the token budget, which is the number that matters — but both point the same direction.

So the official server spends more than a third of a 200k-token window before the agent reads a single line of your infrastructure state. That is the token-budget backlash in one sentence. The rest of this post is about why the obvious design produces that number, what the curated alternative actually looks like, and the design rules the next infrastructure MCP should steal.

Why one-tool-per-endpoint is the obvious first shape​

Give this design its due: it is the shape a code generator produces, and code generators are how API coverage gets shipped. Dokploy publishes an OpenAPI spec; a generator walks every path and emits one tool per endpoint. Coverage is complete by construction. When v0.30.2 added Docker volumes, images, networks, overview, DNS providers, and vault providers, the official server picked them up with zero hand-authoring. No curation meeting, no prioritization, no drift between the API and the agent surface. For a fast-moving project, that is a genuine operational virtue.

It is also the shape that requires no opinions about how agents work. Each tool does exactly one thing, takes exactly the parameters the endpoint takes, and returns exactly what the endpoint returns. If you believe the model is smart enough to pick the right tool out of hundreds — and model vendors keep telling you context windows are growing — then maximalist coverage looks like maximalist capability.

The problem is that every one of those schemas loads into the model's context before you ask your first question. MCP has no lazy tool loading in the base flow: the client calls tools/list, the server returns all definitions, and those definitions ride along in the system prompt of every subsequent turn. Coverage you never use still costs context on every call. That is the input half of the bill. The output half is accuracy.

Where the mirror breaks​

Three failure modes, each with a number attached.

Upfront context burn. The ~74k-token figure above is the headline, but scale it to a realistic setup. Nobody connects one MCP server. Five servers at even a fraction of Dokploy's size, and the tool definitions alone can exceed 100k tokens — spent before the agent has seen your prompt, your repo, or your cluster state. Anthropic's own documentation for its tool-search feature puts a receipt on a typical multi-server setup: 58 tools costing roughly 55,000 tokens of definitions. Dokploy's official server is nearly ten times that tool count by itself.

The accuracy cliff. Also from Anthropic's docs: Claude's ability to pick the right tool degrades once you exceed roughly 30–50 available tools. Past that point, overlapping names (restart vs redeploy vs rebuild, six database engines each with their own create/list/delete) turn tool selection into a guessing game, and mis-selection burns not just tokens but real API calls against production infrastructure. A 546-tool surface is an order of magnitude past the cliff. The generator optimized for coverage; the model needed curation.

Client caps. MCP clients impose their own limits on how many tools they will even register, and those limits vary by client — some fail silently, some truncate, some refuse the server outright. A server that assumes "the client will figure it out" exports its design problem to every client author's allowlist. The curated forks exist partly because real users hit these walls in Cursor, Claude Code, and Claude Desktop, not because anyone disliked completeness in the abstract.

None of this means coverage is worthless. It means coverage priced at 74k tokens and 10x past the accuracy cliff is coverage the agent cannot actually use.

The curated answer: one tool per category, actions as enums​

The community's counter-proposal is simple: one tool per API category, with an action enum selecting the operation. The earliest generation of this idea shipped 13 tools against an official server that then had 67; the current generation ships 22–28 tools against 546+. The ratio has held across versions even as both sides grew.

Concretely, here is the shape. Instead of 94 database tools (six engines × every CRUD operation), the curated server exposes one:

{
  "name": "dokploy_database",
  "parameters": {
    "dbType": "postgres | mysql | mariadb | mongo | redis | ...",
    "action": "list | get | create | update | remove | ...",
    "...": "remaining params optional per action"
  }
}

One tool, 17 actions, all six engines. The same compression repeats everywhere: 31 application tools become one tool with 23 actions, 54 settings tools become one tool with 5 actions, 9 project tools become one tool with 6 actions.

Two details make this work rather than merely shrink. First, the per-tool schemas get bigger, deliberately: median tool schema rises from 388 bytes on the official server to 1,131 bytes on the curated one, because descriptions now carry the workflow knowledge that prevents failed calls — which service id pairs with which databaseType, which actions need which companion parameters. You trade 500 small, dumb schemas for two dozen large, instructive ones. Second, the curated count is not 49 (one per official category) because curation merges what the API splits: six database engines become one tool, and the covered surface is the deploy-and-operate path self-hosters use daily rather than every administrative corner.

If 49 categories mapping to 22 tools feels lossy, that is the honest version of the trade-off — which is the next section.

The honest trade-offs​

Curation wins the token math. It does not win everything, and a design post should say so.

Bigger schemas, weaker discoverability. A 1,131-byte median schema with 23 actions is a small manual the model must read correctly. Action enums inline every operation's parameters as optionals, so the model sees a wall of maybe-relevant fields instead of one crisp signature. For simple CRUD this is strictly better; for an endpoint with genuinely complex inputs, the generated one-tool version can be easier to call correctly. The curated author bets that workflow prose in descriptions outweighs this. That bet is plausible, not proven.

Hand-curation drift. The generator tracks the spec for free — v0.30.2's six new categories arrived without human effort. The curated server tracks them by hand: someone reads the new endpoints, designs the actions, writes the workflow prose. Every release is a curation chore, and a stale curated tool is worse than a verbose generated one because it silently lacks the new capability. The curated forks mitigate this by covering the stable deploy-and-operate core, but "we cover what matters" is a judgment call that rots.

The escape hatches change the calculus. Three newer patterns attack the same problem from different sides. MCP tool search defers loading definitions until the agent needs them. Programmatic tool calling lets the agent reach hundreds of tools through a code interface instead of prompt-stuffed schemas. Skill-based routing (one Dokploy fork claims 80–97% savings with ~120 tokens at session start) teaches the model where to look rather than handing it everything. All three are client- or ecosystem-dependent: a server cannot assume the client supports them. But they set the direction — progressive disclosure beats both "everything upfront" and "hand-curated subset" once clients catch up.

So the fair summary: one-tool-per-endpoint wins on coverage freshness and loses on usable context; curated tools win on usable context and lose on maintenance and edge coverage; progressive disclosure may obsolete the debate but is not universally available yet. A server shipping today has to pick from the first two.

Five design rules for the next infrastructure MCP​

Apply the evidence above to a self-hosted PaaS designing its agent surface from scratch — say, a Render-compatible API that wants deploy-from-chat to actually work. Five rules, each tied to a number from this post:

1. Budget tools/list bytes, not tool count. The budget that matters is serialized schema bytes (÷4 ≈ tokens), because that is what loads upfront. Set a ceiling — 50KB keeps you near ~12k tokens — and measure it in CI the way the curated fork did: start the server, call tools/list, count bytes. A count limit alone lets 500 tiny tools pass while blocking 30 good ones.
2. Stay under the accuracy cliff. Anthropic's 30–50 tool guidance is the closest thing the industry has to a load rating. Design the surface to land under it with headroom for the user's other servers, since nobody connects just yours. If your API has 500 endpoints, that constraint alone forces the category-plus-action shape.
3. Consolidate operations under workflow tools. Anthropic's tool-design guidance says it directly: tools can consolidate functionality, handling multiple discrete operations under the hood. Merge verb pairs and engine variants into single tools with enums, and spend the saved budget on descriptions that encode workflow knowledge — the parameter pairings and ordering constraints that prevent failed calls against live infrastructure.
4. Cover the deploy-and-operate core first, admin corners last. The curated servers earned their keep by covering projects, apps, databases, domains, deployments, and servers — the daily path — before SSO settings and notification providers. Sequence coverage by operator frequency, and let the long tail wait for progressive disclosure rather than bloating day one.
5. Track the spec mechanically, curate the surface by hand. The generator's one true win is zero-drift coverage. Keep it — generate the full mapping internally, then expose the curated subset and diff the two on every release so new endpoints surface as curation tasks instead of silent gaps. Freshness automation plus human judgment beats either alone.

None of these rules requires guessing what clients will support next year. They all work against today's MCP: every schema loads upfront, accuracy degrades past a few dozen tools, and bytes are the budget.

The mirror was never the product​

The deeper lesson is that an API reference and an agent surface are different artifacts that happen to read the same spec. Dokploy's OpenAPI spec is documentation for humans who search it; its MCP server is a toolbox for a model that must hold all of it at once. Generating the second from the first feels efficient because it reuses work, but it exports the wrong property — completeness — into a medium priced by the token and graded on selection accuracy. The community forks are not anti-coverage. They are the market discovering that for agents, the curated subset is the coverage that counts.

Measure your tools/list. Divide by four. Ask whether the agent can still see your infrastructure past your toolbox. If the answer is no, you know which 95% to cut.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agent-operated infrastructure is the bet: a Render-compatible API with an MCP surface designed under the token budget from day one, not mirrored from the spec after the fact. Star the repo on GitHub or deploy your first app today.