Futuro do MCP e Context Engineering
Eu não gosto de servidores MCP. Entendo a promessa de conveniência, como funciona a parte de “descoberta” de ferramentas e a capacidade de ser plug and play, essas características são atraentes e, sem dúvida, se aplicam perfeitamente em certos casos de uso como Claude Code, Codex etc.
Conectar o seu primeiro MCP ao assistente de código preferido parece mágica. Um comando e você tem acesso a um novo sistema de maneira conversacional. Isso funciona até a página 2. Utilizar um servidor MCP é o ato de colocar mais coisa na janela de contexto do seu agente (a maioria das inovações em agentes é simplesmente mexer na janela de contexto).
O cliente MCP pede as definições de ferramentas disponíveis no servidor e injeta essas definições no contexto do agente. Elas contêm a descrição das ferramentas e as instruções de quando e como utilizá-las. Ou seja, se você conectar um agente a um servidor que tem 10 ferramentas, 10 descrições e instruções diferentes serão incluídas na sua janela de contexto. Cinco servidores MCP com 10 ferramentas cada incluem 50 definições de ferramentas e 50 instruções diferentes.
MCPs também têm alguns problemas quando falamos de autenticação, mas isso fica para outro texto.
Tentativas de mitigar o problema da janela de contexto
Esse problema de inserir coisas demais na janela de contexto já foi identificado por diversas empresas e laboratórios de IA. Gosto bastante de um estudo feito pela Chroma em que o conceito de Context Rot é proposto. A ideia central é simples: mais tokens de entrada resultam em pior performance. Recomendo a leitura.
Laboratórios de IA e empresas que constroem agentes fizeram propostas para “economizar” janela de contexto ao modificar como ferramentas são utilizadas. A Cloudflare lançou o que chamam de MCP code mode, e a própria Anthropic, criadora do MCP, também encontrou uma maneira de contornar esse problema por meio de Code Execution with MCP.
Essas duas abordagens seguem a mesma linha de raciocínio: expor as ferramentas do MCP como APIs de código e fornecer uma ferramenta de execução de código ao agente, que consegue chamar essas APIs para operar sobre o resultado dos MCPs por meio de código, sem observar os outputs das ferramentas.
Essas abordagens são bem interessantes, mas ainda não resolvem o problema de inserir todas as definições de ferramentas no contexto do seu agente. Elas somente oferecem uma maneira mais inteligente de operar sobre o retorno das ferramentas do servidor MCP ou de qualquer outro conjunto de ferramentas do seu agente. São agnósticas ao MCP.
Progressive disclosure
Progressive disclosure, ou “descoberta progressiva”, é uma maneira de despachar ou armazenar informações relevantes para fora da janela de contexto do agente.
Existem dois componentes essenciais na descoberta progressiva:
- Mecanismo de armazenamento externo
- Ferramentas de leitura e escrita nesse mecanismo de armazenamento
O mecanismo de armazenamento mais inteligível para humanos é um sistema de arquivos. E a melhor parte: já existem muitas ferramentas de manipulação de arquivos de texto, tudo por meio de um terminal. Comandos como grep, glob e cat são comuns para manipular texto em sistemas de arquivos, e os modelos de linguagem sabem utilizá-los porque eles aparecem extensivamente nos dados de treinamento. É como se modelos de linguagem fossem muito bons em fazer tarefas que já foram resolvidas. Por que será?
Com o sistema de arquivos, é possível armazenar instruções e padrões de utilização de ferramentas como arquivos de texto e scripts de código, como scripts Python, por exemplo. Dê acesso ao terminal e a certos comandos para o seu agente, e você faz com que ele descubra como resolver um problema por meio da exploração de suas próprias capacidades, que estão descritas no sistema de arquivos em formato de texto.
A ideia de utilizar arquivos de texto como uma memória de acesso sob demanda é a base do conceito de skills em context engineering. Skills permitem separar diferentes habilidades que um agente pode ter. Uma skill é simplesmente um arquivo ou um conjunto de arquivos que contém instruções e scripts. O essencial é somente um conjunto de instruções. Existem skills que não têm scripts e mesmo assim continuam sendo um padrão válido, porque o principal objetivo do conceito de skill é a capacidade de carregar instruções específicas para uma certa tarefa sob demanda. Como se o agente se “lembrasse” ou “descobrisse” como solucionar a tarefa. Na verdade, quem solucionou a tarefa foi a pessoa que escreveu a skill.
Progressive disclosure inspirou métodos inovadores como Recursive Language Models.
Três possibilidades
Daqui para frente, eu vejo três caminhos possíveis para utilizarmos MCP sem acabar com a nossa janela de contexto:
- Não utilize MCP. Algo melhor vai ser inventado.
- A maneira de utilizar servidores MCP vai mudar drasticamente para casos de uso complexos. Casos de uso mais simples vão continuar usando da maneira tradicional, mas qualquer agente mais complexo vai aplicar diversas técnicas para não esgotar a janela de contexto.
- Todo agente vai utilizar uma ferramenta de busca de ferramentas.
Sobre o ponto 3: a Anthropic e o GitHub Copilot já fazem otimização de ferramentas selecionadas com base na tarefa. A abordagem comum e simples para isso é indexar as descrições das ferramentas e buscar as mais relevantes para cada tarefa, provavelmente por similaridade semântica e keyword search. Não construí nenhuma ferramenta de busca de ferramentas, então não posso dizer o que funciona melhor.
Deal breaker
Para mim, existe um impedimento que causa muita inércia na adoção de servidores MCP de maneira tradicional: as definições de ferramenta são escritas por outra pessoa. Quando o agente inicializa e carrega as definições de ferramenta do servidor MCP, um prompt de outra pessoa, que não leva em consideração o seu caso de uso, está entrando na sua janela de contexto. Talvez eu esteja sendo muito desconfiado, purista e superestimando o impacto das definições de ferramentas na performance do agente. Sim, provavelmente.
Mas a janela de contexto tem que ser tratada com esse esmero. No nível mais fundamental, ela é a maneira MAIS PODEROSA de controlar o comportamento do seu agente sem modificar os pesos do modelo. É importantíssimo garantir que as ferramentas sejam de alta qualidade. Tem que se pensar sobre o que retornar quando uma operação falha e como inserir instruções no retorno das ferramentas para que o ecossistema funcione bem. Por exemplo, uma ferramenta de busca na web pode conter a seguinte instrução no retorno:
...utilize a ferramenta ler_pagina_web para ler a página que foi encontrada pela busca
Isso inclui novas instruções para que o ecossistema de ferramentas entre em harmonia. É um detalhe que às vezes nem é necessário, porém importante se estamos em busca da máxima performance.
Então existe um equilíbrio ao utilizar servidores MCP: fica fácil dar novas ferramentas ao seu agente, mas, se isso for feito de maneira ingênua, você vai poluir demais o contexto.
Eu, particularmente, acho que o MCP como conhecemos vai morrer.