Desenvolvi três ferramentas para auditar servidores MCP

Nas últimas semanas, construí três pequenas CLIs independentes que verificam de diferentes maneiras como um servidor MCP (Modelo de Protocolo de Contexto) pode falhar — não lendo textos de marketing, mas apontando-as para servidores reais e populares e lendo o que retornou.

As três ferramentas fazem três perguntas diferentes:

• mcp-doctor — está documentado? Análise estática do código-fonte: descrições de ferramentas ausentes, parâmetros não documentados, segredos codificados, sem tratamento de erros, sem testes.
• mcp-fuzz — falha de forma segura? Realmente inicia o servidor via stdio e chama cada ferramenta somente leitura com entradas inválidas derivadas do esquema (campos obrigatórios ausentes, tipos errados) para ver se retorna um erro estruturado ou apenas trava.
• mcp-reality-check — realmente funciona? Chama ferramentas com entradas realistas e verifica se uma resposta "bem-sucedida" é realmente honesta: não é uma recusa disfarçada, não é conteúdo vazio, não ignora seu próprio esquema de saída declarado.

Nenhuma delas usa um LLM para julgar nada. Todas as três são totalmente estáticas/heurísticas por design — determinísticas, sem chave de API, sem custo por chamada.

O padrão que eu não esperava: cada ferramenta encontrou um bug real em si mesma

Eu testei todas as três contra servidores reais enquanto as construía, e a mesma coisa aconteceu três vezes: a primeira passagem séria de teste contra um servidor do mundo real encontrou um bug genuíno na lógica da minha própria ferramenta, não no alvo.

• mcp-doctor, contra homeassistant-ai/ha-mcp (4.5k estrelas): o scanner de segredos estava sinalizando fixtures de teste e constantes de estilo identificador como credenciais codificadas, e a detecção de ferramentas estava contando funções simuladas dentro de arquivos de teste como ferramentas reais. Ambos estavam errados — a pontuação real do servidor corrigiu de um falso 55%/F para um preciso 89%/B. Essa correção levou a um PR mesclado upstream: https://github.com/homeassistant-ai/ha-mcp/pull/2327
• mcp-fuzz, contra mendableai/firecrawl-mcp-server: um servidor que valida entradas com zod e retorna corretamente um erro JSON-RPC bem formado -32602 INVALID_PARAMS estava sendo classificado da mesma forma que um crash real, por causa de uma exceção genérica. Identifiquei a verdadeira distinção (-32602 = servidor validou e rejeitou corretamente; -32603 e tudo o mais = ainda conta como quebrado) e corrigi — mas não antes de quase inverter uma descoberta já publicada e citada em outro repositório para uma aprovação falsa. Peguei isso re-testando o repositório citado antes de enviar, não depois.
• mcp-reality-check, contra modelcontextprotocol/server-time: não havia dica de fuso horário no gerador de entrada realista, então cada propriedade com formato de fuso horário recebeu uma string de espaço reservado falsa e cada chamada falhou. Corrigido adicionando um nome de fuso horário IANA real como dica.

Não acho que isso seja uma coincidência. É o que acontece quando você constrói uma ferramenta cujo trabalho é julgar a correção, e então finalmente a aponta para algo popular o suficiente para ter casos extremos que você não pensou. Se sua própria ferramenta nunca encontra um bug em si mesma na primeira vez que encontra o mundo real, você provavelmente não a testou contra nada difícil o suficiente ainda.

A descoberta mais forte até agora

Executar mcp-fuzz contra antvis/mcp-server-chart (4.3k estrelas, servidor MCP oficial do Ant Design, 27 ferramentas de geração de gráficos) descobriu que todas as 27 ferramentas travam — erros internos JSON-RPC -32603 brutos, não erros estruturados a nível de ferramenta — com entradas obrigatórias ausentes ou de tipo errado. 133 de 214 chamadas de teste falharam dessa forma. Registrado como problema #323: https://github.com/antvis/mcp-server-chart/issues/323

Rastreado mais adiante: a correção já existe no main (um commit não lançado, 9fd0bb4), apenas nunca publicado no npm. Construí o main localmente, reproduzi todos os quatro casos de repro do problema diretamente via stdio, confirmei que a correção realmente resolve o que o mcp-fuzz sinaliza. Postei isso como um comentário em vez de um pedido de "por favor, conserte isso", já que não havia nada mais a consertar — apenas um lançamento não publicado. O mantenedor desde então pediu a entrada exata de repro, que postei como cargas úteis JSON-RPC literais.

Onde as coisas estão

• mcp-doctor: 33+ passes de dogfood do mundo real, um PR mesclado upstream, um placar público ao vivo avaliando 17 servidores MCP reais em qualidade e segurança: https://vishalhabib99.github.io/mcp-doctor/
• mcp-fuzz: ~15 passes, a descoberta antvis acima.
• mcp-reality-check: 13 passes, o mais novo dos três, ainda alcançando seu histórico.

Nenhuma dessas ferramentas tem tração real ainda — isso é de algumas semanas, construído sozinho, com basicamente zero estrelas ou seguidores por trás. Estou escrevendo isso porque o processo em si — construir uma ferramenta, imediatamente desconfiar dela, verificá-la contra algo real antes de acreditar em sua saída — é a parte que eu acho que realmente vale a pena compartilhar, independentemente de as ferramentas em si algum dia se tornarem populares.

Repositórios: mcp-doctor · mcp-fuzz · mcp-reality-check