O que acontece quando uma chamada de ferramenta MCP nunca retorna?

Uma chamada normal de ferramenta MCP é direta: o cliente envia uma solicitação, o servidor executa a ferramenta e uma resposta é retornada.

Um hang é diferente. O servidor aceita a chamada, mas nunca retorna um resultado ou um erro.

Eu queria testar como um cliente MCP se comporta nesse caso sem depender de truques de rede ou matar manualmente um processo.

Reproduzindo um hang

O Laboratório de Falhas MCP tem uma ferramenta hang especificamente para isso.

O comportamento é intencionalmente simples: uma vez chamada, não se resolve.

Isso nos dá uma falha repetível em vez de tentar aproximar uma com um atraso muito longo.

Um cenário para isso se parece com isto:

{
  "name": "chamada de ferramenta pendente expira",
  "call": {
    "tool": "hang",
    "args": {}
  },
  "timeoutMs": 1000,
  "expect": {
    "outcome": "timeout"
  }
}

O comportamento do servidor e o comportamento esperado do cliente são separados aqui.

O servidor fica pendente.

Espera-se que o cliente expire após um segundo.

Essa distinção é importante porque um servidor pendente não produz um timeout por si só. O timeout deve ser imposto pelo cliente ou por algo em torno da solicitação.

Hang vs atraso

Eu originalmente tratei um longo atraso como sendo próximo o suficiente de um hang, mas eles são úteis para testar coisas diferentes.

Uma chamada atrasada ainda tem um ponto de conclusão:

solicitação ---- 5 segundos ----> resposta

Uma chamada pendente não tem:

solicitação -------------------->
        -------------------->
        -------------------->

Com um atraso, uma resposta ainda pode chegar após o cliente ter expirado.

Com um hang, não há resposta eventual.

Essa diferença começa a importar ao testar cancelamento e limpeza.

Um timeout apenas te diz o que o cliente viu

Suponha que um cliente chame uma ferramenta e receba um timeout.

É tentador tratar isso como se a operação tivesse falhado.

Isso não é necessariamente verdade.

Considere uma ferramenta que muda algum estado:

cliente                    servidor
   |                         |
   | ---- solicitação ------>|
   |                         | muda o estado
   |                         |
   |       resposta perdida   X
   |
   | ---- timeout

O cliente viu um timeout, mas o servidor pode já ter completado a operação.

Se o cliente tentar automaticamente novamente, a operação pode ser executada duas vezes.

Essa é uma razão pela qual estou interessado em manter o resultado observado separado do estado do servidor no Laboratório de Falhas.

É também onde o simples teste de timeout para de ser suficiente.

O que deve acontecer após o timeout?

Há algumas coisas que valem a pena verificar além de se um timeout foi lançado:

• É a operação original cancelada?
• É a sessão MCP ainda utilizável?
• Outra chamada de ferramenta pode ter sucesso?
• O cliente tenta novamente?
• Você pode determinar se a operação original mudou de estado?

A última é particularmente útil para ferramentas com efeitos colaterais.

O Laboratório de Falhas suporta uma chamada observe independente para cenários onde o estado precisa ser verificado após a chamada principal.

Isso permite que um teste diferencie entre:

cliente observado: timeout
estado do servidor: inalterado

e:

cliente observado: timeout
estado do servidor: alterado

Esses são resultados muito diferentes, mesmo que o cliente tenha relatado o mesmo erro.

Mantendo a falha determinística

A principal razão pela qual construí a falha de hang não foi para simular uma rede não confiável.

Foi para remover a parte não confiável do teste.

Se o servidor ficar pendente de forma determinística, posso executar diferentes clientes contra o mesmo comportamento e comparar o que eles fazem.

O caminho ainda passa pelo MCP:

cenário
   ↓
cliente MCP
   ↓
transporte
   ↓
servidor MCP
   ↓
hang

Somente a falha é controlada.

Isso torna os bugs em torno do tratamento de timeout muito mais fáceis de reproduzir.

Tente isso

O projeto é de código aberto:

npx mcp-failure-lab demo

GitHub: https://github.com/anilloutombam/mcp-failure-lab

Estou trabalhando em outros casos de falha também, particularmente cancelamento, perda de sessão, respostas malformadas e casos onde o cliente relata falha mesmo que o servidor tenha mudado de estado.

Se você encontrou uma falha MCP que foi difícil de reproduzir, abra um problema. Eu prefiro transformar casos reais de falha em cenários determinísticos do que inventá-los.