Dora NodaThere is a new parity target in platform engineering, and it is not a CLI command or a REST endpoint. When a developer evaluates a PaaS in late 2026, one of the first questions is whether an AI coding agent can operate it directly: deploy the app, read the logs, rotate a variable, roll back the bad release. The answer increasingly comes as a URL ending in /mcp.
The shift happened fast. Render runs an official hosted MCP server at mcp.render.com/mcp (render-oss/render-mcp-server), Heroku answers at mcp.heroku.com/mcp, and Railway runs mcp.railway.com with full user documentation — all three now appear in remote-MCP-server listings next to Netlify and Vercel.
On the self-hosted side, Dokploy ships the official @dokploy/mcp package covering its entire API, and Coolify ships an MCP server alongside its API and CLI. "Agents can operate the platform" moved from roadmap slide to shipped surface in under a year, and the MCP server is now the parity target every platform gets measured against — the same way CLI/API parity used to be.
This post compares what the two most instructive surfaces actually expose, operation by operation, and derives the checklist a Render-compatible MCP surface on owned hardware has to clear before "agent-operated" is a credible claim rather than a demo.
Operation by operation: what each MCP surface actually exposes
The table below is the heart of this post. Columns are the four concrete surfaces this comparison is built from: Dokploy's official package against your own instance, Railway's hosted endpoint, Railway's fuller local CLI server, and Render's hosted endpoint as the reference for "Render-compatible." Rows are the operations an agent needs to run a service day to day.
| Operation | Dokploy @dokploy/mcp (your instance, stdio) | Railway hosted (mcp.railway.com) | Railway local (railway mcp local) | Render hosted (mcp.render.com/mcp) |
|---|---|---|---|---|
| Deploy / redeploy | Application category, 30 tools: create, deploy, redeploy, start, stop, plus Compose (29) and Deployment history/queue (8) | redeploy; accept-deploy commits staged changes and deploys (destructive, client confirms) | deploy, list_deployments, create_service, connect_service_source | Deploy and inspect services, static sites, cron jobs |
| Logs | Deployment history and queue; 41 notification tools (Slack, Discord, PagerDuty-style webhooks) for alerting | Via the railway-agent delegation tool ("figure out why my backend is crashing on deploy") | get_logs, http_requests, http_error_rate, http_response_time | Log querying |
| Env vars | Per-app and per-database environment tools across Application and all six database categories | Via railway-agent ("pull environment variables and save them to a .env file") | list_variables, set_variables, add_reference_variable | Not in the verified public tool list |
| Rollback | Rollback category, 2 tools | Not exposed as a dedicated tool | Not exposed as a dedicated tool | Not in the verified public tool list |
| Domains / TLS | Domain category, 9 tools: CRUD, DNS validation, Traefik.me generation | Not exposed as a dedicated tool | Full set: generate_domain, list_domains, domain_status, update_domain, delete_domain, retry_domain_certificate | Not in the verified public tool list |
| Databases | Six engines with full lifecycles: PostgreSQL, MySQL, MariaDB, MongoDB, Redis (15 tools each), LibSQL (13); Backup (12) plus volume backups and S3 destinations | Deploy from template (deploy_template lives on the local server) | deploy_template, volumes (create/update/remove_volume), buckets | Postgres databases and Key Value stores |
| Status / metrics | Server category (17): metrics, monitoring setup; Audit Log; Docker container inspect | list-projects, list-services, whoami | service_metrics, environment_status, private_network_status | Performance metrics, deployment tracking |
| Auth | Instance API key in DOKPLOY_API_KEY env | CLI login reuse (railway login, CLI 5.44.0+) or OAuth with scoped, short-lived tokens | CLI credentials; destructive tools return a preview and require confirm: true | Bearer API key or OAuth |
| Transport | stdio via npx -y @dokploy/mcp | Hosted Streamable HTTP | In-process stdio for egress-restricted networks | Hosted /mcp over Streamable HTTP |
Three patterns jump out. First, Dokploy is the completeness maximalist: 508 tools across 49 categories, every API endpoint mirrored, including the unglamorous ones agents need in production — rollback, backups, audit log, domain TLS retry. Second, Railway splits the difference: a deliberately small hosted surface (about ten curated tools plus an agent-delegation escape hatch) with the full fifty-tool set reserved for the local server that holds your CLI credentials. Third, nobody's hosted surface exposes rollback or env writes casually — the two operations that can take down production are either absent from the cloud endpoint or wrapped in confirmation gates.
Dokploy's bet: mirror the whole API
Dokploy's philosophy is the simplest one available: if the REST API can do it, the agent can do it. The README states the coverage plainly — all Dokploy API endpoints as MCP tools, 508 tools across 49 categories, from project and application management to SSO, Docker, backups, and notifications. The install story matches the self-hosted ethos: point DOKPLOY_URL at your own instance, hand it an API key, and run the server over stdio inside your editor via npx, bunx, or Deno. Your agent talks to your machine; no vendor cloud sits in the middle of the control plane.
That completeness is also the honest admission in the design. The same README documents DOKPLOY_TOOL_PRESET — minimal (project plus application), core, deploy, databases, git — and a DOKPLOY_ENABLED_TAGS allowlist, with this rationale: some MCP clients and LLM providers get slower or less reliable when very large tool lists are sent to the model. A 508-tool surface is complete API parity and simultaneously a prompt-context liability, so Dokploy pushes the scoping decision to the operator. Start minimal, widen the preset as the workflow demands it.
There is a real lesson here for anyone building an agent surface on owned hardware. Full mirroring is the fastest route to "the agent can do anything the dashboard can," and rollback, per-engine database lifecycles, and backup destinations are exactly the long-tail operations where a curated ten-tool surface falls short. But the preset mechanism concedes the counterpoint: model reliability degrades as the tool list grows, so completeness without scoping is a demo that gets worse the more you use it. Dokploy ships both the mirror and the filter, which is why its surface survives contact with production.
Railway's two tracks: curate the cloud, document the hosting
Railway plays a different game on two boards at once. On the first board — agents operating Railway — the hosted server at mcp.railway.com exposes roughly ten tools: identity, project and service listing, feature flags, redeploy, accept-deploy, and railway-agent, a delegation tool that hands a natural-language request to Railway's own agent for multi-step work like log analysis and debugging. Notably, the docs refuse project tokens: the server requires a user identity so billing and audit trails stay attached to a human. Destructive actions carry protocol-level markings so conforming clients prompt before running them.
The fuller surface lives one layer down. railway mcp local runs an in-process server off CLI credentials with around fifty tools — the deploy, logs, variables, domains, TCP proxy, private-network, template, storage, and metrics tools the hosted endpoint omits. It is also the answer for egress-restricted networks that cannot reach mcp.railway.com. The design reads as deliberate risk tiering: the network-reachable endpoint is small, OAuth-scoped, and human-audited, while the credential-rich surface runs on the operator's own machine.
On the second board, Railway published a guide that reframes the race entirely: instead of only exposing Railway to agents, it teaches tenants to build and deploy their own remote MCP servers in TypeScript on Railway, so Claude and Cursor can call them over the network. The guide is current to the July 2026 spec revision that retired the old HTTP+SSE transport and the initialize/Mcp-Session-Id session handshake in favor of stateless Streamable HTTP — which is precisely what makes a hosted MCP server horizontally scalable with no sticky sessions. Any replica can serve any request. Railway is positioning itself not just as a platform with an MCP surface but as the place MCP servers get hosted, down to the scaling property that makes hosting them boring.
That is the move worth watching. Every PaaS with an MCP endpoint is competing on which operations agents can call; Railway is additionally competing on where the agent economy's own servers run.
The credible-agent-operated checklist for owned hardware
Stack the three surfaces side by side and the bar for a self-hosted, Render-compatible MCP layer comes into focus. "The agent can deploy" is table stakes. Credible means clearing all six operations plus three non-operation requirements the comparison exposes.
The six operations, with the row that proves each is expected:
- Deploy and redeploy — Dokploy's 30-tool Application category, Railway's
redeploy/accept-deploy, Render's deploy tooling. An agent that cannot ship is a dashboard with extra steps. - Logs and observability — Dokploy's deployment history, Railway local's
get_logsplus HTTP error-rate and response-time metrics, Render's log querying. Debugging without logs is guessing. - Env vars — Dokploy's per-app and per-database environment tools, Railway local's
list/set_variables. Rotation and inspection without dashboard round-trips. - Rollback — Dokploy's dedicated Rollback category is the only first-class implementation in this comparison, which is exactly why it belongs on the checklist: the operation you need at 3 AM must be a tool, not a paraphrase of "redeploy the old thing and hope."
- Domains and TLS — Dokploy's 9-tool Domain category, Railway local's full domain set including certificate retry. Custom-domain onboarding is part of operating a service, not a separate hobby.
- Databases and status — Dokploy's six engine lifecycles plus backups, Render's Postgres and Key Value coverage, Railway's service metrics. Data-plane operations with the same auditability as the rest.
And the three requirements no operation count captures:
- Scoped auth, not one god-key. Railway's hosted endpoint takes OAuth with per-workspace scoping and short-lived tokens, and refuses project tokens so every action traces to a user. A self-hosted surface that only accepts a single instance-wide API key gives the agent the keys to every tenant at once. Per-project or per-service scoping is the gap to close first.
- Remote transport, not stdio-only. stdio works when the agent runs next to the server process; a fleet operator needs Streamable HTTP so any agent, anywhere, can reach the control plane — with the stateless-scaling property the July 2026 spec made standard. Dokploy's stdio-only package is the honest gap in an otherwise complete surface.
- Destructive-action gating. Railway marks destructive tools at the protocol level and its local server returns a preview before requiring explicit confirmation. Env writes, rollbacks, deletes, and certificate operations on a shared fleet need the same treatment: the agent proposes, the human (or policy) disposes.
Clear those nine, and "agent-operated" stops being a demo claim. Miss any one and an evaluator comparing against the table above will find the hole in minutes — which is the real meaning of the race: the MCP surface is now the surface, and parity is measurable tool by tool.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. AI agents are first-class operators, not an afterthought. Star the repo on GitHub or deploy your first app today.
