Por que o MCP sempre foi uma má ideia

Recentemente, participei de um evento de dia inteiro focado no que há de mais novo e melhor no mundo do MCP. Embora todos os apresentadores fossem incríveis e parecessem apaixonados pelo trabalho que estavam fazendo, estou honestamente cansado do MCP. É um protocolo horrível construído para uma época em que LLMs não eram tão inteligentes, e nós o superamos.

Breve histórico

O MCP foi lançado em novembro de 2024 pela equipe da Anthropic como um protocolo projetado para ajudar agentes a se conectarem a serviços e fontes de dados externos. Os modelos da época ainda eram relativamente primitivos, pelo menos comparados ao que temos agora. Nem tínhamos o Claude Code naquela época, e fluxos de trabalho agenticos de propósito geral eram muito menos confiáveis. Os usuários começaram a ver a utilidade de dar aos seus modelos de IA acesso a serviços externos. Isso permitiu um nível de produtividade que não tínhamos visto antes. Vimos uma explosão na adoção do MCP, coincidindo com um crescimento semelhante, senão mais explosivo, na adoção de LLMs em toda a economia. Com o tempo, o MCP continuou a evoluir sob a gestão da Anthropic antes de ser eventualmente doado para a Agentic AI Foundation, sob a Linux Foundation, em 2025.

O complexo industrial do MCP

Com o enorme crescimento na adoção, os usuários começaram a adicionar muitos servidores MCP às suas configurações, e começaram a enfrentar o problema de inchaço de contexto. Cada servidor viria com várias ferramentas, cada uma com seu próprio esquema, o que começou a sobrecarregar o contexto de todos esses modelos. Desenvolvedores da Harness encontraram muitos truques para contornar isso, incluindo padrões genéricos de busca/execução agora oferecidos por plataformas como Composio, Mint MCP e Pipedream. Todos eles resolvem efetivamente o problema de ter um único lugar para colocar suas credenciais para os vários serviços externos e dar ao seu agente um conjunto mínimo de ferramentas (para reduzir o inchaço de contexto) que ele pode usar para acessá-los. Quero deixar claro que isso é uma coisa boa, a curto prazo.

Com todas as coisas que construímos em torno do MCP, o que não levamos em conta, ou talvez tenhamos ignorado, é que os modelos estavam melhorando. Agora temos sistemas inteiros dedicados a monitorar servidores MCP, garantir que as respostas sejam boas, garantir que os agentes possam acessar facilmente as ferramentas, descobrir esquemas e determinar o que precisamos dar aos agentes para que eles possam fazer a chamada certa no momento certo.

Surpresa, surpresa, os grandes laboratórios estavam certos

Os modelos melhoraram. Eles agora são capazes de executar código em um computador, raciocinar sobre grandes bases de código e, em geral, agir de forma muito mais autônoma do que nunca. Uma grande parte desse trabalho era escrever/executar scripts para fins de codificação. Um efeito colateral (será que é?) é que agora eles são bons em chamar APIs diretamente. Eles podem escrever scripts, compor vários serviços diferentes e chamar APIs que nunca viram antes, tudo em fluxos de trabalho úteis com intervenção mínima do lado do usuário.

Os LLMs ficaram tão bons nisso que a Cloudflare até lançou o Code Mode, uma maneira melhor de usar o MCP fazendo com que LLMs componham as várias chamadas em scripts que podem ser executados em um sandbox. Mas ainda melhor do que isso, os LLMs descobriram como usar o comando --help para descobrir CLIs, então eles não precisam mais de servidores MCP para acessar muitos serviços disponíveis através de APIs documentadas ou CLIs. A maioria dos servidores MCP de serviços remotos, em última análise, encapsula APIs que já existem.

E agora?

Excluímos a maioria dos nossos servidores MCP. É isso. Agentes com acesso ao terminal podem substituir a maioria dos servidores MCP e muitas vezes são mais capazes.

Ainda existem alguns problemas, como CLIs retornando respostas legíveis por máquina (JSON/XML, etc.), que tendem a ser muito verbosas e pesadas no uso de tokens, mas temos maneiras de corrigir isso. Grande parte da alternativa já existe: APIs HTTP documentadas, negociação de conteúdo padrão e mecanismos de autenticação maduros. Devemos começar a padronizar como os agentes usam APIs HTTP diretamente. Por exemplo, clientes de agentes poderiam anexar cabeçalhos para se identificarem como agentes, e servidores poderiam enviar automaticamente a eles dados de resposta como Markdown ou texto em vez de HTML ou....