O que acontece quando uma ferramenta MCP falha no meio do caminho? Transformando falhas em testes de regressão

Eu mantenho o ResiliReplay e o construí em torno de uma pergunta que continuava sobrevivendo aos testes de fumaça MCP comuns: o que acontece depois que o servidor foi descoberto e uma ferramenta falha na fronteira entre "requisição aceita" e "resultado útil retornado"?

A maioria das verificações de primeira passagem é necessariamente otimista. Inicie o servidor, chame tools/list, invoque uma ferramenta com argumentos válidos e confirme uma resposta limpa. Isso prova que a integração pode funcionar. Não prova que um cliente se recupera dentro de um orçamento, evita efeitos colaterais duplicados, rejeita saídas hostis ou preserva o mesmo comportamento após uma alteração de código posterior.

O trabalho de confiabilidade começa onde essa chamada limpa para.

O Inspector e o ResiliReplay respondem a perguntas diferentes

O MCP Inspector é útil para interagir com um servidor: descobrir ferramentas, inspecionar esquemas, fornecer argumentos e ver respostas reais. O ResiliReplay aceita uma configuração em forma de Inspector, mas não é um substituto para esse fluxo de trabalho interativo.

A divisão que eu uso é simples:

• O Inspector responde: "O que este servidor expõe e uma chamada normal funciona?"
• O ResiliReplay pergunta: "O que acontece quando uma falha declarada é inserida, a recuperação permanece dentro do seu orçamento e posso reproduzir o resultado mais tarde?"

Essa segunda pergunta precisa de mais do que injeção de falhas aleatórias. Uma campanha útil deve ser limitada e revisável: uma semente, cenários explícitos, uma pequena lista de ferramentas permitidas, orçamentos de tentativas e tempo fixos, expectativas declaradas e evidências locais. Se uma campanha chamar uma ferramenta, o ResiliReplay imprime um plano de revisão canônico e requer o hash exato da campanha de volta antes da execução.

Comece sem contatar o servidor

Com Node.js 22 ou 24, o ponto de entrada mínimo é uma execução seca:

npx --yes resilireplay@0.3.1 mcp audit \
  --inspector-config ./mcp.json \
  --server meu-servidor \
  --dry-run

A saída descreve o executável, a lista de argumentos, o diretório de trabalho, transporte, timeouts e nomes de variáveis de ambiente. Não inicia o servidor nem chama uma ferramenta. Isso torna um lugar útil para capturar um alvo incorreto ou uma configuração inesperadamente ampla.

Em seguida, gere um modelo de campanha:

npx --yes resilireplay@0.3.1 campaign init reliability.campaign.yml
npx --yes resilireplay@0.3.1 campaign validate reliability.campaign.yml

Para um teste de campo inicial, mantenho a concorrência em um, permito exatamente uma ferramenta idempotente somente leitura, defino tentativas para uma e uso três cenários.

1. Estabeleça um controle limpo

O controle usa fault: none e espera uma aprovação com zero tentativas. Isso não é cerimonial. Sem um controle limpo, uma falha injetada pode ser confundida com uma instalação quebrada, um diretório de trabalho inválido, um binário de navegador ausente ou uma versão de servidor incompatível.

Uma das minhas configurações MCP do Playwright demonstrou o ponto: a recuperação falhou porque o Chrome para Testes não estava instalado. Essa foi uma falha de ambiente, não uma evidência sobre a recuperação do Playwright MCP. Após usar o instalador documentado, o controle limpo e a campanha limitada puderam ser interpretados honestamente.

2. Injetar uma falha de nível de resultado e tentar novamente uma vez

O próximo cenário usa mcp-tool-error com recovery: retry. O ResiliReplay permite que a chamada real da ferramenta seja concluída, substitui o resultado observado na fronteira do teste por um erro controlado e permite uma tentativa. As afirmações exigem recuperação bem-sucedida, não mais do que uma tentativa, nenhuma tentativa de efeito colateral duplicado e conformidade com a política.

Essa distinção importa. O servidor não continha o erro injetado; o suporte o introduziu. Uma aprovação significa apenas que o comportamento observado correspondeu a este experimento declarado.

3. Adicione um controle negativo canário malicioso

O terceiro cenário injeta mcp-malicious-canary-instruction e espera falha. Seu propósito é mostrar que a campanha pode detectar uma condição ruim conhecida em vez de relatar verde independentemente da entrada.

Este é um controle negativo, não uma reivindicação de vulnerabilidade. O canário é sintético, nenhum segredo real é usado e o resultado esperado é registrado antes da execução. Quando a falha esperada ocorre, o ResiliReplay reduz a trilha causal e escreve um cenário, fixture minimizada, teste Node executável e manifesto. O executor da campanha executa essa regressão gerada imediatamente.

As linhas de base devem falhar fechadas

Após uma execução completa que corresponde às expectativas, aprove-a explicitamente:

npx --yes resilireplay@0.3.1 campaign approve runs/field-test \
  --output baselines/field-test.json

npx --yes resilireplay@0.3.1 campaign compare runs/field-test \
  --baseline baselines/field-test.json \
  --output runs/comparison

A comparação verifica a identidade da execução e métricas declaradas, como queda de pontuação, tentativas e tentativas duplicadas. Evidências incompletas ou inválidas de hash não são tratadas silenciosamente como uma aprovação. Esta é a parte que transforma um experimento único em um limite de CI.

Três validações de campo limitadas

Eu executei o pacote público resilireplay@0.3.0 contra três projetos independentes mantidos, sobre seus caminhos stdio locais documentados:

• Servidor MCP Everything: echo com texto gerado inofensivo.
• Playwright MCP: browser_snapshot em uma página isolada em branco sem navegação.
• Servidor UI5 MCP: get_guidelines contra orientações agrupadas, sem análise de projeto.

Cada campanha executou o controle limpo, um erro de resultado de ferramenta injetado com uma tentativa bem-sucedida e o controle negativo canário. Cada controle negativo produziu uma regressão executável verificada. Cada comparação de linha de base aprovada relatou zero diferenças. Os comandos completos, versões, limites e evidências sanitizadas estão em resultados de campo.

Esses são três estudos de caso limitados, não benchmarks universais. Eles cobrem uma operação revisada por servidor. Eles não classificam os projetos, não implicam adoção upstream ou certificam segurança. O HTTP transmitido é exercido pelos fixtures automatizados locais do ResiliReplay, mas nenhum dos três pacotes externos selecionados o utilizou como o caminho primário local documentado, então não os apresento como evidência de HTTP de terceiros.

Limites e fronteiras de segurança

O ResiliReplay é defensivo