Ensinando um LLM a obter Recursos e Prompts MCP sob demanda (em vez de afogá-lo em contexto)

Como conectamos os primitivos "controlados pela aplicação" do Protocolo de Contexto do Modelo em um loop de chamada de ferramenta controlado pelo modelo — e por que essa pequena mudança muda tudo sobre a higiene do contexto.

TL;DR

O Protocolo de Contexto do Modelo (MCP) oferece a um servidor três maneiras de expor capacidade: ferramentas, recursos e prompts. Ferramentas entram diretamente no loop de chamada de função de um LLM. Recursos e prompts não — eles são controlados pela aplicação, então a maioria das integrações apenas joga o conteúdo de cada recurso no prompt do sistema e espera pelo melhor.

Essa abordagem incha o contexto, trunca documentos grandes, quebra arquivos binários e não dá ao modelo nenhuma voz sobre o que realmente precisa.

Nossa solução: promover recursos e prompts a ferramentas LLM sintéticas e auto-aprovadas — read_resource(uri) e invoke_prompt(name). O prompt do sistema agora carrega apenas um catálogo leve (URIs + descrições). O modelo lê um recurso somente quando decide que precisa de um, através da mesma maquinaria de chamada de ferramenta que já usa. Sob demanda, seletivo, com total fidelidade.

Os três primitivos MCP — e o modelo de controle que ninguém fala

O MCP define três capacidades de servidor, mas a parte interessante é quem está no controle de cada uma:

A chamada de ferramenta é controlada pelo modelo por design: o LLM emite um bloco tool_use, você o executa, você alimenta o resultado de volta. Bonito.

Recursos e prompts são controlados pela aplicação. O modelo mental da especificação é um humano clicando em "anexar este arquivo" ou "/usar este modelo de prompt." Não há um lugar óbvio para eles dentro do loop de raciocínio de um agente autônomo. Então, o que a maioria das integrações faz?

A abordagem ingênua (e por que dói)

O caminho de menor resistência é buscar todos os recursos na inicialização e colá-los no prompt do sistema:

## Recursos Disponíveis
### Recurso: Matriz de Teste SUM ABAP
URI: sap-btp://sum-abap-v1
Conteúdo:
<... 11.000 caracteres de markdown ...>
### Recurso: Documentos da API
URI: sap-btp://api-docs
Conteúdo:
<... mais ...>

Quatro problemas aparecem rapidamente:

1. Inchaço de contexto. Cada solicitação paga por cada recurso, independentemente de ser relevante ou não. Dez recursos × alguns milhares de tokens cada = um prompt do sistema que ofusca a conversa real.
2. Truncamento. Para manter o inchaço sob controle, você limita o conteúdo (content[:2000]) — e agora documentos grandes são silenciosamente cortados. No nosso caso, a matriz SUM ABAP perdeu toda a sua lista de produtos e seção de formato de saída abaixo da linha de 2.000 caracteres.
3. Quebras binárias. Um recurso PDF ou PNG não tem forma de texto significativa. Extratores ingênuos tentam blob.as_string(), encontram um UnicodeDecodeError, e silenciosamente emitem "[Nenhum conteúdo disponível]".
4. Sem agência. O modelo não pode dizer "não preciso de nenhum desses agora" ou "me dê aquele, na íntegra." Ele é alimentado à força.

A percepção: faça recursos e prompts parecerem ferramentas

Aqui está a mudança. O LLM já tem uma maneira limpa e bem compreendida de pedir algo sob demanda: ele chama uma ferramenta. Então, em vez de lutar contra o modelo de controle, nós traduzimos isso.

Registramos duas ferramentas internas DARA que não existem em nenhum servidor MCP — elas são sintetizadas do lado do cliente:

• read_resource(uri) → busca o conteúdo de um recurso quando o modelo pede.
• invoke_prompt(name) → injeta um modelo de prompt nomeado na conversa quando o modelo pede.

O prompt do sistema agora anuncia apenas um catálogo — nomes, URIs e descrições, sem conteúdo:

## Recursos Disponíveis
Os seguintes recursos podem ser lidos sob demanda. Para ler um, chame a
ferramenta `read_resource` com seu URI exato. Não assuma o conteúdo de um recurso até que você o tenha lido.

### Recurso: Matriz de Teste SUM ABAP
URI: sap-btp://sum-abap-v1
Descrição: Especificação da matriz de teste do SUM (Gerenciador de Atualização de Software) para produtos ABAP

O modelo vê o que existe, então busca exatamente o que precisa — através do loop de ferramenta que já fala fluentemente.

Passo a passo da implementação

Construímos isso em cima do LangGraph + langchain-mcp-adapters, mas o padrão é independente de framework.

1. Sintetizar a ferramenta com um esquema

read_resource é uma StructuredTool com um esquema de um campo. Sua func é uma lambda sem operação — nunca a executamos como uma função; a interceptamos no gráfico (veja o passo 3).

from pydantic import BaseModel, Field
from langchain_core.tools import StructuredTool

class _ReadResourceArgs(BaseModel):
    uri: str = Field(description="O URI exato do recurso MCP a ser lido, "
                                 "por exemplo, 'sap-btp://sum-abap-v1'.")

read_resource_tool = StructuredTool.from_function(
    func=lambda uri: "",                      # placeholder — handled in the graph
    name="read_resource",
    description=(
        "Leia o conteúdo completo de um recurso MCP pelo seu URI. "
        "Chame isso quando o usuário pedir para ler, abrir