Software Railway lança MCP remoto e Agent no CLI

Railway lança servidor MCP remoto e comando railway agent no CLI para turbinar o uso de agentes de IA

O Railway acaba de anunciar dois lançamentos que mudam bastante a forma como agentes de IA interagem com plataformas de deploy. E dessa vez, não estamos falando de promessas vagas ou roadmaps distantes. As duas novidades já estão disponíveis para teste agora mesmo.

Se você acompanha o espaço de agentes e MCP nos últimos meses, já deve ter percebido que essa tecnologia deixou de ser experimento e virou parte real do fluxo de trabalho de muita gente. O que antes parecia coisa de laboratório agora aparece no cotidiano de times de desenvolvimento, startups e pessoas que constroem produtos sozinhas, integrando agentes em cada etapa do processo de criação de software.

Ferramentas como Cursor, Claude Code, Codex, GitHub Copilot, Droid e OpenCode já fazem parte do dia a dia de quem desenvolve software, e a pergunta que fica é: as plataformas de deploy conseguem acompanhar esse ritmo? Por muito tempo, a resposta foi um silêncio constrangedor. As ferramentas de desenvolvimento evoluíram rápido, mas a infraestrutura ficou alguns passos atrás, criando um gap entre o que os agentes conseguem fazer e o que as plataformas de deploy estavam preparadas para oferecer.

O Railway resolveu responder a essa pergunta na prática, com duas novidades que chegaram juntas:

Um servidor MCP remoto, disponível em mcp.railway.com, que permite conectar qualquer agente compatível direto do editor, sem instalar nada localmente e com autenticação via OAuth
Um novo comando railway agent no CLI, para quem prefere resolver tudo pelo terminal ou quer integrar o agente em scripts e pipelines de CI

A ideia central é simples: quando um agente precisa fazer algo no Railway, ele consegue, pelo caminho que fizer mais sentido pra você. Sem atrito, sem configurações complicadas, sem precisar dominar toda a infraestrutura por baixo dos panos. A metáfora que o próprio time do Railway usa é boa: pense em um Shinkansen ou um Maglev — trilhos tão bem feitos que o trem simplesmente desliza. 🚄

O que é o servidor MCP remoto do Railway e por que isso importa

O MCP, ou Model Context Protocol, é um padrão aberto que define como modelos de linguagem e agentes de IA se comunicam com ferramentas externas. Pensa nele como uma espécie de linguagem comum que permite que um agente rodando no Cursor, no Claude Code ou em qualquer outro ambiente compatível consiga interagir com serviços externos de forma padronizada e segura. Até pouco tempo atrás, usar MCP exigia rodar um servidor localmente na sua máquina, o que criava fricção, dependia do ambiente configurado corretamente e dificultava o uso em times ou em cenários de automação mais complexos.

O que o Railway fez foi dar um passo à frente e disponibilizar esse servidor de forma remota, acessível diretamente pelo endereço mcp.railway.com. Isso significa que você não precisa instalar nada, não precisa configurar um processo rodando em segundo plano e não precisa se preocupar com versões ou compatibilidades locais. Basta apontar seu agente para o endereço do servidor MCP remoto, autenticar com sua conta do Railway via OAuth pelo navegador e pronto: o agente passa a ter acesso controlado ao que a plataforma oferece.

A página de setup em mcp.railway.com foi construída especificamente para deixar tudo mais simples. Ela traz abas para cada editor suportado — Claude, Cursor, Codex, GitHub Copilot, Droid, OpenCode e uma configuração genérica para qualquer outro cliente. Cada aba tem um snippet pronto para copiar e, no caso do Cursor, existe até um botão de instalação com um clique. O caminho do zero até a conexão funcionando leva poucos minutos.

Na autenticação, o consentimento OAuth abre no navegador na primeira vez que você conecta. Ali você escolhe quais workspaces e projetos o cliente pode acessar, e pode revogar essa permissão a qualquer momento nas configurações do Railway. Nada de login pelo CLI, nada de tokens salvos em disco, nada de ficar garimpando arquivos de configuração escondidos.

O que dá pra fazer com o servidor MCP remoto

Uma vez conectado, o agente consegue listar projetos, ler e atualizar variáveis, fazer redeploy de serviços e — o mais interessante — chamar o railway-agent para delegar tarefas em linguagem natural ao agente de IA do Railway. Na prática, isso abre um leque enorme de possibilidades para quem trabalha com desenvolvimento de software assistido por IA.

Como Implementar as Melhores Ferramentas de IA

Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.

Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.

Entrega em PDF no seu e-mail · Sem spam · LGPD

🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.

Alguns exemplos do que funciona direto, sem configuração adicional:

Ver o que você já tem rodando: pedir para o agente mostrar todos os seus projetos no Railway e quais serviços existem em cada um
Criar algo novo: solicitar a criação de um novo projeto diretamente pelo editor
Investigar problemas: pedir para o agente do Railway descobrir por que um serviço backend está falhando no deploy

Esse último cenário é o que mais chama atenção. Quando você pede algo como investigar por que um serviço está crashando, o seu cliente envia a pergunta para o railway-agent, e o agente do Railway faz toda a investigação internamente — lendo logs, verificando configurações, correlacionando deploys — e devolve um resumo consolidado. Do ponto de vista do seu editor, é um único round-trip. Todo o raciocínio multi-etapa acontece do lado do Railway.

Para quem prefere uma configuração totalmente local, o servidor MCP local continua sendo mantido junto com o CLI do Railway. As duas opções coexistem sem conflito.

O comando railway agent no CLI e o que ele muda no fluxo de trabalho

Para quem vive no terminal, a novidade mais empolgante é o novo comando railway agent disponível no CLI da plataforma. Nem todo mundo quer que a experiência com agentes viva dentro de um editor de código, e o Railway reconheceu isso ao criar uma alternativa que funciona diretamente na linha de comando.

Na forma mais básica, o comando funciona assim: você digita railway agent -p seguido do que precisa, em linguagem natural, e o agente responde. Ele se conecta ao mesmo agente que o dashboard do Railway utiliza, com acesso às mesmas ferramentas internas. As opções de uso são bem flexíveis:

Sessão interativa: basta rodar railway agent sem argumentos para iniciar uma conversa de ida e volta que mantém o contexto dentro da sessão
Prompt único: usar a flag -p para enviar uma pergunta rápida ou executar em scripts
Saída em JSON: a flag –json retorna a resposta estruturada, incluindo o ID da thread e cada tool call que o agente executou, perfeito para encadear em automações
Continuação de thread: com –thread-id você retoma uma conversa anterior de onde parou
Escopo por serviço ou ambiente: as flags –service e –environment permitem direcionar o agente para um contexto específico

Alguns cenários práticos que já funcionam bem desde o primeiro dia:

Pedir para o agente adicionar um banco Postgres a um projeto e configurar a variável DATABASE_URL no serviço de API
Solicitar ajuda para investigar por que um serviço backend está falhando no deploy
Verificar uso de memória e CPU dos serviços
Listar serviços e seus status com saída JSON, pronta para ser processada por ferramentas como jq

O mais bacana é que o comando funciona bem em pipelines de CI, já que respeita o escopo do token do usuário — ele pode fazer exatamente o que você pode fazer, nada além disso. Isso dá segurança para incorporar o agente em fluxos automatizados sem medo de permissões escaparem do controle.

A estratégia por trás das ferramentas MCP: menos é mais

Uma decisão de design particularmente interessante nesse lançamento é a abordagem minimalista da superfície de ferramentas do servidor MCP. O instinto natural quando se constrói um servidor MCP é expor tudo: transformar cada chamada de API em uma ferramenta, espelhar cada comando do CLI e entregar uma lista gigante de opções. Mais ferramentas significam mais capacidade, certo?

O Railway foi na direção oposta. O servidor MCP remoto chegou com apenas 7 ferramentas, e o time já está planejando reduzir esse número. Quando o post de anúncio foi rascunhado, eram 9. Já cortaram duas.

As ferramentas disponíveis hoje são:

whoami — identifica quem está autenticado
list-projects — lista todos os projetos que você pode ver
create-project — cria um novo projeto
list-services — mostra serviços e ambientes dentro de um projeto
redeploy — dispara um novo deploy
accept-deploy — confirma e aplica mudanças staged, marcado como ação destrutiva com prompt de aprovação no cliente
railway-agent — delega tarefas em linguagem natural para o agente de IA do Railway

A razão para essa escolha é dupla e tem tudo a ver com contexto.

Contexto é caro dos dois lados

Do lado do cliente, cada definição de ferramenta exposta vive no prompt do agente — em todas as interações, antes do trabalho real do usuário começar. Uma superfície de 7 ferramentas é leve. Uma de 25 ferramentas não é. E quanto maior a lista, pior fica a qualidade de seleção do modelo na hora de escolher qual ferramenta usar. Esse custo é pago pelo usuário, da janela de contexto dele, em cada interação.

Do lado do servidor, cada round-trip de tool call também consome contexto quando o resultado volta. Uma operação multi-etapa como investigar um deploy com falha pode significar 6 chamadas de ferramentas individuais, custando ao usuário 6 viagens de contexto antes de receber uma resposta útil.

O railway-agent resolve esse problema dos dois lados. O cliente envia uma única mensagem em linguagem natural. O agente do Railway faz toda a investigação multi-etapa internamente — lendo logs, checando configuração, correlacionando deploys, o que for necessário — e retorna uma resposta consolidada. A complexidade de orquestração fica do lado do Railway, onde pode ser melhorada continuamente. O contexto do usuário permanece barato.

Para onde essa estratégia está indo

A direção de médio prazo é clara: manter as ferramentas MCP diretas no mínimo e empurrar cada vez mais o comportamento rico e multi-etapa para dentro do railway-agent. As ferramentas que ficam expostas diretamente são aquelas com limites bem definidos e que não precisam de raciocínio — listar projetos, criar projeto, redeploy. CRUD limpo e discovery básico.

Tudo que é essencialmente uma pergunta disfarçada — como o que há de errado com meu serviço, como devo configurar um banco de dados para isso, ou por que meu último deploy falhou — deve ser roteado pelo railway-agent, onde o agente gerencia o sequenciamento.

Se essa abordagem der certo, dois benefícios ficam evidentes:

O contexto do usuário permanece enxuto, sem pagar por definições de ferramentas que raramente são tocadas, e operações multi-etapa custam um round-trip em vez de seis
A orquestração melhora em um único lugar, e cada cliente MCP e cada usuário do CLI recebe o benefício automaticamente, sem breaking changes na superfície de ferramentas e sem precisar atualizar configurações

Um efeito colateral interessante: como o railway-agent rastreia quais sub-ferramentas ele chama internamente, o time do Railway ganha dados reais de uso sobre quais capacidades eventualmente merecem ser promovidas de volta a uma ferramenta MCP de nível superior. A superfície de ferramentas não é definida por adivinhação — o uso real informa as decisões. 📊

Por dentro da engenharia: como tudo funciona

Para quem gosta de entender a mecânica por baixo do capô, o Railway compartilhou alguns detalhes de implementação que valem ser mencionados.

Ambas as superfícies — o servidor MCP remoto e o comando railway agent no CLI — conversam com o mesmo backend. Na prática, isso significou expor o agente do Railway como um endpoint REST simples, de forma que qualquer coisa capaz de fazer uma requisição HTTP consiga alcançá-lo. Por causa dessa abordagem centralizada, cada melhoria feita no agente dentro do Railway automaticamente se reflete nas duas superfícies.

O servidor MCP não é um serviço separado

Uma decisão arquitetural que chamou atenção foi a escolha de não criar um serviço separado para o servidor MCP. A primeira versão da arquitetura seguia o caminho clássico: serviço independente, Postgres próprio, Redis separado, deploy independente. Mas conforme o desenvolvimento avançou, o time percebeu que estava reconstruindo boa parte do que a aplicação principal já fazia — sessões de usuário, grants OAuth, permissões de workspace e projeto, dataloaders, criptografia, analytics.

Receba o melhor conteúdo de inovação em seu e-mail

Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.

Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.

O que era para ser um serviço independente começou a parecer um proxy elaborado de volta para o monolito. Então a decisão foi incorporar o servidor MCP como um route handler dentro do backend principal do Railway. O middleware de sessão que já autentica todas as outras requisições resolve o token antes do handler rodar, e o trabalho do handler em si é enxuto: montar o contexto, criar uma instância do servidor MCP SDK com o transporte adequado e entregar a requisição.

Essa abordagem trouxe várias vantagens concretas:

OAuth reaproveita o provedor OIDC existente — sem segundo sistema de autenticação, sem interface de consentimento duplicada, mesma infraestrutura de grants
As ferramentas chamam controllers diretamente — sem hop extra via GraphQL, sem reenvio de tokens, sem duplicar lógica de permissão em dois lugares
O contexto flui via AsyncLocalStorage — os handlers de cada ferramenta acessam autenticação, permissões e dados sem precisar passar contexto manualmente por cada chamada

O resultado é que uma ferramenta como o redeploy, por exemplo, tem uma implementação surpreendentemente simples. Sem verificação de auth dentro do handler. Sem checagem de permissão manual. Sem boilerplate de try/catch. O controller chamado é o mesmo que o dashboard e a API GraphQL usam — uma única fonte de verdade para a operação de redeploy de um serviço.

O endpoint de discovery OAuth em mcp.railway.com também não cria um segundo sistema de autenticação. Ele funciona como um ponteiro de volta para o provedor OIDC do backend principal, com o parâmetro de audience binding pré-configurado na URL de autorização anunciada. Todos os endpoints apontam de volta para o backend. Nenhum estado OAuth paralelo, nenhuma interface de consentimento duplicada.

Um sistema de autenticação. Um modelo de permissão. Um lugar para melhorar o agente. Dois pontos de entrada que encontram as pessoas onde elas já trabalham.

O que esses lançamentos dizem sobre o futuro do desenvolvimento de software

Olhando para o cenário mais amplo, o que o Railway está fazendo reflete uma tendência que vai se tornar cada vez mais comum entre plataformas de infraestrutura e deploy. À medida que os agentes de IA se tornam mais capazes e mais integrados ao processo de desenvolvimento de software, as plataformas que não oferecerem interfaces compatíveis com esses agentes vão ficando para trás. Não é mais suficiente ter uma boa UI ou uma API bem documentada. As ferramentas precisam falar a língua dos agentes, e o protocolo MCP está se consolidando como um dos principais padrões para isso acontecer.

O movimento do Railway também sinaliza algo relevante sobre como a complexidade de infraestrutura pode ser abstraída de forma inteligente. Por muito tempo, fazer deploy de aplicações exigiu que o desenvolvedor entendesse profundamente cada camada da infraestrutura, desde configuração de servidores até regras de rede e variáveis de ambiente. Com um agente bem integrado à plataforma, boa parte dessa complexidade pode ser delegada, não porque o desenvolvedor não precisa mais entender o que está acontecendo, mas porque o agente pode lidar com as tarefas mais repetitivas e técnicas enquanto o foco humano vai para o que realmente importa: resolver problemas e construir produtos.

A forma como as pessoas usam agentes com essas ferramentas ainda está mudando a cada poucos dias. O próprio time do Railway reconhece isso e deixou aberto um canal de feedback para que a comunidade ajude a moldar o que vem pela frente — quais ferramentas adicionar, quais aposentar e como o agente deve evoluir.

Para quem acompanha o ecossistema de software e inteligência artificial, esses lançamentos do Railway são um sinal claro de que a integração entre agentes e infraestrutura está amadurecendo em ritmo acelerado. O servidor MCP remoto e o comando railway agent no CLI podem parecer peças pontuais, mas têm um impacto significativo na forma como o trabalho de desenvolvimento pode fluir no dia a dia. E o mais interessante é que isso é só o começo: à medida que mais plataformas adotarem o MCP e ampliarem suas capacidades de agente, o fluxo de desenvolvimento tende a ficar cada vez mais fluido, conectado e inteligente. 🤖