MCP stdio ou HTTP remoto: qual transporte usar na empresa

MCP stdio ou HTTP remoto: qual transporte usar na empresa

Use stdio quando o servidor MCP serve a uma pessoa, roda na máquina dela e acessa só recursos locais. Use HTTP remoto quando vários usuários ou agentes precisam do mesmo servidor, quando ele toca sistemas da empresa e quando você precisa de autenticação por usuário, logs centralizados e atualização num lugar só. A escolha não é sobre qual transporte é mais moderno, e sim sobre onde o servidor roda, quem responde por ele e o que você consegue enxergar quando algo dá errado.

Principais pontos

• No stdio, o cliente inicia o servidor como processo local e conversa com ele pela entrada e saída padrão. Não há rede envolvida, mas também não há controle central.
• No HTTP remoto, o servidor é um serviço independente, com endereço, autenticação e ciclo de vida próprios. Dá para governar, mas você passa a operar um serviço.
• Segurança, manutenção e observabilidade pesam de forma diferente em cada modo. Stdio espalha o risco por várias máquinas. HTTP concentra o risco num ponto que precisa ser bem protegido.
• Servidores que acessam dados de clientes, ERP, CRM ou qualquer sistema sensível tendem a ficar melhor remotos, com permissões por usuário. Ferramentas pessoais e de desenvolvimento tendem a ficar locais.
• Comece com um servidor, uma ação de leitura, logs e um critério de sucesso combinado. Depois decida se expande, ajusta ou para.

O que muda entre stdio e HTTP remoto?

O Model Context Protocol define como um aplicativo de IA (o cliente) se conecta a ferramentas e fontes de dados (os servidores). A introdução oficial do protocolo apresenta essa ideia de forma geral. O transporte é a camada que carrega as mensagens entre os dois lados, e a especificação do protocolo descreve dois modos padrão: stdio e HTTP (chamado de Streamable HTTP na especificação atual). Vale conferir o texto vigente da especificação antes de fechar uma decisão de arquitetura, porque esse trecho evolui.

No stdio, o cliente executa o servidor como um subprocesso na mesma máquina. As mensagens trafegam pela entrada e pela saída padrão do processo. Quando o cliente fecha, o servidor termina junto. O servidor herda o ambiente do usuário: variáveis, arquivos, credenciais e permissões do sistema operacional daquela pessoa.

No HTTP remoto, o servidor é um serviço que fica ligado em algum lugar (um servidor da empresa, uma nuvem, um contêiner) e atende requisições de vários clientes. Ele tem URL, precisa de autenticação, passa por balanceador ou proxy, pode ter versão única e é monitorado como qualquer outro serviço.

Essa diferença parece técnica, mas ela decide três coisas de negócio: quem pode usar a ferramenta, quem a mantém e quem consegue provar o que ela fez.

Segurança: quem tem acesso a quê

No stdio, o servidor roda com as permissões de quem o iniciou. Isso é simples e, para uso pessoal, muitas vezes suficiente. O problema aparece em escala. Se vinte pessoas instalam o mesmo servidor, existem vinte cópias, possivelmente em versões diferentes, cada uma com credenciais guardadas em arquivos de configuração ou variáveis de ambiente do notebook. Um token de API colado num arquivo local é um risco de vazamento que a empresa não enxerga. Se a chave for compartilhada entre todos, você também perde a noção de quem fez o quê. O tema de guarda e troca de segredos tem um tratamento próprio em chaves de API em agentes de IA: onde guardar e como rotacionar.

O stdio também herda um risco clássico: instalar um servidor significa executar código de terceiros na máquina do usuário, com os acessos dele. Um pacote malicioso ou comprometido pode ler arquivos, variáveis e a rede local. Por isso, auditar antes de instalar é obrigatório, como descrevemos em como auditar um servidor MCP antes de instalar na empresa.

No HTTP remoto, o código não roda na máquina do usuário, e isso reduz a superfície no notebook. Em troca, você expõe um endpoint. A especificação do protocolo trata de autorização para o modo HTTP com base em OAuth, e recomenda cuidados como validar a origem das requisições quando o servidor roda localmente. Na prática, isso significa:

• autenticar cada usuário ou cada agente, e não usar uma chave única compartilhada;
• aplicar autorização por ferramenta e por recurso, seguindo princípios como os do guia de autorização da OWASP;
• guardar segredos do sistema integrado no servidor, e não no equipamento de cada pessoa;
• expor o serviço só para a rede ou VPN que precisa dele, quando possível.

Há ainda um risco que vale para os dois modos: injeção de prompt. Se uma ferramenta devolve texto vindo de e-mails, páginas ou mensagens de clientes, esse texto pode conter instruções maliciosas. O transporte não resolve isso. O que reduz o dano é limitar o que a ferramenta pode fazer, exigir aprovação humana para ações sensíveis e separar leitura de escrita. A lista das dez principais vulnerabilidades em aplicações com LLM da OWASP é um bom roteiro de revisão.

Sobre LGPD: quando o servidor acessa dados pessoais, importa saber onde esses dados trafegam e ficam registrados. Num servidor remoto central, é mais fácil definir finalidade, retenção e acesso. Em dezenas de máquinas, logs e caches locais podem guardar dados pessoais sem que ninguém tenha mapeado isso.

Manutenção: quem atualiza e quem responde quando quebra

O stdio é barato de começar. Não há servidor para provisionar, domínio, certificado ou balanceador. O custo vem depois: atualização manual, dependências divergentes (runtime, versão de Node ou Python), suporte caso a caso e o clássico "na minha máquina funciona". Quando o fornecedor do servidor corrige uma falha de segurança, alguém precisa garantir que todas as cópias foram atualizadas.

O HTTP remoto inverte isso. Existe um custo inicial de operação: hospedagem, deploy, monitoramento, rotação de segredos, plano para indisponibilidade. Em compensação, uma correção vira uma publicação só. Você controla a versão, faz rollback, testa antes de liberar e desliga o acesso de uma pessoa sem entrar no computador dela. Se a ferramenta depende de um provedor de LLM ou de uma API externa, também fica mais fácil tratar limites e quedas num ponto central, tema de rate limit e queda de API de LLM.

Há uma terceira consideração: quem vai operar. Um serviço remoto sem dono vira dívida. Antes de escolher HTTP, defina quem recebe o alerta, quem aprova mudanças e quem desliga o servidor em caso de incidente. Se a empresa não tem essa pessoa ou esse parceiro, é melhor admitir que o servidor ainda não está pronto para ser remoto. Para quem hospeda, onde hospedar um agente de IA: VPS, nuvem ou servidor próprio ajuda a comparar as opções.

Observabilidade: o que você consegue enxergar

Observabilidade, como resume o primer do OpenTelemetry, é a capacidade de entender o estado interno de um sistema a partir de sinais que ele emite: logs, métricas e rastros. Para MCP, as perguntas práticas são: qual ferramenta foi chamada, por quem, com quais parâmetros, qual foi o resultado, quanto tempo levou e se houve erro.

No stdio, esses sinais nascem na máquina do usuário. Um detalhe técnico importante: como a saída padrão carrega as mensagens do protocolo, os logs do servidor devem ir para outro canal (normalmente a saída de erro ou um arquivo), senão corrompem a comunicação. Para a empresa, o resultado é que os logs ficam espalhados. Reconstruir o que aconteceu numa conversa exige pedir arquivos a cada pessoa, e isso raramente funciona depois de um incidente.

No HTTP remoto, o servidor é o ponto natural de coleta. Você registra cada chamada com identificador do usuário, ferramenta, parâmetros relevantes (mascarando dados pessoais), resultado e latência, e envia tudo para a ferramenta de monitoramento que a empresa já usa. Isso permite alertas, auditoria e revisão periódica. Se houver necessidade de padronizar o rastreamento de chamadas a modelos, as convenções semânticas do OpenTelemetry para IA generativa são uma referência.

O que deve estar no log de uma chamada, em qualquer transporte:

• quem pediu (usuário ou agente) e em qual contexto;
• qual ferramenta foi chamada e se era leitura ou escrita;
• parâmetros, com mascaramento de dados pessoais;
• resultado resumido ou código de erro;
• se houve aprovação humana e de quem.

Como decidir: um guia por tipo de servidor

Use a lista abaixo como ponto de partida. Cada item descreve uma situação e o transporte que costuma fazer mais sentido.

• Ferramenta pessoal de produtividade que lê pastas do próprio usuário: stdio, com servidor auditado e versão fixada.
• Ferramenta de desenvolvimento que age no repositório local, usada por uma pessoa de cada vez: stdio, com permissões e isolamento do ambiente de desenvolvimento. Veja segurança no Claude Code para empresas.
• Servidor que acessa ERP, CRM, base de clientes ou financeiro: HTTP remoto, com autenticação por usuário, permissões por ferramenta e logs centrais.
• Servidor compartilhado por vários agentes (por exemplo, atendimento no WhatsApp e uma rotina interna): HTTP remoto, para que regras e limites fiquem num lugar só.
• Servidor que executa ações com efeito externo (enviar mensagem, alterar pedido, emitir algo): HTTP remoto, com aprovação humana e registro de decisão.
• Servidor de terceiros que você ainda não auditou: nem um nem outro até auditar. Se precisar testar, use ambiente isolado e dados fictícios.
• Prova de conceito de uma semana: stdio costuma bastar, desde que exista a decisão registrada de migrar ou descartar.

Uma regra simples resume a lista: quanto mais gente, mais dados sensíveis e mais ações com efeito real, mais o servidor deve ir para o remoto. Quanto mais pessoal, descartável e restrito à máquina, mais o stdio se justifica.

Cenário ilustrativo: de local para remoto

Imagine, como cenário ilustrativo, uma empresa de serviços que começa com um servidor MCP de consulta ao CRM rodando em stdio no notebook de uma analista. Para testar, funciona bem: ela pergunta ao assistente sobre o histórico de um contato e recebe a resposta.

Quando outras pessoas do comercial pedem o mesmo acesso, aparecem os problemas. Cada uma precisaria de um token do CRM no próprio computador. Ninguém sabe qual versão do servidor está instalada em cada máquina. Se alguém sair da empresa, o token continua válido até que alguém lembre de revogá-lo. E não existe um lugar único para ver quais consultas foram feitas.

A decisão razoável nesse momento é migrar o servidor para HTTP remoto, com login por usuário, permissão somente de leitura e logs centrais. O servidor passa a guardar a credencial do CRM, e as pessoas deixam de ter acesso direto ao token. Para decidir entre MCP, API direta ou webhooks nessa integração, o artigo sobre integrar IA ao CRM cobre os caminhos.

Como esse critério entra no método

No trabalho com empresas, tratamos a escolha de transporte como parte de quatro passos. Mapear: quais sistemas o servidor toca, quem vai usar e que dados passam por ele. Limitar: começar com leitura, restringir ferramentas e definir onde ficam os segredos. Pilotar: rodar um fluxo real com logs e uma métrica de sucesso acordada. Transferir: entregar a operação com documentação, dono definido e decisão explícita de expandir, ajustar ou parar. Se o servidor for criado sob medida para um sistema interno, vale começar pelo roteiro de como criar servidor MCP para o sistema interno, com leitura primeiro. E, para quem configura o lado do cliente, configurar MCP no Claude Code explica os escopos local, de projeto e de usuário.

Perguntas frequentes

Stdio é inseguro para uso em empresa? Não necessariamente. Ele é adequado para uso individual com servidor auditado, versão fixa e credenciais de baixo privilégio. O risco cresce quando muitas máquinas guardam credenciais próprias ou quando o servidor acessa sistemas sensíveis sem registro central.

Posso começar em stdio e migrar para HTTP depois? Sim, e é um caminho comum. Para facilitar, mantenha a lógica das ferramentas separada do transporte, evite depender de arquivos locais e documente quais permissões o servidor realmente precisa. Assim a migração troca a forma de conexão sem reescrever as ferramentas.

O HTTP remoto resolve o problema de injeção de prompt? Não. O transporte protege a comunicação e permite autenticação e logs, mas o conteúdo devolvido por uma ferramenta ainda pode conter instruções maliciosas. A defesa vem de limitar ações, separar leitura de escrita, validar saídas e exigir aprovação humana quando o efeito for relevante.

Quem deve ser o dono de um servidor MCP remoto? Uma pessoa ou equipe com responsabilidade clara por atualizações, alertas, acessos e desligamento em caso de incidente. Pode ser a área de tecnologia da empresa ou um parceiro com operação contratada. Sem dono definido, o servidor deve continuar em piloto e não ir para uso amplo.

Fontes

• Model Context Protocol: introdução
• OWASP: guia de autorização
• OpenTelemetry: conceitos de observabilidade
• OWASP Top 10 para aplicações com LLM