{"slug": "every-agents-connection-to-railway", "title": "Every (Agents) Connection to Railway", "summary": "Railway launched three connection methods for AI agents to access its platform: Local MCP via CLI, Remote MCP via OAuth, and CLI+Agent. The move aims to enable agents to deploy, manage, and debug projects without human dashboard interaction, supporting tools like Cursor and Factory's Droid.", "body_md": "# Every (Agents) Connection to Railway\n\n## Every (Agents) Connection to Railway\n\nIf it can't just fire up a browser and log in as you, how does an agent actually get in and use Railway? We've spent [agents week](https://railway.com/agents-week) talking about the different ways we've looked at making it easier. Everything from fully revamping setup, the CLI as their first tool, [sandboxes](https://docs.railway.com/sandboxes) for short-lived ephemeral work and agent actions (shoutout to our [agents in the sandbox](https://blog.railway.com/p/agents-in-the-sandbox) post, we added [Droid from Factory](https://factory.ai) and [Cursor](https://cursor.com)'s agent yesterday.), and how we build the loop all the way from develop, to deployed, iterating, and debugging.\n\nAll of that only matters if the agent can get in at all. For a long time the dashboard and [canvas](https://docs.railway.com/overview/the-basics) were that front door, which is a great experience for a human but not for the agent/harness a user is throwing commands at to \"go do the thing\" (sans something like browser-use, but, you get my point). So we've spent a lot of effort over the past few months to make sure as many actions as safely possible are exposed in a way agents can consume.\n\n## Three paths in\n\nThe three connection patterns absolutely have some overlap, because ultimately the thing on the other end of the connection isn't always the same. Classic adage of \"tool for the job.\" Sometimes the \"thing\" is a coding agent running on your laptop inside a project. Sometimes it's a hosted assistant with no access to your filesystem at all, relying instead on GitHub to pull down and take action. Sometimes it's even a script in CI that just needs a structured answer back.\n\nEach of these has their own unique demands and expectations from tooling.\n\n**Local MCP** runs on your machine through the Railway CLI. It's the default, configured via the[automated setup flow](https://agents.railway.com), and the right call when \"local state\" matters: you just built an app, haven't pushed it to GitHub yet, and are running out of the directory you're standing in. Under the hood, the MCP drives API calls, falling back to CLI calls and the Railway Agent as needed. If you're driving agents locally, this ends up being the most successful path for you.\n\n**Remote MCP** lives atand is a standard OAuth based MCP server. It stands on its own, talking straight to the Railway API with no local CLI to lean on, which matters because the systems reaching for it usually don't have one installed. It's very portable, able to run in hosted systems like`mcp.railway.com`\n\n[ChatGPT](https://chatgpt.com)or[Claude.ai](https://claude.ai)directly.\n\nBeyond the MCP approach...\n\n**Railway CLI + Railway Agent** is a different shape entirely. We've been hard at work over the last six months to cover as much of Railway's surface area as we can in an agent-friendly CLI. For the parts that there isn't, you hand the work to an agent-operator that understands the core of Railway and how to drive the outcome. It's only callable from the Remote MCP server, and we expose CLI commands (`railway agent -p`\n\n) that are consumable from the local MCP.\n\n## Install once, get local MCP\n\nThe recommended starting point is heading to [agents.railway.com](https://agents.railway.com) to grab the instructions (or asking your agent to ask railway.com where to configure the agent tools), and dropping the one-liner in your terminal:\n\n```\ncurl -fsSL railway.com/agents.sh | sh\n```\n\nThat installs the CLI, Railway's [agent skills](https://docs.railway.com/ai/agent-skills), and the MCP server, configuring the local MCP server by default in the agents it detects.\n\nWhy prefer the local MCP? The earlier reference to local file state is a big reason, but also from a friction standpoint it inherits your sign-in from the CLI directly. Once you've run `railway login`\n\n, the local MCP server reuses that exact authentication, the same token every other CLI command already uses. There's no second login, no token to paste into a config file, no OAuth round-trip for the agent to complete. There's nothing else to wire up, and your agent can start making structured tool calls against the important parts of Railway right away.\n\nIt also has the widest reach of the three doors, because of the combination of tool availability, local CLI access, and the Railway Agent access via the CLI. Past the basics like deploying and pulling logs, it can create services, manage variables and volumes, generate domains, scale, and read metrics. If the CLI can do it, the local MCP server is usually right behind it.\n\nIf you installed using the installation command above, everything is configured by default. If you haven't installed via that path (hi Homebrew), you can run `railway setup agent`\n\nto execute the same flow, or just land the MCP configuration with `railway mcp install`\n\n. This configures just the MCP piece for the coding tools it finds on your machine:\n\n```\nrailway mcp install\n```\n\nThat covers Claude Code, Cursor, Factory Droid, GitHub Copilot, OpenAI Codex, and OpenCode, merging the Railway entry into each tool's config without touching the other servers you've set up.\n\nOne housekeeping note while we're here. If you wired up Railway's MCP through an `npx`\n\ncommand at some point, that older path is deprecated. The server ships inside the CLI now, so `railway mcp`\n\nis the whole story, and re-running the install moves you onto the supported path.\n\n## Skill and Railway CLI\n\nYesterday, we wrote a [post focused on our Railway Agent Skills](https://blog.railway.com/p/skills-issue-writing-skills), and how we approached landing them. When you install via the bootstrap command, these skills are installed by default and help route agents between when to use MCP vs CLI, which MCP to use, and how to engage Railway Agent. It's an important part, because it lets us tune the approach the agent is taking and guide it down the paths we want.\n\nAs we moved through CLI improvements, we focused on the agent-experience nits that pop up when a non-interactive caller is hitting the system: commands that don't return proper structure, and interactive prompts that block automation.\n\n- Commands that return data now take a\n`--json`\n\nflag that outputs it accordingly, so an agent gets structured output instead of scraping returns meant for human eyes. - Where applicable,\n`-y`\n\nskips the confirmation prompts that would otherwise leave an agent hanging on an \"Enter\" that never comes. `-s`\n\n/`-e`\n\nscope any command to an exact service and environment, so you're filtering down to the right one.\n\nAll of these behaviors are steered by the agent skills and the skills router we've built into `use-railway`\n\n. The layered approach has worked really well for us.\n\nThe other half of the work has been closing the gap between the dashboard and the terminal, one command at a time. [Metrics](https://railway.com/changelog/2026-05-15-railway-for-ios), custom domains, outbound networking, volumes, buckets, templates, and [sandboxes](https://railway.com/changelog/2026-06-12-docker-in-sandboxes) all landed as first-class CLI commands, which means they all landed as things an agent can do too.\n\n## Remote MCP\n\nLocal MCP assumes a few things: that you can install the CLI, that you can sign in, and that the work has something to do with the machine you're on. There are plenty of practical examples where these aren't true. That's when the remote MCP server earns its keep.\n\nIt's accessed at [mcp.railway.com](https://mcp.railway.com) (which doubles as its landing page too), responds over Streamable HTTP, and it doesn't require a local install, outside of being configured in your agents and signed in via OAuth. The Remote MCP talks straight to the Railway API, and is fully self-contained. The agent authenticates through the browser with OAuth, you choose which workspaces and projects it can touch on the consent screen, and the connection is scoped to exactly that. (Project tokens aren't accepted here on purpose. The remote server wants a real user identity behind every call for billing and audit.)\n\nThe situations where remote is the right call tend to have similar shapes:\n\n- The system has no filesystem access, or you'd rather not give it any.\n- You can't or won't install the CLI, like a hosted assistant or a locked-down box.\n- A third-party agent that can't shell out to a local binary and only speaks MCP over HTTP.\n- CI, where a hosted endpoint and browser OAuth beat managing CLI auth inside a runner.\n\nWhen we [first shipped remote MCP](https://blog.railway.com/p/agent-rails-remote-mcp-cli), we kept the tool count deliberately tiny: a handful of operations plus the `railway-agent`\n\ntool as the escape hatch for anything complicated. A smaller surface is easier for a model to reason about, and we'd rather grow it on evidence than guess at what people wanted and bloat it on day one. So when the requests came in, they were specific. People wanted the exact operations they kept dropping back to the CLI for, and the read operations they lived in, logs and status, went in first. Here's where the remote server sits now:\n\n**Account:**`whoami`\n\n**Projects & services:**`list-projects`\n\n,`create-project`\n\n,`list-services`\n\n**Deployments:**`list-deployments`\n\n,`get-status`\n\n,`create-deployment`\n\n,`deploy-artifact`\n\n,`redeploy`\n\n, and`accept-deploy`\n\nto commit staged changes (it's destructive, so well-behaved clients prompt before firing)**Observability:**`get-logs`\n\n**Agent:**`railway-agent`\n\n, the entry point for the multi-step work that doesn't fit a single tool call\n\nFun fact: There was a time period where Railway Agent made up 50% of the calls. Once we added `get-status`\n\nand `get-logs`\n\n, the volume for agent calls dropped by two-thirds. It still gets a lot of usage, but the intention is to gradually expose the workflows that users actually need, and keep the context used by tools small.\n\n## The Railway Agent, your operator\n\nThe two MCP servers give an agent tools. The CLI expands that tool box a lot further. The [Railway Agent](https://docs.railway.com/ai/railway-agent) gives it a teammate who's REALLY smart about running Railway.\n\nYour coding agent is good at building your application. It is not, out of the box, a Railway expert and in many cases it's operating out of aged training data. It'll almost always figure out its way through it, but it's definitely not peaceful to watch the CLI error a bunch of times as the agent works through it (another reason why we strongly encourage getting the skills installed).\n\nThe Railway Agent already knows all of the operating patterns. The project model, the services, the deployments, the logs and metrics, the variables, the networking, and the ways these things tend to break. So rather than teaching your agent to be a Railway expert, you let it delegate to one.\n\nOn the operations side it manages your Railway environment directly: create and configure services, attach a Postgres or Redis, wire up networking, set variables, scale a service, and walk a failing deployment until it understands what went wrong.\n\nOn the code side it can go a step further and write the fix. When a deploy breaks, [smart diagnosis](https://railway.com/changelog/2026-02-27-smart-diagnosis) reads the build and runtime logs against your recent changes, explains what happened, and when the fix belongs in your repo it can open a pull request for you to review. For heavier work it can spin up its own [sandbox](https://docs.railway.com/sandboxes) and actually run code instead of guessing at it.\n\nYou can reach the Agent from the dashboard in the UI, but for the terminal-pilled builder, the Remote MCP server through the `railway-agent`\n\ntool, or CLI are your best bet. Take this for a spin in the CLI next time you're authenticated:\n\n```\nrailway agent -p \"why is my service crashing?\"\n```\n\n`-p`\n\nis a single-turn prompt, which kicks the agent into a multi-step workflow behind the scenes: read the logs, check the deployment, reason about what went wrong, and answer with project-aware context instead of a guess.\n\nA few example ways you can use it with automation:\n\n```\n# structured output a script can act on\nrailway agent -p \"what's the status of my deployment?\" --json\n\n# continue an existing thread instead of starting cold\nrailway agent -p \"now scale it to two replicas\" --thread-id <ID>\n\n# scope the question to a specific service and environment\nrailway agent -p \"is this service healthy?\" -s api -e production\n```\n\n`--json`\n\nis the one that matters for CI or sub-agent paths. A pipeline can shell out to `railway agent`\n\n, get structured output back, and make a decision on it without a human reading a chat window.\n\nRun `railway agent`\n\nwith no `-p`\n\nand you drop into an interactive session, which feels a lot more like a traditional back and forth REPL.\n\n## Which door do I use?\n\nThe short version:\n\n**Local MCP** for a coding agent on your own machine. Inherits your sign-in, broadest surface, knows your directory and project. The default, and almost always the right answer.**Remote MCP** when local doesn't fit: no filesystem, no CLI, a hosted assistant, or CI.**The Railway Agent** when you'd rather hand off a multi-step problem than drive each tool call yourself.**The CLI** directly when you want full control and the complete surface.\n\nMost setups mix them, and that's the point. Whatever's on the other end, there's a door that fits.\n\n## Get connected\n\nIf you've got a coding agent in front of you right now, the fastest path (outside of asking your agent to look at railway.com and tell you how to get started) is to drop this into your terminal:\n\n```\ncurl -fsSL railway.com/agents.sh | sh\n```\n\nIf you're wiring up something hosted, attach `--remote`\n\nto the installer and you'll get pointed at `https://mcp.railway.com`\n\nfor the remote install instead.\n\nRather hand the work off than manage the tools? `railway agent -p`\n\nis one prompt away.\n\n## Further reading\n\n[Railway MCP Server](https://docs.railway.com/ai/mcp-server)- remote and local MCP, setup, and the full tool list- install into specific tools, local stdio vs remote config`railway mcp`\n\nCLI reference- prompts, threads, JSON output, and scoping`railway agent`\n\nCLI reference[Railway Agent](https://docs.railway.com/ai/railway-agent)- what the operator knows and how it works[Railway for Agents](https://docs.railway.com/agents)- the broader setup, skills, and MCP story\n\nHappy shipping.\n\n*— Cody*", "url": "https://wpnews.pro/news/every-agents-connection-to-railway", "canonical_source": "https://blog.railway.com/p/agent-connection-to-railway", "published_at": "2026-06-26 13:00:00+00:00", "updated_at": "2026-06-26 14:06:44.345687+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Railway", "Cursor", "Factory", "ChatGPT", "Claude.ai", "MCP"], "alternates": {"html": "https://wpnews.pro/news/every-agents-connection-to-railway", "markdown": "https://wpnews.pro/news/every-agents-connection-to-railway.md", "text": "https://wpnews.pro/news/every-agents-connection-to-railway.txt", "jsonld": "https://wpnews.pro/news/every-agents-connection-to-railway.jsonld"}}