Uma análise crítica do MCP

• MCP (Model Context Protocol) fornece uma forma padronizada de integração para que LLMs interajam com o mundo externo
• Recentemente, padrões semelhantes como ACP da IBM e A2A do Google surgiram, e implementações do MCP e ferramentas relacionadas estão aumentando rapidamente
• No entanto, práticas de engenharia ainda imaturas, como confusão no design, documentação insuficiente e falta de uma especificação real do protocolo, são apontadas como problemas
• Os meios de transporte atualmente propostos, como HTTP+SSE e Streamable HTTP, aumentam a complexidade e os problemas de segurança, e o uso de WebSocket é recomendado como alternativa
• Os protocolos mais recentes estão adicionando inconsistência e complexidade excessiva em autorização e gerenciamento de sessão

---

Revisão do MCP e das tendências recentes

• O MCP é um protocolo aberto criado para padronizar como aplicações fornecem contexto a modelos de linguagem de grande porte (LLMs)
• No último mês, o MCP emergiu como um padrão central para transformar LLMs em agentes, e seu uso e implementação vêm se espalhando rapidamente
• Assim como o ACP da IBM e o A2A do Google, padrões mais ortodoxos com objetivos semelhantes estão surgindo em ritmo acelerado

Problemas de práticas de engenharia e da especificação do protocolo

• O baixo nível de implementação real e de documentação aparece em vários pontos
• Grandes empresas de tecnologia investem pesado no treinamento de modelos, mas SDKs e documentação continuam fracos, causando confusão aos usuários
• O MCP também mostra problemas semelhantes, com partes do design pouco razoáveis e falta de especificações, exemplos e diretrizes

Discussão sobre o protocolo de transporte

Método de transporte via stdio

• Stdio é a forma tradicional de conectar diretamente, em ambiente local, servidor e cliente MCP por meio de pipes (stdout, stdin)
• Há menos tratamento complexo de sockets e menos problemas específicos de sistema operacional, permitindo uma configuração de ambiente simples com variáveis de ambiente e streams de entrada e saída

Métodos HTTP+SSE / Streamable HTTP

• Com a intenção de também atender ao mundo web, foram adotados os métodos HTTP+SSE e Streamable HTTP
• Porém, embora tentem substituir o WebSocket, esses métodos acabam gerando ainda mais ambiguidade, confusão de design e complexidade
• Como uma mesma sessão e conexão pode ser criada e encerrada de várias formas, isso se torna um grande peso para o gerenciamento de estado e para a segurança no servidor

Dificuldades em casos reais de implementação de servidor/cliente MCP

• A falta de suporte em várias linguagens, como a ausência de um SDK oficial em Go, se destaca
• Como a documentação e a especificação não são claras, muitas vezes é preciso implementar por meio de engenharia reversa
• Mesmo que os servidores de exemplo sejam em sua maioria baseados em Python e JavaScript, questões de dependência e portabilidade dificultam o uso em ambientes profissionais
• Na implementação do servidor, SSE/Streamable HTTP tenta se passar por socket, mas na prática é difícil manter de forma consistente o estado da sessão e da conexão, além de exigir infraestrutura separada, como filas de mensagens

Estrutura e problemas de HTTP+SSE e Streamable HTTP

Modo HTTP+SSE

• O cliente abre uma sessão SSE com o servidor e, ao fazer uma requisição de escrita para um endpoint separado, o servidor retorna uma resposta 202 e envia a resposta pela conexão SSE já existente
• Isso exige conexão de sessão e manutenção da sincronização de estado, mas o processo é mal documentado e tem complexidade operacional muito alta

Modo Streamable HTTP

• Criação de sessão, abertura de SSE e entrega de resposta se misturam de várias formas, fazendo com que um único fluxo de requisição-resposta perca consistência
• A mistura de múltiplos estados, vários endpoints e diferentes formas de cabeçalhos cria obstáculos graves para a implementação prática e a escalabilidade

Implicações gerais

• Com o aumento da complexidade técnica, cresce também a carga cognitiva e de manutenção dos desenvolvedores, e surgem problemas de incompatibilidade e comportamento imprevisível entre diferentes implementações de servidor e cliente
• O servidor precisa rastrear todos os estados e situações de conexão, e em ambientes distribuídos a escalabilidade eficiente e a sincronização de estado ficam ainda mais difíceis

Implicações de segurança

• Formas microscópicas e variadas de conexão/sessão aumentam vulnerabilidades de segurança ligadas ao gerenciamento de estado, como sequestro de sessão, ataques de repetição e negação de serviço (DoS)
• Múltiplos pontos de entrada e formas de resposta ampliam a superfície de ataque e podem permitir a ocultação de atividade maliciosa por meio de fluxos não intencionais

Confusão no protocolo de autorização

• A especificação atual aplica regras inconsistentes, como exigir OAuth2 apenas para transporte HTTP, enquanto no transporte STDIO permite o uso arbitrário de variáveis de ambiente
• Há confusão e incoerência, como por que apenas o transporte HTTP é forçado a implementar OAuth2 complexo

Sugestões de melhoria

• É necessário simplificar para um único protocolo JSON RPC, com os meios de transporte centrados, na prática, apenas em Stdio e WebSocket
• Uma abordagem desejável é mapear as variáveis do ambiente Stdio para cabeçalhos no ambiente HTTP e mapear entrada e saída para os streams bidirecionais do WebSocket
• Isso permite eliminar rastreamento de sessão desnecessário, gerenciamento de estado e inúmeras exceções
• O WebSocket deveria se tornar a escolha padrão para todos os transportes baseados em HTTP, além de resolver os problemas complexos de sincronização de estado

Comparação com protocolos alternativos e tendências de mercado

• O ACP da IBM e o A2A do Google oferecem um design de transporte mais simples e recursos de descoberta de agentes no aspecto de interoperabilidade entre agentes
• Mas, em essência, na maioria dos casos eles podem ser integrados como ferramentas separadas dentro de um ambiente construído sobre MCP
• Como o surgimento contínuo de novos protocolos pode levar ao risco de proliferação de padrões, priorizar a simplicidade do transporte é importante para o crescimento da indústria

[GN⁺]

Comentários do Hacker News

• Tenho certeza de que a razão de a documentação escrita por fornecedores de LLM ser tão confusa é justamente porque eles estão usando LLM para escrevê-la; isso é uma abordagem muito ruim, e usar LLM em trabalho de especificação é muito pior do que usá-lo para redigir boa documentação; o próprio processo de escrever uma especificação é a parte central, e é importante que designers humanos encontrem com cuidado falhas, lacunas e tratem casos específicos, mas na especificação do MCP vejo pouca evidência desse tipo de reflexão humana; aquele estilo insosso característico, a dispersão e a estrutura centrada em listas são exatamente o tipo de resultado que um LLM produz
  • A documentação da DeepSeek, por outro lado, tem o problema de conter muitos erros de ortografia e gramática; é realmente estranho que uma empresa que trabalha com linguagem o dia inteiro e que chegou a ter um dos melhores LLMs em inglês do mundo não consiga produzir documentação com aparência profissional
  • Eu também sinto fortemente que essa especificação foi escrita por um LLM; todas as evidências apontam para isso; suspeito que a maioria dos produtos já é feita para apresentar aos investidores, em um IPO, uma média do resultado mais plausível
  • Se isso for verdade, é realmente lamentável; a Anthropic tem muita gente inteligente, então é triste ver isso acontecer em um componente central de um ecossistema importante
  • Só agora me ocorreu que fornecedores de IA para programação talvez tenham um incentivo para tornar a documentação deliberadamente incompreensível: criar código que humanos não entendem e que só a IA deles consegue interpretar, tornando o usuário totalmente dependente do serviço específico deles; se em dois anos eles não conseguirem substituir programadores de verdade por completo, essa estratégia vai acabar eliminando todos os consumidores e destruindo o próprio mercado deles; no fim, só vai restar uma enorme pilha de código impossível de converter entre humanos e IA
  • Quando leio prosa escrita por LLM, não parece ser só um problema meu perder a concentração; sinto que esse texto repetitivo e sem contexto produzido por máquina não contém pensamento profundo e passa a causar até fadiga emocional; quando um LLM como esse chega ao ponto de escrever especificações técnicas, conteúdo que nem o próprio autor entende acaba se misturando ali de forma inconsciente; isso me preocupa cada vez mais
  • A documentação da DeepSeek, no geral, não pareceu ruim; parece feita rapidamente, mas em um nível aceitável; isso pode significar que existem exceções à ideia de que toda documentação escrita por LLM é ruim
• Hoje em dia o campo de LLM está imitando paradigmas de software em velocidade de trapaça; já existem muitos exemplos antigos de como expor funções remotas, como DLL, gRPC, SOAP, IDL e dCOM, mas o pessoal atual de LLM parece nem saber que isso existe; espero que amadureça com o tempo, mas no fim ainda resta fazer o dever de casa
  • Daqui a mais alguns meses isso certamente vai amadurecer, mas ao olhar para o ecossistema inicial de Python lembro de como erros acabam se fixando nas camadas de base e todo mundo passa a empilhar novas ferramentas em cima deles; desta vez é ainda mais triste porque o ecossistema de IA está indo pelo mesmo caminho apesar de já existir o histórico desses mesmos erros do passado
  • Quando vi o MCP pela primeira vez, pensei em COM/DCOM e lembrei do antigo DLL Hell; vou observar como o MCP evolui daqui para frente
  • Ainda não encontrei uma explicação que me faça entender exatamente o que é o MCP, e fico curioso sobre como isso seria chamado em linguagens de desenvolvimento do passado
  • Quero apontar que, em um protocolo tão rígido e declarativo como esse, perde-se o espaço de significado potencial e as forças semânticas do LLM; talvez fosse mais intuitivo simplesmente colocar um arquivo agents.json na raiz web e deixar que agentes resolvessem tudo sozinhos por meio de uma conversa semântica; no fim, o HTTP vira a entrada e saída padrão dos agentes
  • Acho que todos os exemplos apresentados são apropriados
  • Fico curioso se o MPC é baseado em JSON-RPC
• Concordo com o conteúdo geral do texto, especialmente com a experiência frustrante de não conseguir encontrar informação substancial no site do MCP; RFCs são difíceis de ler, mas ainda são muito melhores do que “use apenas o SDK”
  • Gostaria que mais gente percebesse a importância deste blog; talvez devêssemos pausar um pouco a adoção do MCP e rever se existe uma base técnica realmente sólida; há muito entusiasmo, mas quando se entra mais fundo na implementação a decepção aparece; várias decisões centrais, como WebSockets, são questionáveis, e embora não tudo, muita coisa parece ter sido feita às pressas como um tipo de gambiarra
  • É uma pena não haver uma especificação clara no site; parece que metade da especificação foi gerada com Sonnet, e não há uma descrição nítida de como o protocolo realmente funciona; em comparação, a especificação do GraphQL é muito melhor escrita
• No momento, a maior parte do trabalho na área de IA está sendo tocada principalmente por matemáticos, cientistas de dados, estudantes e entusiastas amadores, e muita coisa ainda não amadureceu o suficiente para passar de um projeto de fim de semana sob os padrões de um engenheiro de software profissional
  • Eu acho que engenheiros de software profissionais de fato estão fazendo grande parte do trabalho
• O MCP deveria ter ido desde o início para HTTP stateless; na maioria dos servidores não há necessidade de manter estado, e bastaria armazenar estado de forma global ou usar apenas um identificador de sessão
  • Não consigo entender a estrutura da interação real do MCP; quero saber por que ele não é stateless e por que a conexão precisa ficar aberta o tempo todo
  • Minha experiência pessoal é limitada, mas, se você fecha a conexão após uma requisição, precisa reconectá-la para a seguinte; manter a sessão aberta ou fechá-la depende de várias variáveis, como padrão de uso, consumo de memória etc.
• Estou criando um serviço MCP baseado em Ruby on Rails chamado ninja.ai; é uma app store para instalar servidores MCP com um clique; ele instala servidores Model Context Protocol no dispositivo do cliente usando Tauri, e também oferece servidores MCP em nuvem com Rails; sou crítico de HTTP+SSE e de Streamable HTTP; para comunicação bidirecional em tempo real, WebSockets é melhor, e como o suporte a SSE no Rails é limitado, acabei migrando o endpoint para o servidor web Falcon; tenho curiosidade sobre o motivo de engenheiros da Shopify terem escolhido Streamable HTTP, talvez por restrições de infraestrutura ou deploy; também vale notar que a camada de transporte do MCP é abstraída, então implementações futuras continuam bem abertas a adotar WebSockets ou WebRTC
• Sou o operador de um dos registros MCP (glama.ai/mcp/servers); concordo em parte com o autor, mas o protocolo ainda está em um estágio muito inicial e pode mudar bastante no futuro; ele recebeu muito mais atenção do que o esperado, e em um estágio extremamente inicial passou de algumas dezenas de servidores para milhares, embora só uma parte deles realmente funcione, então gasto muito tempo filtrando isso; é um fenômeno causado pelo fato de o MCP ter recebido atenção pública antes de amadurecer; ainda assim, recentemente o ecossistema — frameworks de código, registros, clientes com suporte a MCP etc. — cresceu de forma surpreendentemente rápida; ver essa mudança em apenas meio ano é algo sem precedentes; se continuar nesse ritmo, acho a perspectiva promissora, e também forneço uma coletânea de materiais úteis para quem está começando
  • Se você comete erros no começo do design de um protocolo, terá de carregá-los para sempre, então a especificação precisa ser construída com humildade; algo como uma estrutura à la Rube Goldberg com SSE pode acabar ficando permanentemente se não for corrigido; em nível enterprise, qualquer mudança que quebre o protocolo não é fácil, então é possível ficar preso por muito tempo às decisões iniciais sem conseguir alterá-las
  • Quanto ao protocolo MCP em si, considero natural que continue evoluindo com o tempo; esperar perfeição desde o início é que seria estranho; acima de tudo, a padronização de APIs agênticas é uma mudança realmente poderosa; quando você escreve e publica código e a IA passa a reconhecê-lo e usá-lo automaticamente, é algo que precisa ser vivenciado para se sentir de verdade
  • Minha preocupação é se, nessa velocidade, o mcp não vai adotar cedo demais um design de camada de transporte que precisaria durar muito tempo; isso me lembra casos como a divisão de padrões nas guerras dos navegadores dos anos 90, que demoraram demais para se resolver, como o IE11 permanecendo por tanto tempo
• A controvérsia sobre autenticação já está sendo atualizada; em cooperação com a Anthropic e com a comunidade de segurança, foi implementada no MCP a separação entre os papéis de servidor de recursos (RS) e servidor de autorização (AS); até que a nova versão do protocolo seja formalizada, uma especificação preliminar foi publicada temporariamente
  • Fico curioso sobre qual proporção da especificação do MCP é saída de LLM; queria saber se o autor apenas percebeu isso por instinto, por causa dos sinais de alerta recorrentes
  • Tenho uma posição relativamente neutra, mas parece que apenas copiaram por cima um rascunho de OAuth, e me incomoda uma estrutura em que, ao usar HTTP, não há opção além de seguir isso obrigatoriamente; na verdade, daria para organizar isso de forma mais clara para que cliente e servidor pudessem opcionalmente suportar OAuth2
• Já abri uma issue sobre o lançamento do Streamable HTTP no MCP perguntando se não seria possível transformar tudo apenas em requisições HTTP; a especificação do MCP é promissora como solução genérica para conectar LLMs e ferramentas, mas na prática enfrenta várias dificuldades, como autenticação, streaming, comandos customizados por ferramenta e verificação da confiabilidade das ferramentas; pessoalmente, acho mais simples integrar só com APIs REST; OpenAI e Gemini também disseram que adotariam MCP, mas imagino que em breve a especificação vá esbarrar em divergências em UI, camada de interação e outras áreas que ela não deseja, gerando problemas como incompatibilidade com a marca ou até sequestro de autenticação
  • Mesmo que a Anthropic tenha criado o MCP, sua escala é visivelmente menor que a do ChatGPT; fico em dúvida se grandes empresas como OpenAI e Google realmente aceitariam por muito tempo uma especificação externa definindo os limites da experiência do usuário; há precedentes como os antigos plugins do ChatGPT, que fracassaram menos por engenharia ruim e mais por limitações da experiência do consumidor; ainda assim, estou disposto a apostar na força de uma comunidade forte
  • Depois de publicar o blog, cheguei a registrar eu mesmo issues parecidas; sinto que isso é importante demais para errar, porque depois fica difícil voltar atrás
• Acho curioso o MCP estar tão em alta, mas de qualquer forma é a tendência; eu gostaria de ouvir uma explicação de em que sentido o MCP seria melhor do que a especificação OpenAPI
  • Na minha opinião, a maior parte da popularidade do MCP vem do fato de que a usabilidade recente das ferramentas de LLM realmente melhorou; os plugins da OpenAI em 2023 fracassaram porque os LLMs da época ainda não eram confiáveis o bastante no uso de ferramentas, e o timing do MCP foi muito melhor
  • Outro fator importante é que começar um servidor MCP é muito fácil, e a barreira de entrada é baixa; conforme as ferramentas aumentam, também aumenta o texto enviado ao LLM, mas, ao fornecer OpenAPI com detalhes de rotas individuais e mensagens descritivas, até o Claude consegue integrar muito bem
  • Um dos motivos pelos quais o MCP é importante é que o OpenAPI é documentação estática, então o LLM precisa assumir toda a responsabilidade de gerar as requisições, enquanto um servidor MCP reduz esse peso por meio de abstrações; no fim, isso o torna mais fácil, rápido e seguro do ponto de vista do LLM
  • Não acho que o MCP seja perfeito, mas ele tem alguns pontos em que se ajusta melhor a LLMs do que o OpenAPI; primeiro, ferramentas MCP podem ser especificadas de forma muito mais curta e simples, enquanto uma especificação OpenAPI costuma ser grande demais e ocupa contexto demais do LLM; como o LLM não cria de fato a chamada, e sim apenas gera texto de saída, a abordagem do MCP é mais natural; além disso, o MCP é muito mais flexível para estruturas dinâmicas, como adição ou alteração de ferramentas, superando as limitações estáticas do OpenAPI; claro, há problemas evidentes, especialmente na camada de transporte, que ainda tem espaço para melhorar, mas as bibliotecas principais também estão bem implementadas