Converta seu MCP Server de STDIO para HTTP — permitindo acesso remoto e deploy em nuvem.
O MCP suporta dois modelos de transporte: STDIO (entrada/saída padrão) e HTTP (via rede). STDIO é local, simples e rápido — ideal para desenvolvimento e uso pessoal. HTTP é remoto, acessível pela rede e perfeito para deploy em cloud. A pergunta-chave é: quando migrar? Quando outros precisam acessar seu server — seja sua equipe, seus clientes ou sua infraestrutura de produção.
STDIO funciona como um pipe Unix: o client lança o server como processo filho e se comunica via stdin/stdout. É zero-config e instantâneo, mas limitado à máquina local. HTTP expõe o server como um serviço web: qualquer client na rede pode se conectar via URL. Isso habilita cenários como múltiplos clients simultâneos, deploy em containers, e acesso de qualquer lugar do mundo. A troca é que HTTP exige configuração de rede, segurança e infraestrutura — mas o ganho em flexibilidade é enorme.
A especificação MCP define oficialmente dois transportes: STDIO e HTTP com SSE. Na prática, a maioria dos MCP Servers em produção utiliza HTTP/SSE para permitir integração com múltiplos clients e deploy em nuvem. O protocolo HTTP adiciona tipicamente 1-5ms de latência por requisição em redes locais, mas essa diferença é imperceptível comparada ao tempo de processamento das ferramentas. A versão mais recente do protocolo também suporta Streamable HTTP, uma evolução do SSE com melhor suporte a reconexão.
O FastMCP abstrai toda a complexidade de configurar um servidor HTTP. Com uma única linha de código, você troca o transporte de STDIO para HTTP ou SSE. O framework cuida de rotas, serialização JSON-RPC, gerenciamento de conexões e streaming — você foca na lógica das suas tools.
Configurar HTTP no FastMCP é trocar um único parâmetro:
# Antes — transporte STDIO (padrão) mcp.run() # Depois — transporte HTTP mcp.run(transport="http", host="0.0.0.0", port=8000) # Ou com SSE (Server-Sent Events) mcp.run(transport="sse", host="0.0.0.0", port=8000)
O parâmetro host="0.0.0.0" aceita conexões de qualquer IP (necessário para Docker/cloud). O port define a porta do servidor. O FastMCP usa internamente o uvicorn como servidor ASGI, garantindo performance e compatibilidade com o ecossistema Python.
Use uma variável de ambiente para alternar entre transportes sem modificar o código: transport = os.getenv("MCP_TRANSPORT", "stdio"). Em desenvolvimento local, use STDIO. Em produção, defina MCP_TRANSPORT=http. Assim, o mesmo código funciona em ambos os cenários sem nenhuma alteração no source.
Adicionar uvicorn e starlette às dependências no pyproject.toml.
Alterar mcp.run() para mcp.run(transport="http", host="0.0.0.0", port=8000).
Testar localmente acessando http://localhost:8000 e verificar que as tools respondem via HTTP.
SSE (Server-Sent Events) é uma tecnologia que permite o server enviar atualizações contínuas para o client via uma conexão HTTP persistente. Diferente de WebSockets (bidirecional), SSE é unidirecional: o server envia, o client recebe. Isso é ideal para operações longas onde o client precisa acompanhar o progresso em tempo real.
No transporte SSE do MCP, o client faz uma requisição HTTP e mantém a conexão aberta. O server envia mensagens JSON-RPC como eventos SSE conforme processa as requisições. Isso permite streaming de resultados parciais, notificações de progresso e respostas incrementais. O MCP usa SSE como canal de resposta enquanto o client envia requisições via POST normal. Essa arquitetura é robusta e funciona bem com proxies, load balancers e CDNs — diferente de WebSockets que requerem suporte especial de infraestrutura.
SSE é suportado nativamente por todos os browsers modernos e pela maioria dos frameworks HTTP. Comparado a WebSockets, SSE usa HTTP padrão, o que significa compatibilidade total com proxies reversos (Nginx, Cloudflare) sem configuração especial. A reconexão automática é built-in na spec SSE — se a conexão cair, o browser reconecta automaticamente usando o último Last-Event-ID. A evolução do SSE no MCP é o Streamable HTTP, que combina POST para envio e SSE para recebimento em um único endpoint.
Expor um MCP Server via HTTP significa expô-lo à rede — e potencialmente à internet. Segurança não é opcional: HTTPS obrigatório em produção, autenticação via headers, configuração de CORS e rate limiting são o mínimo. Um server MCP sem proteção é uma porta aberta para execução de código arbitrário.
Checklist de segurança para MCP Server HTTP:
Authorization: Bearer <token>).NUNCA use HTTP sem TLS em produção! Sem HTTPS, tokens de autenticação, dados de requisições e respostas trafegam em texto puro — qualquer pessoa na mesma rede pode interceptar. Um MCP Server expõe tools que podem executar código, acessar bancos de dados e manipular arquivos. HTTP sem TLS em produção é equivalente a deixar a porta do cofre aberta com a senha colada na parede.
allow_origins=["*"] em produçãoCom o server rodando via HTTP, o próximo passo é colocá-lo na nuvem. Existem diversas opções — desde plataformas simples como Railway e Fly.io até infraestrutura completa com AWS Lambda ou Docker em VPS. A escolha depende do seu orçamento, escala e necessidades de controle.
Um Dockerfile básico para deploy do MCP Server:
FROM python:3.12-slim WORKDIR /app COPY . . RUN pip install --no-cache-dir . ENV MCP_TRANSPORT=http ENV PORT=8000 EXPOSE 8000 CMD ["meu-server"]
O Dockerfile instala o pacote Python, define variáveis de ambiente e expõe a porta. Plataformas como Railway e Fly.io detectam automaticamente o Dockerfile e fazem o build. Para AWS Lambda, use um adapter como mangum para converter ASGI em Lambda handler.
Criar o Dockerfile na raiz do projeto com a configuração do server HTTP.
Configurar variáveis de ambiente na plataforma: tokens de API, MCP_TRANSPORT, porta e secrets.
Fazer push do código para o repositório Git conectado à plataforma — o deploy é automático.
Verificar os logs de deploy, testar a URL pública e configurar domínio customizado se necessário.
Para projetos pessoais e MVPs, Railway e Fly.io são as opções mais rápidas — deploy direto do GitHub em minutos, com HTTPS automático e tier gratuito. Para produção com mais controle, use Docker + VPS (Hetzner, DigitalOcean) com Nginx como reverse proxy e Let's Encrypt para TLS. Sempre use .dockerignore para excluir .env, .git e __pycache__.
Com o server deployed, é hora de verificar que tudo funciona de fora — de outra máquina, de outra rede, como um client real faria. Testar remotamente revela problemas que testes locais escondem: firewalls, DNS, latência de rede e configurações de CORS.
Testando com curl e configurando client remoto:
# Testar se o server responde $ curl https://meu-server.railway.app/sse # Configurar no Claude Desktop (claude_desktop_config.json) { "mcpServers": { "meu-server": { "url": "https://meu-server.railway.app/sse" } } }
Para clients HTTP/SSE, basta apontar a URL do server deployed. O client se conecta via HTTPS, mantém a conexão SSE aberta e envia requisições normalmente. Verifique latência com curl -w "%{time_total}" para garantir que o tempo de resposta é aceitável.
Teste a partir de múltiplos ambientes: sua máquina local, uma VM em outra região, e o celular (via hotspot 4G). Cada ambiente revela problemas diferentes — DNS pode falhar em uma rede, CORS pode bloquear em um browser, e latência pode ser inaceitável de outra região. Use mcp-cli ou npx @modelcontextprotocol/inspector para inspecionar as mensagens JSON-RPC trocadas.
Verificar que a URL pública responde com curl — HTTP 200 no health check.
Conectar um MCP client remoto e listar as tools disponíveis com tools/list.
Executar uma tool e medir a latência — verificar que o tempo de resposta é menor que 5 segundos para operações simples.
Próximo Módulo: 5.4 — MCP com TypeScript