Dora NodaOn April 17, 2026, Railway turned on a remote MCP server at mcp.railway.com and shipped a one-line install (curl -fsSL agents.railway.com | sh) that drops a Railway-specific Agent Skill into Claude Code, Cursor, Codex, and OpenCode. Point an agent at it, and it can list your projects, trigger a redeploy, and — with your explicit approval — stand up a brand-new service from a git repo. No dashboard tab required.
That's a real, working agent-ops surface from a direct competitor, not a slide. It's also a useful stress test for any other platform claiming the same territory. bex already ships an MCP server of its own — three months earlier, in fact — with almost double Railway's tool count. So what does Railway's smaller surface actually do that bex's bigger one doesn't?
What Railway Actually Shipped
The remote MCP server isn't a new microservice — it's a route handler inside Railway's existing backend (backboard), reusing the same OAuth and permission checks every other Railway surface already runs on. An agent authenticates once in-browser; Railway can revoke that grant from account settings at any time. The tool surface is deliberately narrow — seven tools, trimmed down from nine during development because, per Railway's own write-up, routing multi-step work through a delegated agent beats bloating the client's context with granular tools:
| Tool | What it does |
|---|---|
whoami | confirm the authenticated identity |
list-projects | list accessible projects |
create-project | create a new project |
list-services | list services and environments |
redeploy | trigger a redeploy of an existing service |
accept-deploy | stage and deploy a new build |
railway-agent | hand off a multi-step task to Railway's own hosted agent |
Alongside the MCP server, the railway agent CLI command runs the same hosted agent interactively (railway agent), as a one-shot (railway agent -p "why is my staging deploy failing"), or scriptably (--json output, --thread-id to continue a prior session, --service/--environment to scope it). That's three ways to reach the identical backend logic — an interactive terminal session, a single scripted prompt, and a chat-client tool call — which is the same "one core, many surfaces" instinct bex applies to REST/GraphQL/MCP, just aimed at a different layer (a hosted agent, rather than a set of fixed verbs).
The use-railway Agent Skill — the SKILL.md-format runbook installed by that same one-liner — is what tells a general-purpose coding agent when to reach for which of those tools: when to redeploy versus call railway-agent for something more open-ended, when to check logs before acting, and when to stop and ask. Install is a single command with no separate auth step beyond the OAuth prompt that fires the first time a tool actually gets called — the friction Railway is optimizing away is "open a second browser tab and configure a token by hand," and the one-liner genuinely removes it.
That last part matters more than the tool count. accept-deploy carries a destructiveHint annotation in its MCP tool definition, and Railway's MCP-compatible clients surface that as an explicit approval prompt before the deploy fires. redeploy and the read-only tools don't — an agent can list projects and re-trigger a known-good deploy without a human in the loop, but the moment it's about to ship a new build, something has to say yes.
Where bex Already Matches — and Beats — the Tool Count
bex's MCP server isn't a roadmap item. It shipped as pillar 3 of the product (docs/vision.md) months before Railway's remote server went live, and its tool surface is already wider:
| Tool | Core verb | What it does |
|---|---|---|
list_services / get_service | List / Get | list and inspect services |
restart_service / suspend_service / resume_service | Restart/Suspend/Resume | lifecycle control |
update_service_plan | SetPlan | change instance plan |
scale_service | Scale | change replica count |
list_logs | QueryLogs | filtered log reads, per-service |
get_metrics | Metrics | CPU/memory/request/latency/bandwidth series |
list_postgres_instances / get_postgres / create_postgres | ListPostgres/GetPostgres/CreatePostgres | managed Postgres |
create_api_key / list_api_keys / revoke_api_key | — | credential management |
That's thirteen tools against Railway's seven, and it covers ground Railway's server doesn't touch at all: metrics, managed Postgres, and self-service API-key rotation. bex's tools are also intentionally shaped to match Render's official MCP server naming (list_services, restart_service, get_postgres) — the same compatibility bet bex makes across REST and GraphQL, so an agent already fluent in Render's shape needs to learn nothing new.
None of that is a coincidence. It's the same "one core, three adapters" design that gives bex its REST and GraphQL surfaces: every MCP tool delegates to the identical Service method the REST handler calls, so the three surfaces can't drift apart. Railway's tool count grew and shrank by design decisions about agent context; bex's grew as a side effect of just not having a second code path to keep in sync.
The One Verb Neither Tool Table Should Distract From
Here's the gap a bigger tool count doesn't paper over: bex's MCP server has no deploy verb. Not "deploy a fresh build from a git repo," not even Railway's narrower redeploy of something already running. Every tool in that thirteen-tool table above operates on a service that already exists. Getting a new app onto bex today still means going around the MCP surface entirely.
That's not an oversight — it's explicitly the next pillar on bex's own roadmap, tracked as "🔜 planned" right next to the MCP server's "✅ shipped": one API call that takes a repo plus a bex.yml to a live URL, so "deploy this" becomes a single agent action instead of a manual multi-step process. It's gated on two roadmap items that are still open: wiring push-to-deploy and wake-on-request from git hosting, and — the harder one — in-cluster builds, so a build-from-git image is actually pullable by cluster nodes without a human kicking off a build pipeline first. Railway solved that problem years ago as a paying, hosted service; bex is solving it as something a fleet on owned Hetzner machines does itself, which is a slower and more honest path but the same destination.
So the honest comparison isn't "bex has more tools, Railway has fewer" — it's that Railway's seven tools already close the loop from zero to running service, and bex's thirteen don't yet. A wider surface for operating what's already deployed is real value, but it's not the same capability as accept-deploy.
What This Actually Changes About bex's Own MCP Roadmap
Three concrete things Railway's launch should move up bex's list, not because a competitor did it first, but because the design choices are worth stealing on their own merits:
Ship deploy_app the moment in-cluster builds land — not as a follow-on. The tempting sequencing is: land in-cluster builds, get it stable in REST/GraphQL, then add the MCP tool later. Railway's example argues for shipping the MCP tool in the same release. The whole point of pillar 4 is that "deploy this" becomes a single agent action — if the MCP verb lags the REST verb by even one release, the capability that actually matters to an agent-operated fleet is the one still missing.
Add destructiveHint annotations to bex's own mutating tools now, not later. restart_service, suspend_service, scale_service, and update_service_plan all currently look identical to list_services from an MCP client's perspective — nothing in the tool definition tells a client "this one needs a human to say yes." Railway's accept-deploy shows the fix costs nothing beyond adding the annotation the MCP spec already defines; the client-side approval prompt is free once it's there. For a fleet where an agent has real restart/suspend/scale authority, that's not a nice-to-have — it's the difference between "an agent can operate this" and "an agent operating this unsupervised is one bad prompt away from an outage."
Package a use-bex-equivalent Skill, not just a tool list. bex's MCP tools already exist; what doesn't exist yet is the SKILL.md-format runbook that tells a general-purpose coding agent when to reach for which one — when to check list_logs before restarting, when a plan change needs confirmation, when to fall back to kubectl because the MCP surface doesn't cover it. Railway's insight — proven out in an earlier look at Anthropic's own Agent Skills format — is that the tool surface and the operating manual are separably valuable, and shipping only the former leaves an agent knowing that it can restart a service without knowing when it should.
There's also an installation-friction lesson worth taking straight, independent of tool count. bex's MCP server already supports two transports — streamable HTTP at /mcp behind the same bearer/session auth as every other route, and a stdio mode (api mcp-stdio) for an agent running as a local subprocess that already holds cluster credentials. What bex doesn't have is Railway's single install command that wires a specific editor's config file, drops in the Skill, and confirms auth in one shot. The transports are arguably more flexible than what Railway ships; the onboarding path from "I have an agent" to "my agent can call this" is not.
None of this is Railway doing something bex structurally can't match — it's a competitor's shipped product making concrete what "finish the MCP story" actually means in practice, tool by tool.
bex is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP server that's already fluent in Render's own tool names. Star the repo on GitHub or point an agent at /mcp today.
