Descubra como dados viajam entre Client e Server — STDIO para local, HTTP para web e SSE para streaming em tempo real.
No MCP, o transporte é a camada que define como Client e Server se comunicam fisicamente — por qual canal os dados viajam. O protocolo MCP em si é independente do transporte: ele define o formato das mensagens (o "quê"), mas não impõe como essas mensagens chegam ao destino (o "como"). Isso significa que o mesmo server pode funcionar sobre diferentes meios de comunicação sem precisar alterar sua lógica interna.
Pense no transporte como o meio de envio de uma mensagem. Você pode enviar a mesma carta pelo correio, por e-mail ou ler por telefone — o conteúdo da mensagem é idêntico, mas o canal muda. No MCP, a mensagem JSON-RPC é sempre a mesma, mas ela pode viajar por STDIO (dentro da mesma máquina), HTTP (pela rede) ou SSE (streaming pela rede). O server não precisa saber qual transporte está sendo usado — ele apenas processa as mensagens que chegam.
O MCP suporta oficialmente três transportes: STDIO, HTTP e SSE. Essa separação entre protocolo e transporte é um padrão arquitetural consagrado — o próprio HTTP funciona sobre TCP, mas poderia funcionar sobre qualquer protocolo de transporte confiável. Essa independência é o que permite ao MCP ser tão flexível: funciona tanto em um script local na sua máquina quanto em um servidor em nuvem servindo milhares de clientes simultaneamente.
O transporte STDIO (Standard Input/Output) é o mais simples e direto dos três. Neste modo, o Client e o Server rodam na mesma máquina, e a comunicação acontece através dos canais padrão de entrada e saída do processo — o famoso stdin e stdout. O Client inicia o Server como um processo filho e envia mensagens pelo stdin do processo. O Server responde pelo stdout. Sem rede, sem portas, sem configuração HTTP — apenas dois processos conversando diretamente.
No STDIO, o Client spawna (inicia) o Server como um processo filho no sistema operacional. A comunicação flui através dos pipes padrão: o Client escreve no stdin do Server e lê do stdout do Server. Cada mensagem é uma linha JSON-RPC terminada com newline. É o transporte mais rápido porque não há overhead de rede — os dados passam diretamente pela memória do sistema operacional. Ideal para ferramentas locais como acesso a arquivos, execução de comandos e integração com IDEs.
STDIO é perfeito para desenvolvimento local e ferramentas que rodam no seu computador. Se o seu server MCP acessa arquivos locais, executa scripts ou interage com programas instalados na máquina, STDIO é a escolha natural. É também o mais fácil de depurar — você pode literalmente ver as mensagens sendo trocadas no terminal.
O transporte HTTP permite que Client e Server estejam em máquinas diferentes, comunicando-se pela rede. O Server expõe endpoints HTTP e o Client envia requisições padrão (POST) contendo mensagens JSON-RPC. É o transporte ideal para servers remotos, APIs em nuvem e cenários onde o server precisa ser acessado por múltiplos clients simultaneamente.
No transporte HTTP, o Server MCP roda como um serviço web que escuta em uma porta (ex: porta 3000). O Client envia mensagens JSON-RPC como corpo de requisições POST para o endpoint do server. O server processa a requisição e retorna a resposta no corpo da resposta HTTP. É o mesmo modelo familiar de qualquer API REST — mas em vez de endpoints variados, todas as mensagens MCP passam por um único endpoint, com o tipo da operação definido dentro do JSON-RPC.
O Client monta uma mensagem JSON-RPC (ex: chamar uma tool) e a envia como corpo de um POST HTTP para o endpoint do Server.
O Server recebe a requisição, desserializa o JSON-RPC, identifica o método solicitado e executa a lógica correspondente.
O Server monta a resposta JSON-RPC com o resultado (ou erro) e a envia de volta no corpo da resposta HTTP ao Client.
O HTTP é o protocolo mais usado na web, o que torna o transporte HTTP do MCP nativamente compatível com toda a infraestrutura existente: load balancers, proxies reversos, firewalls, certificados TLS e ferramentas de monitoramento. Servers MCP sobre HTTP podem ser deployados em qualquer plataforma de nuvem (AWS, GCP, Azure) e escalar horizontalmente usando as mesmas técnicas usadas para qualquer API web tradicional.
O SSE (Server-Sent Events) é uma extensão do HTTP que permite streaming unidirecional do Server para o Client. Em vez de o Client enviar uma requisição e esperar a resposta completa, o Server abre um canal persistente e envia dados continuamente à medida que ficam disponíveis. No MCP, isso é ideal para operações longas — como processar um arquivo grande ou executar uma consulta demorada — onde o Client precisa receber atualizações de progresso em tempo real.
Com SSE, o Server pode enviar dados ao Client sem que o Client precise ficar perguntando (polling). O Client faz uma única requisição HTTP, e a conexão permanece aberta. O Server então envia eventos pelo canal sempre que há novos dados. No contexto MCP, isso permite que o server envie notificações de progresso, resultados parciais e atualizações de estado em tempo real. O Client usa POST para enviar mensagens ao Server, e o Server usa o canal SSE para enviar respostas e notificações de volta.
Use SSE quando seu server MCP precisa enviar atualizações em tempo real ao client — por exemplo, progresso de processamento de arquivos, logs de execução ao vivo ou resultados que chegam gradualmente. SSE é suportado nativamente pelos navegadores e funciona com a infraestrutura HTTP existente, sem necessidade de WebSocket.
Cada transporte tem suas forças e fraquezas. A escolha depende do cenário: onde o server roda, quantos clients precisa atender, se há necessidade de streaming e qual a complexidade aceitável. Entender as diferenças é fundamental para tomar a decisão certa na hora de implementar seu server MCP.
| Critério | STDIO | HTTP | SSE |
|---|---|---|---|
| Localização | Mesma máquina | Qualquer lugar | Qualquer lugar |
| Velocidade | Muito rápido | Rápido | Rápido |
| Complexidade | Mínima | Moderada | Moderada |
| Streaming | Não | Não | Sim |
| Multi-client | Não | Sim | Sim |
| Caso ideal | Dev local, IDEs | APIs em nuvem | Tempo real |
Atualmente, STDIO é usado em aproximadamente 70% dos servers MCP em produção, justamente por ser o mais simples de implementar e testar. HTTP aparece em cerca de 25% dos casos — principalmente em servers deployados em nuvem. SSE ainda é o menos adotado (~5%), mas sua participação cresce à medida que mais aplicações demandam streaming e feedback em tempo real. A tendência é que HTTP e SSE ganhem espaço conforme o ecossistema amadurece e mais servers migram para ambientes remotos.
Na prática, a escolha do transporte se resume a responder algumas perguntas simples: onde o server vai rodar? Quantos clients precisam se conectar? Há necessidade de streaming? Na dúvida, a regra de ouro é: comece com STDIO. É o mais fácil de configurar, testar e depurar. Quando precisar de acesso remoto, migre para HTTP. Quando precisar de streaming, adicione SSE.
Guia de decisão para escolher o transporte:
Comece sempre com STDIO — é o mais fácil de testar e depurar. Você pode ter um server funcionando em minutos, sem configurar portas, URLs ou certificados. Quando estiver satisfeito com a lógica do server, migrar para HTTP ou SSE é uma mudança apenas na camada de transporte — todo o código do server permanece o mesmo. Essa é a beleza da separação protocolo/transporte do MCP.
Não complique no início. Um erro comum de iniciantes é querer usar HTTP ou SSE quando STDIO resolve perfeitamente o problema. Configurar transporte de rede adiciona complexidade desnecessária nas fases iniciais: portas, CORS, autenticação, TLS, firewalls. Foque primeiro na lógica do seu server — tools, resources, prompts — e só depois se preocupe com o transporte de produção. Otimize quando houver necessidade real, não por antecipação.
Próxima Trilha: Trilha 2 - Ambiente de Desenvolvimento