Servidores MCP Falham em Silêncio. Seu Dashboard Não Vai Te Contar.

Seu servidor MCP retorna 200 OK em cada requisição. Seu painel está verde. Seus usuários estão frustrados.

Códigos de status HTTP não medem o que importa aqui. A ferramenta retornou dados. Era a ferramenta certa? A resposta foi útil? O modelo realmente a usou?

Uma avaliação pública da Anthropic sobre uso agente de ferramentas (MCP Bench, fim de 2025) mediu taxas de erro de seleção entre 28% e 46% em servidores MCP populares com mais de seis ferramentas. O mesmo padrão aparece em produção: servidores com uptime perfeito, latência abaixo de 200ms, zero erros 5xx — enquanto o modelo chama a ferramenta errada quase metade do tempo.

O servidor não sabe. A equipe não sabe. Os usuários só dizem que a IA é ruim.

Isso é a falha silenciosa. Um servidor MCP pode passar em toda verificação tradicional e ainda assim responder à pergunta errada em cada chamada.

Para uma API REST, funcionar significa aceitar requisições válidas e retornar respostas corretas. Décadas de ferramentas existem para verificar isso.

Para um servidor MCP, funcionar é uma cadeia de quatro passos. O modelo escolhe a ferramenta certa. Envia parâmetros corretos. Recebe uma resposta útil. Incorpora a resposta na sua resposta. Cada passo falha independentemente. Nenhum aparece no monitoramento tradicional.

Ferramenta errada? 200. Parâmetros que passam na validação de schema mas não captam a intenção? 200. Resposta ignorada? 200.

Você pode ter 100% de sucesso no painel e 40% de sucesso em produção. Nessa lacuna os usuários dizem "a IA não funciona" — e estão certos, mesmo que cada métrica de SRE diga o contrário.

Uma vez aceito que métricas tradicionais são insuficientes, a pergunta vira o que medir no lugar. Cinco coisas.

**Precisão de seleção de ferramenta.** Se você tem `search_invoices` e `list_documents`, e um usuário pede "as faturas do mês passado", qual é chamada? Rastreie a lacuna entre seleção pretendida e real. É a métrica mais reveladora em observabilidade MCP.

**Validade de parâmetros.** Não se os parâmetros passaram na validação de schema — isso é o básico. O intervalo de datas correspondeu ao que o usuário pediu? A consulta capturou a intenção?

**Utilização de resposta.** O modelo realmente usou a resposta? Se você retorna 50 linhas e o modelo não referencia nenhuma na resposta dele, ou a descrição da ferramenta está errada, ou o formato está errado, ou os dados são irrelevantes.

**Taxa de recuperação de erros.** Quando uma chamada falha, o modelo tenta de novo com parâmetros corrigidos, troca de ferramenta ou desiste? O padrão de recuperação diz se suas mensagens de erro são úteis.

**Custo por invocação bem-sucedida.** Não custo por chamada. Custo por chamada que produziu uma resposta útil. Retries desperdiçados e chamadas à ferramenta errada costumam empurrar o custo real a 3-5x o gasto bruto da API.

Essas cinco dizem mais sobre a saúde de um servidor MCP do que todas as métricas tradicionais juntas.

Datadog, New Relic e Grafana são excelentes no que fazem. Rastreiam distribuições de latência, taxas de erro, throughput e utilização de recursos. Isso é a forma certa para uma API cujo chamador é um navegador ou um app mandando requisições determinísticas.

O chamador de um servidor MCP não é determinístico. É um modelo tomando uma decisão em tempo de inferência. O modo de falha não é "requisição expirou". É "o modelo decidiu que essa era a ferramenta certa, e não era". É um problema de qualidade de decisão, e o APM tradicional não foi feito para medir isso.

Concretamente: se seu agente tem `get_customer` e `search_customers` e o modelo sempre escolhe `get_customer` com um ID chutado, seu p99 fica plano, sua taxa de erro fica plana, e cada interação com o usuário termina em falha. O ferramental existente não tem sinal para emitir.

Você precisa de uma camada de observabilidade entre o modelo e as ferramentas — uma que consiga correlacionar intenção do usuário, seleção de ferramenta, parâmetros e utilização de resposta. APM tradicional é o chão. Para servidores MCP, nem é metade do quadro.

Três coisas concretas para começar. Não precisa resolver tudo de uma vez.

**1. Logue cada invocação com contexto completo do prompt.** Não só nome da ferramenta e parâmetros. A conversa que levou à chamada, o system prompt, a última mensagem do usuário. Sem contexto, não dá pra avaliar se a seleção foi correta.

**2. Rastreie ferramenta pretendida versus ferramenta selecionada.** Você precisa de verdade base — rótulos manuais numa amostra, sinais de polegar pra cima/baixo dos usuários, ou regras heurísticas (uma pergunta batendo com "fatura|cobrança|pagamento" que terminou em `list_contacts` é um defeito). Mesmo heurística tosca bate nada.

**3. Meça utilização de resposta.** Diff entre o que a ferramenta retornou e o que apareceu na resposta final do modelo. Uma lacuna grande significa formato ruim, dados irrelevantes, ou descrição que não ajuda o modelo a usar o resultado.

Esses três sinais — contexto de invocação, precisão de seleção, utilização de resposta — dizem se seu servidor MCP está realmente ajudando usuários. Painéis de cinco noves dizem se o processo está vivo. São perguntas diferentes.