Uma análise crítica do MCP

• O MCP é um protocolo baseado em JSON-RPC que busca permitir que LLMs/Agents lidem com ferramentas externas e fontes de dados de forma padronizada, mas é criticado por aumentar o custo de implementação por causa do desenho de transporte em HTTP e da qualidade da documentação
• O ponto mais controverso é que, ao implementar comunicação bidirecional simples sobre HTTP, ele reconstrói indiretamente um comportamento próximo ao de WebSocket com HTTP+SSE e Streamable HTTP
• O Streamable HTTP divide a criação de sessão, a conexão SSE e os caminhos de entrega de resposta em várias ramificações, aumentando a carga de gerenciamento de estado, depuração, interoperabilidade, escalabilidade e segurança
• Ao transporte HTTP se somam exigências de autorização centradas em OAuth2, enquanto o stdio é definido para obter credenciais de variáveis de ambiente, fazendo com que o modelo de autenticação varie conforme o tipo de transporte
• O transporte HTTP deveria ser simplificado com WebSocket, que é o mais próximo dos fluxos de entrada e saída do stdio, e o design deveria ser otimizado para os casos de uso mais comuns, não para exceções

---

O cenário de rápida adoção do MCP

• O MCP(Model Context Protocol) é um protocolo aberto que padroniza a forma como aplicações fornecem contexto para LLMs
• A Anthropic compara o MCP a uma porta USB-C para aplicações de IA, descrevendo-o como uma forma padronizada de conectar modelos de IA a diversas fontes de dados e ferramentas
• No último mês, o MCP se espalhou rapidamente, e novos MCP Server e Client estão sendo criados diariamente, podendo ser vistos em sites como mcp.so e pulsemcp.com
• A IBM publicou o Agent Communication Protocol(ACP) como um “padrão ortogonal” ao MCP, e o Google também anunciou o Agent2Agent(A2A)
• A crítica central continua sendo que, embora grandes empresas gastem enormes quantias em treinamento e ajuste de modelos, a maturidade de documentação, SDKs e guias de implementação ainda é baixa

O próprio protocolo e a camada de transporte

• O MCP é um protocolo JSON-RPC com métodos e endpoints predefinidos para uso com LLMs
• Os principais modos de transporte se dividem entre stdio, mais próximo da execução local, e transporte baseado em HTTP

  • stdio

    • Inicia um MCP Server local, conecta os pipes de stdout e stdin ao Client para trocar JSON e usa stderr para logging
    • O uso do paradigma de pipes do Unix/Linux para comunicação bidirecional pode ser criticado, mas funciona facilmente em todos os sistemas operacionais e é simples de entender por não exigir tratamento de sockets

  • Transporte baseado em HTTP

    • Opera sobre HTTP e inclui HTTP+SSE e o Streamable HTTP, que busca substituí-lo
    • Ambos tentam implementar uma troca simples de mensagens bidirecionais por meio da combinação de requisições HTTP e conexões SSE, aumentando a complexidade

Críticas ao HTTP+SSE e ao Streamable HTTP

• O transporte HTTP existente usa HTTP+SSE(Server-Sent Events), e a nova especificação busca substituí-lo por Streamable HTTP
• No HTTP+SSE, para criar full duplex, o Client abre uma sessão SSE de leitura com uma requisição como GET /sse, recebe na primeira resposta uma URL de escrita e então envia uma requisição como POST /a-endpoint?session-id=1234
  • O servidor retorna 202 Accepted com corpo vazio
  • A resposta real deve ser lida na conexão /sse já aberta
• O Streamable HTTP trata o ID de sessão em um header HTTP em vez de um endpoint separado, e pode abrir uma sessão SSE com GET ou POST /mcp
  • A resposta pode vir em um novo stream SSE
  • Pode vir com 200 no corpo da resposta do POST
  • Pode ser entregue depois em um dos streams SSE já existentes
• Esse desenho é mais próximo de uma estrutura que tenta operar como WebSocket sobre SSE, e a lógica para evitar o uso de WebSocket de fato é discutida em modelcontextprotocol/pull/206
• O transporte HTTP tenta imitar o stdio, mas como não é um socket de verdade, a implementação do servidor acaba assumindo o ônus de combinar (join) várias chamadas e conexões HTTP

Problemas de documentação e SDK expostos na experiência de implementação

• Em uma tentativa de implementar um MCP Server em Go, não havia SDK oficial em Go, e entender o protocolo exigiu na prática engenharia reversa
• A documentação em modelcontextprotocol.io omite ou deixa passar detalhes importantes do protocolo e não oferece exemplos de fluxo de conversa
• O site tem um perfil mais voltado a direcionar o leitor para tutoriais de implementação com SDK do que para a leitura do padrão em si
• Os servidores de exemplo são implementados em Python ou JavaScript e partem do pressuposto de execução local via stdio
  • Python e JavaScript são criticados como escolhas ruins para ferramentas locais que precisam funcionar de forma confiável no computador de outras pessoas
  • O fato de os exemplos também serem oferecidos como contêineres Docker parece refletir certo reconhecimento desse problema
• Para execução local de MCP, considera-se que linguagens mais portáveis ou opções baseadas em VM, como Rust, Go, Java e C#, sejam mais adequadas

A complexidade criada pelo Streamable HTTP

• No Streamable HTTP, uma nova sessão pode ser criada de três formas
  • Requisição GET vazia
  • Requisição POST vazia
  • Requisição POST contendo uma chamada RPC
• O SSE também pode ser aberto por quatro caminhos
  • GET para inicialização
  • GET para entrar em uma sessão anterior
  • POST para inicialização de sessão
  • POST contendo uma requisição e recebendo a resposta por SSE
• As respostas das requisições, por sua vez, podem ser entregues de três maneiras
  • Na resposta HTTP da requisição POST com a chamada RPC
  • Em um evento SSE aberto como resposta àquele POST
  • Em qualquer evento SSE previamente aberto
• Com tantos caminhos para chegar ao mesmo resultado, aumentam a carga cognitiva, a dificuldade de depuração e o peso da manutenção
• Se Client e Server implementarem apenas partes que cada lado considerar necessárias, podem surgir problemas de interoperabilidade e comportamentos inesperados
• Em arquiteturas de servidor distribuídas por várias máquinas, o gerenciamento do estado das conexões e do mecanismo de resposta pode se tornar um gargalo de escalabilidade

Problemas de segurança e autorização

• A flexibilidade do Streamable HTTP levanta várias preocupações de segurança
  • O gerenciamento de estado de sessão entre HTTP e SSE é complexo e pode abrir espaço para sequestro de sessão, ataques de replay e DoS
  • O aumento de pontos de entrada para criação de sessão e conexão SSE amplia a superfície de ataque
  • A variedade de formas de iniciar sessão e entregar respostas pode ser usada para esconder atividade maliciosa
• A especificação mais recente de authorization recomenda que implementações de transporte baseado em HTTP sigam essa especificação
• A mesma especificação recomenda que implementações com transporte STDIO não a sigam, e obtenham credenciais do ambiente
• Nessa estrutura, surge a reclamação de que, ao usar transporte HTTP, é preciso implementar o fluxo OAuth2, enquanto no stdio parece possível operar com um nível de acesso equivalente a API key

Proposta: simplificar o transporte HTTP com WebSocket

• O MCP tem um único protocolo JSON-RPC, e o stdio parece claramente o modo de transporte preferido
• O transporte HTTP deveria ser o mais parecido possível com o stdio, com diferenças apenas quando realmente necessárias
• As variáveis de ambiente do stdio podem corresponder a headers HTTP no HTTP
• Os fluxos de entrada e saída do stdio, semelhantes a sockets, podem corresponder a WebSocket no HTTP
• O uso de WebSocket pode reduzir o complexo gerenciamento de estado entre servidores para sessões e muitos corner cases
• Ainda assim, a autorização pode se tornar mais complexa em alguns casos, alguns firewalls podem bloquear WebSocket, sessões curtas podem trazer overhead e retomar sessões interrompidas pode ser mais difícil
• A própria especificação do MCP também afirma que ele é um protocolo agnóstico ao transporte que pode ser implementado em qualquer canal de comunicação que suporte troca bidirecional de mensagens
• O setor deveria se otimizar para os casos de uso mais comuns, não para corner cases

Avaliação adicional sobre ACP e A2A

• O MCP é um protocolo para expor APIs a LLMs, enquanto ACP e A2A estão mais próximos de protocolos para expor Agents a LLMs
• Ao olhar a especificação do A2A, sua necessidade parece limitada, e muitos de seus recursos parecem poder ser tratados pelo próprio MCP ou com pequenas extensões
• ACP e A2A também poderiam ser implementados não como protocolos separados, mas como ferramentas de um MCP Server
• A própria IBM apresenta essa visão na documentação do MCP adapter, onde trata um agente ACP como recurso MCP e como algo que pode ser chamado por ferramentas MCP
• Há a avaliação de que o ACP parece ter também um caráter de promoção da ferramenta de construção de agentes da IBM, o BeeAI
• As vantagens trazidas por ACP e A2A estariam em uma camada de transporte mais completa e em formas de descoberta de Agents