Seu servidor MCP PostgreSQL é tão atual quanto seu contexto de esquema

Um servidor PostgreSQL MCP pode funcionar perfeitamente na sexta-feira e se tornar confiantemente errado após a migração de segunda-feira.

O banco de dados está disponível.

A ferramenta se conecta.

O SQL pode até ser executado.

Mas uma migração ainda pode mudar:

• o granulado de uma view
• um enum de status
• o significado de negócio de um timestamp
• a cardinalidade de um join
• permissões expostas
• a fonte métrica autoritativa

A prontidão para mudanças no esquema, portanto, precisa de mais do que redescoberta.

Teste objetos renomeados e removidos, mudanças executáveis, mas semânticas, derivações de permissões, caches obsoletos, múltiplas réplicas MCP, planos de consulta representativos, conversas em andamento e estados de rollout interrompidos.

Vincule cada teste a:

• versão da migração do banco de dados
• versões de objetos e políticas expostas
• definição semântica
• esquema da ferramenta MCP
• build do servidor
• timestamp de descoberta

Se a frescura do contexto não puder ser provada, as ferramentas afetadas devem falhar com um resultado de esquema obsoleto estruturado em vez de adivinhar.

E use expandir e contrair para contratos de ferramentas também: adicione a nova versão, execute a antiga e a nova contra fixtures determinísticas, migre clientes deliberadamente, observe a janela de compatibilidade, e então remova o contrato antigo.

“A nova view existe” não é um portão de produção.

“O novo significado é testado, versionado, autorizado, observável e recuperável” é.

Guia completo de testes: Servidor MCP para Postgres: teste a prontidão para mudanças no esquema antes da produção