Timeout de 500ms Resulta em 28 Horas

Eu tinha um servidor MCP que ocasionalmente travava, então eu lhe dei uma curta folga:

{ "mcpServers": { "flaky": { "type": "http", "url": "...", "timeout": 500 } } }

timeout está em milissegundos, então isso é lido como meio segundo.

Valores abaixo de 1000 são ignorados. A chamada cai para
MCP_TOOL_TIMEOUT, e se isso não estiver definido, para seu padrão — cerca de 28 horas.

Eu escrevi o limite mais restrito que consegui e produzi o mais solto disponível.

Antes da v2.1.162, um valor abaixo de 1000 era arredondado para um segundo, que é o
comportamento que eu tinha em mente. Isso mudou, e nada na minha configuração
mudou com isso.

Três coisas relacionadas que só aprendi lendo toda a seção:

• timeout é um limite rígido de relógio por chamada de ferramenta. As notificações de progresso não estendem isso
• Um timeout de pelo menos 1000 também atua como um piso no timeout ocioso — as chamadas nunca são abortadas por ociosidade antes disso
• servidores stdio e WebSocket têm nenhum temporizador por solicitação

Um url sem type é lido como um servidor stdio

{ "mcpServers": { "example": { "url": "https://mcp.example.com/mcp" } } }

Não há padrão para http. Uma entrada sem type é um servidor stdio,
stdio requer command, e assim o servidor é ignorado como um erro de configuração:

O servidor MCP "example" tem um "url" mas sem "type"; adicione "type": "http" (ou "sse" / "ws") a esta entrada

Essa mensagem existe desde a v2.1.202. Antes disso, o mesmo erro reportava
command: expected string, received undefined — você escreveu uma url e foi informado
sobre um comando, o que é uma longa distância da causa.

Com --output-format stream-json isso também aparece no evento system/init
mcp_server_errors, então um script pode detectar que um servidor nunca carregou. Isso é
a única forma legível por máquina que encontrei para isso.

Um repositório clonado não pode aprovar seus próprios servidores

Isso me custou mais tempo, porque parece um bug de permissões.

Servidores de .mcp.json precisam de aprovação. Você pode confirmar
enableAllProjectMcpServers ou enabledMcpjsonServers nas configurações do projeto
.claude/settings.json — e em uma pasta não confiável, eles são ignorados. O
servidor fica em ⏸ Aguardando aprovação, nunca conectado, nunca verificado quanto à saúde.

O que está correto, e óbvio uma vez declarado: um repositório que poderia aprovar seus
próprios servidores MCP seria uma forma de executar código em qualquer um que o clone.

Três fontes de aprovação ainda se aplicam em uma pasta não confiável: seu próprio
~/.claude/settings.json, configurações gerenciadas e configurações passadas com
--settings.

O padrão em todos esses casos

Cada um deles é uma configuração que carrega. Nenhum erro, nenhuma advertência que você
notaria, e um sistema em execução que está fazendo algo diferente do que o
arquivo diz.

timeout: 500 é o exemplo mais agudo: o arquivo diz meio segundo, o sistema
diz um dia e pouco, e ambos estão funcionando como projetado.

O que eu quero de um verificador de configuração, tendo estado do lado errado disso,
não são mais regras. É que as que ele tem nunca disparem em algo
correto — porque a razão pela qual parei de ler a saída de inicialização no primeiro lugar
foi que nada ali tinha importância, e quando algo realmente importou, eu já havia
me treinado a ignorar.

npx @quintetkit/ccheck

erro .mcp.json:3
      O servidor "example" tem um `url` mas sem `type`. Adicione `"type": "http"` (ou "sse" / "ws").
warn  .mcp.json:9
      O servidor "flaky": `timeout: 500` está em milissegundos; valores abaixo de 1000 são ignorados.

O conjunto completo, incluindo o campo obrigatório por transporte:

https://quintetkit.github.io/en/reference/claude-code-mcp-json.html

Eu publico a configuração para dividir o Claude Code em personas separadas —
Arquiteto, Codificador, Revisor, Resolutor de Conflitos — sob MIT. Copie, execute
./setup.sh, e funciona. Não depende da sua pilha tecnológica.

https://github.com/quintetkit/quartet

Eu construí uma ferramenta real usando nada além desse fluxo de trabalho. Cada Problema, PR, revisão
e mesclagem ainda estão lá. As partes que deram errado não foram deletadas.

https://github.com/quintetkit/mdlinkcheck

A versão que adiciona uma persona de Designer de UI, critérios de revisão, um script de execução paralela por Problema
e um guia de 11 capítulos está na
página do produto.

O kit completo — cinco personas, os scripts e o guia completo — está disponível aqui.

https://quintetkit.gumroad.com/l/quintet