Railway Shipped Three Agent Tracks at Once: Remote MCP, railway agent, and One-Command Skills — Which Should a Self-Hosted PaaS Copy First?

If your agent can write the code, it should be able to ship it too. That was Railway's pitch on April 17, 2026, when changelog #0286 laid not one but three new tracks for agents in a single week: a hosted Remote MCP server, a railway agent command in the CLI, and a one-command skills install for the four biggest coding editors.

Most platforms ship one agent integration and call it a strategy. Railway shipped three surfaces at once — and then published the design reasoning behind them. That makes this bundle the best-documented case study we have of what "agent-operable PaaS" actually costs to build, and in which order.

Here is the bundle up front, because the verdict at the end depends on it:

The short version of the verdict: a self-hosted PaaS should copy them in exactly this order — skills first, MCP second, hosted agent harness last. The reasoning is about cost, not capability, and Railway's own engineering blog accidentally proves it. Details below.

Track 1: A Remote MCP Server With Only 7 Tools​

The Remote MCP Server lives at mcp.railway.com and speaks to any MCP-compatible client — Claude, Cursor, Codex, GitHub Copilot, Droid, OpenCode — over OAuth. No local install, no token files on disk. Connect from the editor, pick which workspaces and projects the client may touch in a browser consent screen, and revoke access from Railway settings at any time.

The deliberately interesting part is the tool list. Railway's engineering post by Cody De Arkland admits the instinct is to expose everything — wrap every API call as a tool, mirror every CLI command — and says they went the other way. The server launched with 7 tools, down from 9 in the first draft of the announcement, with the author openly planning to cut further:

Two costs drive this shape, and both are about context. Every tool definition sits in the client's prompt on every turn, so a 25-tool surface taxes the user's context window before any work happens — and larger lists measurably hurt the model's tool selection. Then each tool-call round-trip burns more context when results come back, so a "debug my deploy" task done as six narrow calls costs six trips' worth of context.

railway-agent is the escape hatch for both costs. The client sends one natural-language message; Railway's agent does the full multi-step investigation server-side — reading logs, checking config, correlating deploys — and returns one consolidated response. The orchestration complexity stays on Railway's side, where it can be improved without breaking any client's config. Railway's stated medium-term direction is to keep shrinking the direct tools to cleanly bounded CRUD and discovery, and route everything that is really a question in disguise through the agent.

There is a quiet instrumentation win here too: because railway-agent tracks which sub-tools it calls internally, Railway gets real usage data about which capabilities might earn promotion back up to top-level tools. The tool surface gets designed by evidence, not guessing.

Track 2: The Same Agent, Reachable From a Terminal​

Not every workflow lives in an editor. railway agent puts the same hosted agent — the one behind the dashboard and behind railway-agent in the MCP server — into the CLI you already have installed:

# Add a Postgres database and wire it up
railway agent -p "add a Postgres database to this project and set DATABASE_URL on the API service"
 
# Investigate a failing service
railway agent -p "help me figure out why my backend service is crashing on deploy"
 
# Pipe it into your automation
railway agent -p "list my services and their status" --json | jq '.toolCalls'

Day-one surface: interactive back-and-forth with a bare railway agent, one-shot prompts with -p for scripts and quick questions, --json output carrying the thread ID plus every tool call for chaining into automation, --thread-id to resume a previous conversation, and --service / --environment to scope a request. Because it is scoped to your user token — it can do anything you can do, nothing more — it drops into CI without extra credentials: investigate a failing deploy or spin up a database from a job step.

The notable design fact is the "same agent" part. Shipping the MCP server and the CLI command together forced Railway to expose its agent as a small REST endpoint (POST /api/v1/agent) that anything over HTTP can reach. Every improvement to the agent lands in both surfaces at once. That is the kind of forcing function worth copying: one agent backend, many on-ramps, no per-surface agent fork to maintain.

Track 3: Skills as the Distribution Channel​

The third track is the least glamorous and possibly the most strategic. railway skills install drops Railway's curated agent skills into ~/.agents/skills and every detected editor directory — Claude Code, Cursor, Codex, OpenCode — so a coding agent shows up already knowing how Railway works: how to deploy, debug, and manage services through the CLI. --agent targets one tool, railway skills update pulls upstream changes, railway skills remove uninstalls.

Why this matters beyond convenience: skills are now a portable standard, not a per-editor integration. Anthropic opened the Agent Skills format (a SKILL.md file with YAML frontmatter plus instructions) as an open specification in December 2025, and it has since been adopted across Claude Code, Codex, Cursor, Copilot, OpenCode, and dozens more tools. One skill folder works everywhere; agents load only the skill name and description until the task at hand needs the full content, so installing skills does not tax every conversation's context.

That turns railway skills into a distribution channel with near-zero marginal cost per editor. Railway writes deployment expertise once, and every agent in every supported editor inherits it — including guidance like "use direct CLI commands for deterministic operations, use railway agent only for natural-language investigation," which keeps agents on the cheap path by default. Later changelog entries show the skills compounding: smarter routing between CLI-based and Remote MCP configurations in May, sandbox awareness in June, refreshes against new CLI versions in July. Skills are the track that keeps paying without new infrastructure.

The Design Underneath: One Backend, Minimal Surface, No Parallel Auth​

The engineering post is unusually candid about implementation, and three decisions stand out for anyone building a platform:

The MCP server is a route handler, not a service. The first architecture sketch was a separate service with its own Postgres and Redis — until the team realized they were rebuilding user sessions, OAuth grants, permissions, dataloaders, encryption, and analytics as an elaborate proxy back into the monolith. The shipped version is a Koa route inside the main backend: existing session middleware resolves the bearer token, a RailwayContext flows through AsyncLocalStorage into tool handlers, and tools call the same controllers the dashboard calls. One auth system, one permission model.

OAuth piggy-backs on the existing provider. The .well-known/oauth-authorization-server endpoint on mcp.railway.com is a discovery mirror pointing back at the main backend's OIDC provider, with the RFC 8707 resource parameter pre-baked so audience binding holds even if a client forgets it. No second consent UI, no parallel OAuth state.

Direct tools stay minimal; the agent absorbs complexity. The strategy is explicit: bounded CRUD stays as tools, questions route through railway-agent, and internal sub-tool telemetry decides what gets promoted. Five months of follow-up changelogs confirm the trajectory — editor plugins moved from local MCP to the hosted server, railway mcp in the CLI now connects to the same remote server, and the skills kept absorbing each new capability.

Which Track Should a Self-Hosted PaaS Copy First?​

Here is the verdict table, then the reasoning:

Skills first. A SKILL.md that teaches agents your CLI, your config schema, and your failure modes costs roughly a good docs page plus testing against two or three agents — and the open standard makes it portable for free. It is also the track that disciplines everything else: writing down "the right way for an agent to deploy here" exposes every place your CLI output is unparseable, your flags are inconsistent, or your docs assume a human reader. Railway's own skill guidance (deterministic CLI calls by default, agent escalation only for investigations) is a policy any platform can adopt before building any agent infrastructure at all.

MCP second, and local before remote. Railway's remote server is the polished end state, but its value rests on two prerequisites a self-hosted project must build anyway: a typed, idempotent API (or at minimum a CLI with complete --json output) and a tight tool list with a destructive-action policy. The OAuth workspace/project scoping that makes remote MCP safe is real engineering — consent UI, grants storage, revocation — and a self-hoster gets most of the benefit sooner with a local stdio MCP server riding on existing CLI auth. Note the contrast with community CLI-wrapper shims, which inherit every CLI wart as prompt-embedded guesswork; the lesson is that MCP quality equals API discipline, not adapter cleverness.

The hosted agent harness last. This is the track Railway emphasizes most and a self-hosted project should build last — because Railway already had the agent. The multi-step reasoning backend, the model spend, the eval loop over real deploy failures: that is a product in itself, and it only earns its keep once agents are already deploying through your skills and tools in volume. Until then, railway-agent's job can be approximated by the general-purpose coding agent the user already pays for, guided by your skill.

Notice the copy order is the reverse of Railway's emphasis order. That is not a contradiction: Railway's emphasis reflects what differentiates a hosted platform with an existing agent team, while the copy order reflects what compounds cheapest for a project starting without one. Skills compound into MCP design (the skill's pain points become the tool list), and both compound into knowing what the agent harness must eventually do.

Agents Will Judge Your Platform by Its Cheapest On-Ramp​

Railway's bundle is a roadmap disguised as a release: meet agents in the editor, in the terminal, and in the skills directory — on one backend, behind one auth system, with the tool surface shrinking as the agent grows. The individual pieces are all public and well documented, which is exactly what makes the bundle worth studying rather than just admiring.

For a self-hosted PaaS, the takeaway is sequencing. Ship the skill that makes agents competent on your platform this month. Build the typed API and tight tool list that earns an MCP server next. Earn the hosted agent harness with usage data, the way Railway does. Agent-operability is not a feature checkbox — it is a roadmap order question, and the cheapest track to copy is also the one that teaches you what the expensive tracks need.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.