Dora NodaMCP crossed 97 million monthly SDK downloads in 2026 — a growth curve steeper than React's, which took about three years to reach the same number. The public registry PulseMCP counted 22,311 servers as of July 16, 2026, up from the 10,000-plus tally that made headlines back in March. By any download or server-count metric, the Model Context Protocol won its adoption argument months ago.
Almost none of those servers can deploy anything.
Pull up any registry and the shape is the same: a list_repos here, a get_deployment_status there, a query_table for the database, a search_invoices for Stripe. Read, read, read. The overwhelming majority of that 22,000-server ecosystem is lookups against GitHub, Slack, Postgres, and Stripe — tools that answer a question and change nothing. That's not a criticism; it's the easy 90% of the protocol's use case, and it's why MCP could scale this fast without anyone getting hurt.
A server that actually deploys or rolls back infrastructure is a different animal, and the read-only majority never had to build the parts that make it safe. Three things, specifically: idempotent handling of both deploy and rollback calls, a way to surface a build's in-progress state to a caller that can't poll a dashboard, and audit logging designed for a non-human caller from day one. None of the 22,000 servers doing lookups had to solve any of this. A deploy-and-operate server has to solve all three before its first production tool call.
Why Read-Only Was the Easy 90%
A read tool is naturally idempotent. Call get_deployment_status once, call it five times because the connection dropped and your agent retried — nothing changes on the fifth call that wasn't already true after the first. The MCP transport doesn't guarantee exactly-once delivery, and for a read tool that's fine, because "at least once" and "exactly once" produce an identical result when nothing is being written.
That property is why the first wave of MCP servers could ship fast and loose. GitHub's server can retry a list_pull_requests call as many times as a flaky Wi-Fi connection demands. Slack's can re-fetch a channel history mid-agent-session with zero downside. None of that engineering discipline transfers to a tool that says deploy or rollback, and that's exactly where the next stretch of MCP's growth is heading — Vercel shipped its first write tool in July 2026, eleven and a half months after its read-only launch, and Anthropic's own Claude Managed Agents pushed self-hosted sandboxes and MCP tunnels to general availability that same quarter. The ecosystem is visibly turning from "let an agent look things up" to "let an agent operate infrastructure," and the safety rails that made the read-only era boring don't come for free on the other side.
Requirement 1: Idempotent Deploys — and Idempotent Rollbacks
The fix for a retried write is the same one REST APIs settled on a decade ago: a client-supplied idempotency key. The agent generates a token before calling deploy, passes it as an argument, and the server deduplicates on that token — a retried call with the same key returns the original result instead of triggering a second deploy. 2026 production guidance on MCP servers is explicit that every write tool needs this, accepting client-generated request IDs and returning deterministic results for repeated calls with the same key.
High-impact tools get a second layer on top of that. Rather than executing immediately, a deploy call can return a confirm payload — a summary of what's about to happen — that only executes once the caller sends it back through a follow-up confirm_action call. That two-step pattern turns an agent's single malformed tool call into a preview instead of an accident.
Rollback needs the same treatment, and it's the sharper case. A retried deploy at worst repeats a deploy that already succeeded — annoying, not dangerous. A retried rollback is a different failure mode entirely: if the first call already reverted a service to the prior known-good version and a network hiccup makes the agent retry, a naive rollback tool re-executes "go back one version" and lands the service two versions behind the one it was trying to reach.
The fix isn't just an idempotency key on the call — it's making the rollback target an explicit, versioned state (rollback_to: deploy_id_4821) rather than a relative instruction like "undo the last one." An idempotency key dedupes the call; a versioned target makes the outcome well-defined no matter how many times that call lands.
Requirement 2: Surfacing "Still Building" Without a Dashboard
A human clicking deploy in a dashboard gets a progress bar for free. An agent calling a deploy tool gets nothing unless the server builds a way to ask "is it done yet" — and as of the July 28, 2026 MCP specification revision, it can't lean on a session to do that.
That revision is the largest the protocol has shipped: it removes the initialize handshake and the Mcp-Session-Id header entirely, so a remote MCP server can run behind a plain round-robin load balancer instead of needing sticky sessions or a shared session store. The tradeoff is that a server can no longer just remember "this connection is watching build #4821" the way a stateful session made trivial. The replacement, formalized as SEP-2567, is an explicit handle: the server mints an identifier — a build_id, the spec's own example is a basket_id — and hands it back as an ordinary return value. The caller passes that handle as a normal argument on every subsequent call.
For a deploy tool, that maps directly: deploy returns { build_id: "bld_4821" } immediately rather than blocking until the build finishes, and the agent polls status with a separate get_build_status(build_id) call for as long as it needs to. No long-lived connection, no session to keep alive across a control-plane restart, no dashboard to poll instead. The stateless-by-default direction the protocol just took isn't a constraint deploy tooling has to work around — it's the mechanism that makes "still building, check back" expressible without inventing a bespoke solution per server.
Requirement 3: Audit Logs for a Caller That Isn't a Person
A human operator's dashboard session already has an audit trail: browser login, IP address, click history, a support team that can ask "why did you deploy this" and get an answer. An agentic caller has none of that friction by default. It can execute hundreds of tool calls in a session, pattern-match across them in ways a human wouldn't, and do it all under whatever credentials the MCP server happens to accept — which is exactly the setup 2026 security writeups on MCP describe with the phrase "confused deputy": if a server can't answer who invoked this tool, when, and with what scope, it isn't a deploy server, it's a liability with an API.
The industry's response is now standardizing rather than ad hoc. The Interceptors Working Group, chartered in April 2026 with engineers from Bloomberg, Saxo Bank, and Nordstrom, is building a spec for validators and mutators that intercept every tool call — audit logging is one of the group's three named reference interceptors, not an afterthought bolted onto the protocol later. Anthropic's own Security Interest Group, chartered that June, scopes the requirement even more concretely: tamper-evident records of what a tool call did and under what authority, built for compliance review and incident response, not just a debug log a developer can tail -f.
For a deploy/rollback server specifically, that means every mutating call needs to log, at minimum, the calling agent's identity and scope, the exact arguments passed, the idempotency key used, the resulting state change, and a timestamp — recorded somewhere the agent itself can't retroactively edit. A read tool never needed this, because a bad list_repos call leaves no state to reconstruct. A bad deploy call does, and by the time a human asks "why is production down," the answer needs to already be sitting in a log, not something reconstructed from an agent's own (potentially hallucinated) account of what it did.
What a Real Deploy Tool Contract Looks Like
Put the three requirements together and a deploy tool's contract stops being a single RPC call. It becomes five pieces of surface area a read-only lookup tool never had to design:
- The caller supplies an idempotency key before the call executes.
- The server returns a
build_idhandle instead of blocking until the build finishes. - A
get_build_status(build_id)tool lets the caller check progress without a session. - A
rollbacktool takes an explicit versioned target rather than a relative "undo." - Every mutating call writes an immutable audit entry keyed to the calling agent's identity before it returns.
That's the actual gap between "MCP server" and "MCP server an agent can trust with production."
This is precisely the gap bex's own roadmapped MCP server has to close before it ships, and the three requirements don't land in the same order. Audit logging is closest to free — a Cluster API-backed control plane that already tracks deploy history for its human-facing dashboard just needs to attribute each entry to a calling identity instead of a browser session, no new storage layer required.
Idempotent deploy and versioned rollback are a genuine design decision, not a retrofit, precisely because a Render-compatible API's existing POST /deploys endpoint wasn't built assuming a caller might legitimately retry with the same intent. Handle-based progress-polling is the one requirement the July 28 spec revision handed the whole ecosystem for free — a platform building against the current protocol gets SEP-2567's pattern by default, instead of inventing a bespoke long-poll or webhook scheme the way a deploy server built two years ago had to.
None of that is exotic engineering. It's the same idempotency-key, versioned-target, and audit-trail discipline that any API serving unattended callers has needed since long before MCP existed. What's new is that the caller on the other end of a deploy tool is now routinely an agent running unsupervised for hours at a time — and the read-only 90% of the MCP ecosystem simply never had to find that out the hard way.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API an agent can call directly. Star the repo on GitHub or deploy your first app today.
