Dora NodaAn October 2026 audit of the Model Context Protocol lands the most honest rule of thumb the ecosystem has produced all year: build one MCP server per system, and the protocol pays for itself once an agent touches three or more systems. Past that line, the audit says, tool sprawl, auth surface, and versioning become the real costs — and the numbers behind that claim are public. Here is the part nobody has spelled out: the rule cuts both ways. If your deploy agent touches five systems, MCP earns its keep — and your deploy server is only one guest in a crowded context window, so it has to be scoped like one.
This post applies that math, concretely, to a self-hosted PaaS designing its deploy MCP server: count the systems, spend the token budget, and draw the line where "every endpoint is agent-callable" stops being leverage and starts being the breakage the audit warns about.
The deploy-loop budget, worked end to end
Start by counting systems the way the audit counts them — one server per system. A deploy agent that ships a real app touches at least five: the git provider, the container registry or build service, the platform API itself, DNS and TLS for the custom domain, and observability for logs and status. Qovery's own accounting of the shipping path puts it at 5 to 8 separate systems per deploy. Five clears the audit's three-system bar comfortably, so MCP earns its keep here. That is the good news, and it is the last uncomplicated sentence in this post.
Now the budget. Community measurements from late September put a three-server setup — GitHub, Slack, Sentry — at roughly 143,000 tokens of a 200k context window, spent on tool definitions the agent may never call. GitHub's server alone exposes about 93 tools costing around 55,000 tokens, re-sent every turn. Three servers, and the agent has roughly 57k tokens left to actually work in.
Your deploy server does not arrive into an empty window. It arrives fifth.
So give it an allowance. If the other four servers in a deploy loop average even 25k tokens each — a conservative number next to GitHub's 55k — that is 100k spoken for before the deploy server says a word. Holding 40–50k back for the task itself, the prompt, and tool results leaves the deploy server something like 10–15k tokens of definitions. That is the budget. Everything below is about spending it without blowing it.
A tight deploy/rollback/logs/status surface fits easily. Twelve tools cover the daily path:
deploy rollback get_status get_logs list_services get_deploy
scale restart set_env create_preview delete_preview add_domainHow much context does that cost? Measured medians from the Dokploy token-budget teardown put curated, instructive tool schemas at about 1.1KB each — deliberately larger than generated stubs, because descriptions carry the workflow knowledge that prevents failed calls. Twelve tools at 1–2KB each is 12–24KB of tools/list payload, or roughly 3–6k tokens at the usual bytes-divided-by-four estimate. That lands at half the allowance with room to grow, and it stays an order of magnitude under the accuracy cliff: Anthropic's tool-design guidance puts correct tool selection degrading past roughly 30–50 available tools, a number the whole 200k-window debate has to respect regardless of budget.
Note what the list excludes on purpose: SSO settings, notification providers, billing, user management, audit-log export — the admin long tail. Those endpoints exist, they are documented, and the agent does not need them to ship. Every one of them added back would cost context on every call, widen the auth scope, and add a versioning obligation, which is exactly the audit's breakage ledger. The line is not "deploy verbs only" out of minimalism. It is twelve tools because the window is shared with four other servers.
The same budget at a million tokens
The obvious objection: 200k windows are last year's constraint, and 1M-token models make this whole exercise quaint. Run the sensitivity and the objection half-fails.
At 1M tokens, the 143k three-server setup drops from 72% of the window to about 14%. Dokploy's official 546-tool mirror, which burns roughly 37% of a 200k window, falls to about 7%. The context constraint genuinely relaxes — a server that was unshippable at 200k becomes merely expensive at 1M. If tokens were the only cost, bigger windows would repeal the budget.
But tokens were never the only cost, and the other two do not scale with window size. The accuracy cliff is about the model's ability to pick the right tool out of overlapping names, not about fitting schemas into memory — 546 tools is ten times past the 30–50 guidance whether the window is 200k or 2M. And the auth surface plus versioning burden are per-tool obligations: each endpoint the agent can call is a permission to scope, a behavior to keep stable across releases, and a new way for a confused model to touch production. Cloudflare's MCP team reached the same conclusion from the far end of the telescope: instead of exposing every API endpoint as a native tool — a surface they estimate would exceed one million tokens of tool definitions — they ship a search-and-execute pattern where the agent finds the capability first and loads its schema on demand.
So the sensitivity analysis has a clean result: at 200k the budget binds on tokens, at 1M it binds on accuracy and governance, and the twelve-tool ceiling holds either way for different reasons. Budget like a guest at any window size.
Where leverage becomes breakage
The audit's breakage half deserves the same concrete treatment as the cost half, because "tool sprawl, auth surface, and versioning" is abstract until it is attached to deploy verbs. Each has a deploy-server price tag.
Sprawl is a per-turn tax. Every tool definition rides along in the model's context on every request, used or not — the audit cites a scan of 3,105 public servers confirming the pattern, with single heavy servers measured above 10,000 tokens each. The marginal endpoint is never free: it costs its schema bytes times every turn of every session, forever. That is why the budget above is denominated in bytes, not vibes, and why "we might need it someday" is the most expensive sentence in MCP server design.
Auth surface scales with verbs, not systems. The NSA's AI Security Center said the quiet part out loud in its May 20, 2026 guidance on MCP, warning that adoption has outpaced the protocol's safeguards and naming uncontrolled automated tool selection and missing input screening as primary gaps. Applied to a deploy server, the audit's checklist translates directly: narrowly scoped tokens per server, human approval for deploy and rollback, every tool call logged into normal security monitoring, and — the sharpest rule — read-only tools and write tools on separate servers. Twelve tools split into a read server and a gated write server is two small blast radii. Five hundred tools on one server with one credential is ambient authority wearing a tool belt.
Versioning is the cost nobody budgets. A generated mirror tracks the API spec for free and rots the agent surface with every release; a curated surface stays usable and costs a human review on every release. The honest answer, which the Dokploy teardown already landed, is to generate the full mapping internally and expose the curated subset, diffing the two each release so new endpoints surface as curation tasks instead of silent gaps. Twelve exposed tools with a mechanical diff behind them is a maintainable promise. It is also the shape that lets the admin long tail wait for progressive disclosure — load-on-demand definitions — instead of bloating day one.
When not to build it at all
The audit earns trust with its skip rule, so this post keeps it: one agent, one API, a fixed workflow — skip MCP and make the direct function call. It is simpler and cheaper, and no protocol absolves you from that comparison.
Concretely: a nightly job that redeploys a staging service from main and posts the result to Slack is two API calls with no branching, no tool selection, and no second agent. Wrapping that in an MCP server buys standardization nobody consumes and bills context nobody needed. The three-system rule is a floor, not a ceiling — below it, the direct call wins, and the governed-tools-versus-raw-keys decision we published alongside this piece says the same from the governance side. Build the deploy server for the five-system loop where it earns its keep, not the two-call cron where it is ceremony.
Scope it like a guest
The audit's rule of thumb, applied all the way down, is one sentence: your deploy server is one of five servers in the window, so twelve workflow tools at a few thousand tokens is the whole budget, and everything past that is breakage you chose. Count the systems to justify MCP at all, spend bytes like they repeat every turn — because they do — split reads from writes, approve the destructive verbs, and let the admin tail wait. The protocol pays for itself at three systems. It starts charging interest past thirty tools.
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 deploys are the bet: a Render-compatible API with a deploy MCP surface scoped 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.
