Dora NodaAn MCP server that can run deploy, rollback, and scale against a real app is a genuinely useful thing to hand an AI agent. Running it as a local stdio subprocess next to your editor is also, structurally, the safest possible way to do it: the process lives and dies with your session, the only credential in play is whatever your own shell already has, and nobody but you can ever call it. That entire safety story is a side effect of it never leaving your machine — and the moment a teammate, a CI job, or another agent needs to call the same tool, that side effect disappears. Everything it was quietly buying you has to be rebuilt on purpose, in code, before the server is allowed anywhere near a network socket.
This is a walkthrough of exactly what has to get rebuilt — line by line, not in the abstract — when an infrastructure-control MCP server moves from a process one developer launches to a service an entire team, and their agents, can reach.
The Transport Switch: stdio Under Your Editor vs Streamable HTTP Under a Team
The two transports the current MCP spec actually recommends are stdio for local and Streamable HTTP for everything else — the older HTTP+SSE transport is deprecated, so "remote" effectively means Streamable HTTP today. The difference isn't cosmetic:
stdio (local) | Streamable HTTP (remote) | |
|---|---|---|
| How it runs | Spawned subprocess, talks JSON-RPC over stdin/stdout | Long-lived service behind a URL, one HTTP endpoint (POST + optional SSE) |
| Overhead | ~1ms, no network stack involved | ~10–50ms under load; benchmarks of shared-session Streamable HTTP deployments show ~290–300 requests/second sustained at 100% success, versus 33–36 RPS when every request opens a new session |
| Who can call it | Whoever launched the process | Any client that can reach the URL |
| Lifecycle owner | The OS, implicitly, when the parent process exits | Whoever operates the service, explicitly, forever |
That last row is the one that matters here. Against the latency of the LLM call surrounding a tool invocation — typically hundreds of milliseconds to seconds — the 10–50ms transport overhead is close to noise. The real cost of going remote isn't latency. It's that four things stdio gave you for free now need an explicit owner.
Auth Stops Being Optional
A local stdio server has no auth story because it doesn't need one — the operating system's process boundary is the security boundary. There's no login step because there's nothing to log into; whoever can launch the process already has whatever permissions the process has.
A remote infrastructure-control MCP server doesn't get to skip this, and as of the November 2025 MCP spec revision it isn't allowed to try. Any internet-reachable MCP server must implement OAuth 2.1 with PKCE, and only the S256 challenge method — the plain method OAuth 2.0 used to permit is explicitly banned. Two more requirements ride along with it:
- Protected Resource Metadata (RFC 9728) — the server must respond to an unauthenticated call with an HTTP 401 and a
WWW-Authenticateheader pointing to a metadata document that names the authorization server clients should talk to. - Resource Indicators (RFC 8707) — every token request must specify which server it's for, and the MCP server must verify a presented token was actually issued for it. Without this, a token stolen from or leaked by one MCP server could be replayed against a different one.
None of that exists in the local version. A team standing up a remote deploy/rollback MCP server isn't just adding a login screen — it's standing up an OAuth 2.1 authorization server (or wiring into an existing one), publishing a metadata endpoint, and validating token audience on every call, before the first legitimate request is served.
Write-Scoping: From "Whatever My Shell Can Do" to deploy:write
Locally, permission is whatever your own credentials already allow — if your shell can run bex deploy, so can the agent sitting next to it, because it's using your session. There's no separate scoping layer because there's only ever one caller, and that caller is you.
Remotely, a deploy-capable tool needs its own, narrower permission model, and it needs one per action rather than one per server. The pattern that shows up consistently in production MCP deployments is scoped, tool-level permissions — deploy:write, rollback:write, scale:write as distinct grants rather than one admin-shaped API key — checked twice: once when the agent asks what tools exist (so an under-scoped caller doesn't even see rollback in its tool list), and again when it actually calls one. Best practice starts an agent at the narrowest scope that lets it do its job and grants more only when a specific task needs it, precisely because the blast radius of a leaked or misused token is bounded by what that token's scope actually allows.
This is also where "agent," not just "remote caller," matters concretely. A human operator hitting an expired token gets an interactive re-auth prompt and moves on. An agent mid-task doesn't have a browser tab to complete an OAuth redirect in — it either has a long-lived scoped credential provisioned for exactly this job, or it stalls. That pushes teams toward narrower, longer-lived, more tightly audited scopes for agent callers specifically, not the same broad session a human would casually accept for convenience. A deploy:write grant that's fine for a person clicking through a dashboard is a much larger liability handed to a fully autonomous loop that will use it unattended, at any hour, without a human noticing it happening in real time.
Statelessness, Scaling, and the Retry an Agent Makes That a Human Wouldn't
A single local stdio process never needs to scale — there's one caller, so one process is exactly the right number. A remote infrastructure-control server, by design, needs to serve a whole team plus however many agents are running concurrently, which means running more than one instance behind a load balancer. That's where MCP's stateful session design has historically bitten teams hardest: a session gets created on one pod, and the next request from that same client lands on a different pod with no memory of it, so horizontal scaling required sticky routing pinning a client to one instance, or an external store like Redis to share session state across replicas — extra infrastructure a single local process never had to think about.
The protocol itself is moving to remove that requirement. MCP's 2026 direction is a stateless core: no handshake, no session ID at the protocol layer, which means any request can land on any server instance without sticky routing or a shared session store. That's a meaningful simplification for a deploy/rollback MCP server that needs real horizontal scale — but it changes, rather than eliminates, the retry problem an agent creates that a human wouldn't. A person who issues bex deploy and gets a timeout will look at a dashboard before trying again. An agent that gets a timeout is liable to retry the call immediately, and once the session-affinity requirement is gone, that retry can land on a different replica than the one that may have already started the deploy — which means idempotency on the deploy/rollback tool itself (a request ID the server de-dupes on, not just statelessness at the transport layer) has to be part of the design, not an assumption inherited from "well, it's stateless now."
The Server Becomes Infrastructure: Uptime, Audit, and a Rollback Plan With a Number On It
If a local stdio process crashes, exactly one developer notices, and the fix is restarting their own agent session. Nobody pages anyone. Nothing was down for anyone else, because there was never an "everyone else" in the first place.
A remote deploy/rollback MCP server going down is an outage of the control plane — every agent and CI job that would have called it is now blocked, at the same time, with no local fallback. That single fact pulls in a list of operational obligations a local server never had to answer for:
- It needs monitoring and an on-call story, the same as any other production service — because it now is one.
- It needs an audit log, not optionally. OWASP's MCP Top 10 names "Lack of Audit and Telemetry" (MCP08:2025) as a standing risk category precisely because MCP itself ships no built-in centralized log storage or retention — that has to be added, not assumed.
- It needs to avoid maker-mode credentials — a fixed, author-level token baked into the server that every caller inherits regardless of their own actual permissions. That pattern silently erases whatever per-action scoping the server otherwise enforces, because every agent ends up acting with the server's full authority instead of its own.
- It needs a tested rollback and revocation plan, not a hoped-for one. Production MCP security guidance treats a rollback plan with a confirmed recovery time — 15 minutes is the bar commonly cited — as a pre-deployment checklist item, on the same footing as the audit logging itself being tested with sample queries before go-live.
None of these are exotic asks. They're the standard operational baseline for any production service that can change infrastructure state. The only thing that changed is that the MCP server now qualifies as one.
Why an Infrastructure-Control MCP Server Can't Treat This as an Afterthought
A read-only "search my internal docs" MCP server can reasonably bolt most of this on later. If its auth is sloppy for a month, the worst case is someone reads a document they weren't supposed to. The blast radius is bounded by what the tool can do, and a read-only tool can't do much.
None of that is true for a server whose tool list includes deploy, rollback, and scale. Every gap this walkthrough covered — an unscoped token, a missing audience check, a maker-mode credential, an un-tested rollback plan — turns directly into "an agent (or someone impersonating one) can change what's running in production, and there's no clean way to prove what happened or undo it fast." A platform whose MCP server is the infrastructure control plane, rather than a convenience layer sitting in front of one, has to treat OAuth 2.1, per-action scoping, statelessness-aware idempotency, and audit logging as day-one requirements for that server — the same way it would treat them for any other API with deploy authority — because by the time an agent is calling it in production, it already is one.
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 and an MCP surface built for agents as first-class operators from the start. Star the repo on GitHub or deploy your first app today.
