Dora NodaEvery "best cloud platform" listicle in 2026 is a stealth list of MCP servers. That line is Railway's, from its May 2026 ranking of cloud platform MCP servers, and it names the shift plainly: the question teams ask about a deploy platform is no longer just "how fast can I ship from git?" but "can a coding agent drive this platform end to end?" Railway calls 2026 the agentic-PaaS moment, and the numbers back the framing — the Model Context Protocol sits at roughly 97 million monthly SDK downloads, more than 9,400 public servers, and a December 2025 donation to the Linux Foundation that moved it under the Agentic AI Foundation alongside OpenAI and Block.
Three independent convergences make the pattern impossible to miss. JetBrains' TeamCity — the most enterprisey CI/CD server imaginable — is now fully accessible via MCP and CLI, so agents configure pipelines, trigger builds, and analyze failures without leaving the IDE. Dooor OS ships an MCP server that exposes its whole workspace — apps, deploys, git, databases, agents, monitoring — as tools for Claude Code and Claude Desktop. And generic setup playbooks now exist for wiring coding agents to infrastructure MCPs, which is what happens when a pattern stops being per-product novelty and starts being assumed knowledge.
Here is the verdict up front, worked out in full below: a git-push PaaS's MCP server needs a minimum tool inventory covering the whole deploy loop — deploy, roll back, tail logs, read status, manage env vars, provision databases, configure domains — and anything less is a demo that stalls the first time an agent leaves the happy path. What separates the demo from a production-safe interface is not more tools but four controls: approval-gated mutations, per-session identity with per-environment scoping, dry-run modes, and idempotent operations.
| A PaaS MCP must expose | Why an agent stalls without it |
|---|---|
| Deploy (from git ref to a live service) | The core loop; without it the MCP is read-only commentary |
| Roll back to a known-good build | Incident response is the workflow agents get pointed at first |
| Tail and page through logs | Debugging without logs is guessing; agents need streams, not screenshots |
| Read deploy and service status | Every workflow starts with "what state is this in?" |
| Manage env vars per service and environment | The single most common mid-workflow mutation |
| Provision and inspect databases | Agents that can deploy but can't add a database hand off halfway |
| Configure custom domains and TLS | Launch day is a real workflow, not an edge case |
| Explicit non-goal: raw shell or kubectl passthrough | Untyped escape hatches erase every safety property below |
Exhibit A: TeamCity — CI/CD as agent tools
TeamCity is the least likely candidate for an agent-native glow-up: a two-decade-old self-hosted CI/CD server whose power users speak fluent build-configuration XML. Its agent interface arrived in the classic open-source order — community first, vendor second.
The community teamcity-mcp server (TypeScript, MIT) bridges Claude Code, Cursor, and Windsurf to a TeamCity instance, exposing builds, tests, agents, and configs as MCP tools: trigger builds, inspect test results, manage build agents, and modify project configurations including infrastructure settings. Then JetBrains shipped the official answer: built-in MCP support plus a TeamCity CLI with an installable agent skill, which the community project's own README now recommends as the better default for most workflows. JetBrains' pitch is worth quoting because it states the guardrail contract every platform MCP inherits: "You set the guardrails and the AI agents handle the rest."
Two things matter here for a PaaS audience. First, the inventory is the whole operational surface, not a greatest-hits subset — builds and tests and agents and infra config, because an agent debugging a red pipeline needs all four in one session. Second, the vendor endorsement closes the loop the community opened: when the company that owns the platform treats the MCP surface as a first-class interface rather than tolerating it as a third-party wrapper, the tool definitions track the platform instead of rotting a release behind it.
Exhibit B: Dooor OS — the deploy surface as agent tools
If TeamCity shows the CI-shaped inventory, Dooor OS shows the PaaS-shaped one. Its open-source MCP server exposes the workspace's apps, deploys, git, databases, agents, monitoring, and connected business data as MCP tools, so an MCP client like Claude Code or Claude Desktop can query workspace state, deploy apps, and manage agents and databases conversationally.
Note what the inventory centers: not cluster primitives, not YAML editing, not shell access — platform objects. Apps, deploys, databases. That is the correct altitude for an agent interface to a PaaS, and it mirrors the shape every mature deploy-platform MCP converges on. Compare Render's MCP: services, deploys, env vars, and a subset of database operations — same object model, PaaS-shaped rather than infrastructure-shaped. Or Fly.io's: machines, apps, volumes, regions, Postgres — lower-level because Fly's product is IaaS-shaped by design, and the MCP honestly reflects the contract underneath it.
The lesson for a git-push PaaS is that the agent interface should speak the same nouns the dashboard speaks. An agent that has to translate "redeploy the API" into ReplicaSet surgery is doing the platform's job, and every translation step is a place where a confident, fast agent invents something destructive.
Exhibit C: the wiring playbook — setup guidance as the third convergence
The third convergence is quieter but arguably the strongest signal: the pattern now has generic setup guidance. Playbooks for wiring coding agents to infrastructure MCPs walk through the same steps regardless of which platform sits underneath — install the server, point Claude Code, Cursor, Windsurf, or Codex at it, scope the token, separate read tools from mutation tools.
That such guidance can be written generically is the tell. Nobody writes a universal setup guide for a one-off integration; playbooks appear when the shape has stabilized enough that the per-product differences fit in a config snippet. The stabilized shape is: the deploy platform exposes a typed tool surface, the agent authenticates with a scoped credential, and the human decides which mutations need approval. TeamCity and Dooor OS are two instances; the playbook is the abstraction leaking through.
There is a corollary for platform builders. If the wiring is generic, the differentiator is no longer "we have an MCP" — it is coverage and safety. Which is exactly where the PaaS scoreboard currently spreads out.
The minimum viable tool inventory, spelled out
Railway's ranking draws the distinction that matters: full-surface coverage versus curated-subset coverage. A complete MCP exposes what the CLI and dashboard expose. A curated subset exposes a handful of "common" operations and leaves the rest behind a human.
The subset model breaks for one reason — agents do not stay inside the happy path — and it breaks in exactly three ways: the agent stalls and hands back to the human, the agent falls back to shelling out raw CLI commands with credentials it should not be carrying, or a human does the missing step by hand in a dashboard mid-workflow. The first breaks the promise of automation; the second ends up in a postmortem; the third ends up in a status meeting.
Here is the full inventory table for a git-push PaaS, with the failure each row prevents:
| Operation | Why the agent needs it | What breaks without it |
|---|---|---|
| Deploy from a git ref | The core loop: push, build, release | Read-only MCP; the agent narrates instead of shipping |
| Roll back to a previous build | Incident response is the first agent workflow teams automate | Agent diagnoses the outage but can't remediate |
| Tail and search logs | Every debug loop starts here | Agent asks the human to paste logs into chat |
| Read service and deploy status | Ground truth before any mutation | Agent mutates blind or re-asks for state it should read |
| Set env vars per environment | Most common mid-deploy mutation | Stalls on the single most routine operation |
| Provision and inspect databases | Deploys that need datastores are the norm, not the exception | Half-automated provisioning with a human seam |
| Custom domains and TLS | Launch and migration workflows | Launch day still requires dashboard clicks |
| List and diff prior deploys | "What changed?" precedes "fix it" | No baseline for rollback or bisect decisions |
How far the current market is from this bar varies wildly, and the spread is instructive. Render's MCP covers the day-to-day deploy loop (services, deploys, env vars, subset of database operations) but leaves dashboard-only operations behind a human — the classic curated subset. Heroku's MCP covers apps, dynos, config vars, and releases, but the platform is in sustaining mode after Salesforce halted new Heroku feature development in February 2026, so the subset is permanent, not a roadmap phase. And the hyperscalers have no coherent first-party surface at all — per-service community MCPs with no single contract across service boundaries, which is where agent workflows stall the moment they cross from one service to another.
The last row of the inventory deserves emphasis as a negative: raw shell or kubectl passthrough is not an agent interface. A tool that executes arbitrary commands has no typed inputs to validate, no scope to enforce, and no audit trail more precise than a shell history. Every control in the next section assumes typed, narrow tools; a passthrough tool opts out of all of them at once.
What separates a demo wrapper from production-safe
Tools are the demo. Controls are the product — as Qovery's take on agent deploys puts it, the hard part is governance, not access. Four controls separate an MCP server you can point at production from one you should keep on a scratch project, and each maps to a concrete failure it prevents.
Approval-gated mutations. Destructive operations — deploy to production, roll back, delete a database, rotate credentials — must pause for human approval before executing. MCP's mechanism for this is elicitation: the server requests confirmation through the client mid-workflow, and the July 2026 spec tightening (SEP-2260) requires every elicitation to trace back to a client request the user started, so agents can't be prompted out of nowhere through the transport. Without this gate, a fast, confident agent turns a misread plan into a production incident at machine speed. One honest caveat from the security community: approval dialogs that show a model-written summary instead of the actual arguments train users to click through — the gate must show the real inputs, and it can't be the only control, because approval fatigue is real.
Per-session identity with per-environment scoping. The credential an agent carries must answer "who is this, and what may it touch?" — ideally a short-lived token scoped to one environment, so an agent working on staging physically cannot mutate production. Railway's ranking makes this an explicit criterion for good reason: if the only auth model is full-account access, the platform hasn't thought about agents yet. The maturity gap is measurable and ugly — a July 2025 scan found more than 1,800 MCP servers answering unauthenticated requests. OAuth 2.1 with audience-bound tokens is the bar; anything all-or-nothing fails it.
Dry-run modes. Before the agent runs the destructive thing, it should be able to preview the destructive thing. Railway's decision questionnaire asks it directly: does the MCP support dry-run modes for destructive operations? A plan that shows "this deploy will replace 3 services and restart 12 pods" turns approval from a blind click into an informed decision, and it gives the agent itself a verification step — diff the plan against intent before executing.
Idempotent operations. Agents retry. Networks flake. Timeouts lie about whether the operation landed. If "deploy" or "scale" isn't safe to call twice, every retry is a gamble with production state. Idempotency turns the agent's most failure-prone habit into a safe default.
These four compose: scoped identity limits the blast radius, dry-run makes the blast visible, approval gates the blast, and idempotency makes the blast repeatable-safe. Remove any one and the remaining three cover for it poorly — which is why "we show an approval dialog" alone is not a safety story.
The agent-driven platform is the buying criterion now
Step back and the direction is unambiguous. CI servers and deploy platforms have all converged on the same contract: a typed MCP tool surface over the platform's real objects, wired to coding agents through generic setup, gated by approvals and scoped credentials. Teams picking platforms in 2026 and 2027 will default to the ones whose MCP coverage is complete, because the cost of partial coverage compounds with every workflow they try to automate. "Can an agent drive it end to end?" is becoming the question that decides purchases the way "does it have an API?" did a decade ago.
For self-hosted teams the implication cuts both ways. Running your own PaaS means you own the agent interface too — there is no vendor roadmap to wait for, which is freedom if you ship the inventory and the controls, and a gap if you ship neither. The good news is the bar is now written down: the eight rows above, the four controls, no shell passthrough. That is a buildable spec, not a research project.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first app today.
