Prevenindo o inchaço de contexto e loops de agentes em servidores MCP de banco de dados

Eu tenho trabalhado com Cursor e Claude Code com MCP há algum tempo, e uma coisa se tornou óbvia rapidamente:

Dar a um agente uma ferramenta genérica execute_sql geralmente é uma péssima ideia.

O primeiro problema é a explosão de contexto. Se um agente precisa entender um banco de dados, ele frequentemente começa puxando enormes dumps de esquema, definições de tabelas ou resultados de consultas diretamente para a conversa. O contexto é consumido incrivelmente rápido.

O segundo problema é o que eu chamo de armadilha do loop do agente. O modelo escreve uma consulta, recebe um erro, reescreve, recebe outro erro e continua indefinidamente. Se você está usando modelos pagos, isso pode se tornar surpreendentemente caro.

Para explorar uma abordagem diferente, passei as últimas semanas construindo DBeast, um servidor MCP de código aberto para PostgreSQL focado em descoberta, diagnósticos e segurança, em vez de execução irrestrita de SQL.

Em vez de expor uma única ferramenta poderosa de banco de dados, o DBeast expõe 21 ferramentas especializadas.

Algumas decisões de design que acabaram funcionando bem:

1. Mapeamento de esquema em vez de despejo de esquema

Em vez de alimentar definições DDL inteiras no contexto, o servidor lê information_schema e catálogos do sistema para gerar representações estruturais compactas.

O objetivo é ajudar o modelo a entender:

• relações de tabela
• chaves estrangeiras
• cardinalidade
• gráficos de dependência

sem inundar a janela de contexto.

Em muitos casos, uma representação gráfica compacta é dramaticamente mais útil do que milhares de linhas de SQL.

2. Segurança imposta na camada da ferramenta

Eu não queria que os agentes realizassem gravações irrestritas.

Ferramentas orientadas à leitura impõem automaticamente limites de resultados, e tentativas de mutação são interceptadas antes da execução.

Para operações potencialmente destrutivas, o servidor pode retornar uma avaliação de impacto em vez disso:

• número estimado de linhas afetadas
• informações de dependência
• potencial raio de impacto

Isso dá ao modelo informações suficientes para raciocinar sobre as consequências sem realmente fazer mudanças.

3. Quebrando loops de autocorreção

Uma coisa que notei é que os agentes frequentemente tratam erros de banco de dados como convites para continuar tentando para sempre.

Quando o PostgreSQL retorna certas classes de erros, o DBeast os envolve em respostas estruturadas que incentivam o agente a parar, reavaliar ou pedir esclarecimentos em vez de queimar tokens indefinidamente.

4. Mantendo tudo local

O servidor roda localmente usando AsyncIO e transporte padrão de MCP stdio.

Os pools de conexão permanecem isolados, e nenhum metadado do banco de dados sai da máquina, a menos que a aplicação host escolha enviá-lo ao modelo.

O projeto é licenciado sob MIT e ainda está no início.

Estou particularmente interessado em como outros estão lidando com:

• descoberta de esquema
• escopo de permissões
• gerenciamento de contexto
• prevenção de loops de agente/ferramenta descontrolados
• mutação segura de banco de dados

Para aqueles que estão construindo servidores MCP em torno de sistemas de dados, quais abordagens funcionaram bem para você?

GitHub: https://github.com/snss10/DBeast