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 tools e a capacidade de ser plug and play, essas características do servidor MCP são atraentes e, sem dúvida, se aplicam perfeitamente em certos casos de uso como claude code, codex e etc.

Conectar o seu primeiro MCP no seu 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 do 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 MCP e injeta as definições no contexto do agente, essas definições contém a descrição das ferramentas e as instruções de quando e como utilizar as ferramentas, 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. 5 servidores MCP com 10 ferramentas cada, inclui 50 definições de ferramentas e 50 instruções diferentes.

MCPs também tem alguns problemas quando falamos de autenticação, mas isso fica pra 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, eu gosto bastante de um estudo feito pela Chroma onde o conceito de Context Rot é proposto, a ideia central é simples: Mais tokens de entrada resulta em pior performance, recomendo a leitura.

Laboratórios de IA e companhias construindo 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 achou 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 de código para que o agente consiga operar sobre o resultado dos MCPs por meio de código, sem observar os outputs das ferramentas.

Essa 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 suas ferramentas do servidor MCP ou qualquer outro conjunto de ferramentas do seu agente, elas 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 para resolver o problema

Existem dois componentes essenciais na descoberta progressiva:

• Mecanismo de armazenamento externo
• Ferramentas de leitura e escrita no 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 sistemas de arquivos de texto, tudo isso por meio de um terminal. Comandos como grep, glob, cat são comandos comuns para manipular texto em sistemas de arquivos e os modelos de linguagem sabem como utilizar esses comandos porque esses eles aparecem extensivamente nos dados de treinamento. É como se modelos de linguagem fossem mto 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 disponíveis como arquivos de texto e scripts de código, como scripts Python por exemplo. Dê acesso ao terminal e a certos comandos pro seu agente e você faz com que ele descubra como resolver um problema por meio de exploração de suas próprias capacidades, que estão descritas no sistema de arquivos em formato de texto.

A ideia de conseguir 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 tem scripts e mesmo assim continuam sendo um padrão válido porque o principal o objetivo do conceito de skill é 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

3 Possibilidades

Daqui pra frente, eu vejo 3 caminhos possíveis para utilizarmos MCP sem acabar com a nossa janela de contexto.

1. Não utilize MCP, algo melhor vai ser inventado.
2. A maneira de utilizar servidores MCP vai mudar drastricamente 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 pra não esgotar a janela de contexto
3. Todo agente vai utilizar uma ferramenta de busca de ferramentas.

Sobre o ponto 3; A Anthropic e GitHub Copilot já fazem otimização de ferramentas selecionadas baseado na tarefa, a abordagem comum e simples para isso é indexar as descrições das ferramentas e fazer a busca das ferramentas mais relevantes para certa tarefa, provavelmente por similaridade semântica e keyword search. Não construi nenhuma ferramenta de busca de ferramentas então não posso dizer o que funciona melhor.

deal breaker

Pra mim, existe um impedimento que causa muita inércia para utilizar servidores MCPs 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 super estimando o impacto das definições de ferramentas na performance do agente? Sim.

Mas a janela de contexto tem que ser tratada com esse esmero. No mais baixo nível, ela é a ÚNICA maneira de controlar o comportamento do seu agente sem modificar os pesos do modelo. É importantíssimo garantir que as ferramentas são 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 de ferramentas funcione bem. Por exemplo, uma ferramenta de busca na web pode conter a seguinte instrução no retorno da ferramenta:

...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 as vezes nem é necessário porém importante se estamos em busca da máxima performance.

Então existe um balanço ao utilizar servidores MCP, fica fácil de dar novas ferramentas ao seu agente mas se isso for feito de