MCP Server Health Monitor
Monitoramento de saúde para todos os seus servidores MCP — sondas, rastreamento de SLA, gráficos de dependência, reinicialização automática
Documentação
MCP Server Health Monitor
Pacote npm mcp-server-health-monitor
Monitoramento de saúde nativo do MCP que fala o protocolo, não apenas HTTP. Em vez de fazer ping em uma porta, ele chama list_tools em cada servidor — o mesmo handshake que seu agente usa — então um status verde significa que o servidor está realmente pronto para atender solicitações MCP. Todo o histórico de saúde permanece local no SQLite; nenhum serviço de monitoramento externo é necessário.
Referência de ferramentas | Configuração | Contribuição | Solução de problemas
Principais recursos
- Descoberta automática: Lê seus arquivos de configuração MCP existentes (Claude Desktop, Cursor, VS Code) sem configuração adicional.
- Sondagem não intrusiva: Apenas chama
list_toolsnos servidores alvo — somente leitura, sem efeitos colaterais. - Detecção de desvio de versão: Compara esquemas de ferramentas entre verificações para detectar quando um servidor foi atualizado.
- Tendências históricas: Armazena o histórico de latência no SQLite; p50/p95 são calculados sob demanda a partir do histórico armazenado para revelar regressões antes que se tornem indisponibilidades.
- Painel HTML: Gera um painel de saúde autocontido com minigráficos de uptime por servidor.
- Sondagem em segundo plano: Executa como um daemon para que os dados de saúde estejam sempre atualizados quando você os solicitar.
Por que isto em vez de monitores de uptime genéricos?
Monitores de uptime genéricos (UptimeRobot, Pingdom, BetterStack) verificam se uma porta está aberta ou se um endpoint HTTP retorna 200. Isso não é suficiente para servidores MCP — um servidor pode estar em execução, mas falhando ao negociar o protocolo MCP ou retornando um esquema de ferramenta quebrado.
| mcp-server-health-monitor | Monitores de uptime genéricos | |
|---|---|---|
| Método de sondagem | Chamada MCP list_tools — testa o protocolo real | Ping HTTP ou verificação de porta TCP |
| Detecção de desvio de esquema | Detecta quando assinaturas de ferramentas mudam entre versões | Não é possível sem conhecimento do protocolo |
| Descoberta automática de configuração | Lê configurações do Claude Desktop, Cursor, VS Code automaticamente | Entrada manual de URL por servidor |
| Residência de dados | SQLite local; sem serviço externo | Dados de saúde armazenados na nuvem do fornecedor |
| Custo | Gratuito, auto-hospedado | Camada gratuita limitada; pago por histórico/alertas |
Se você quer saber se seus servidores MCP estão genuinamente saudáveis — não apenas "o processo está em execução" — esta é a ferramenta certa.
Requisitos
- Node.js v20.19 ou mais recente.
- npm.
Começando
Adicione a seguinte configuração ao seu cliente MCP:
{
"mcpServers": {
"health-monitor": {
"command": "npx",
"args": ["-y", "mcp-server-health-monitor@latest"]
}
}
}
O monitor descobre automaticamente outros servidores MCP do mesmo arquivo de configuração em que está registrado. Nenhuma configuração adicional é necessária.
Configuração do cliente MCP
Amp · Claude Code · Cline · Cursor · VS Code · Windsurf · Zed
Seu primeiro prompt
Digite o seguinte no seu cliente MCP para verificar se tudo está funcionando:
Check the health of all my MCP servers.
Seu cliente deve retornar uma tabela de status mostrando cada servidor com sua latência atual e estado de saúde.
Ferramentas
Verificações de saúde (3 ferramentas)
health_check_all— sonda todos os servidores configurados em paralelo vialist_tools, mede a latência e armazena os resultados. Aceita um parâmetro opcionaltimeout_ms(padrão: 5000).get_server_status— retorna detalhes por servidor, incluindo latência, último horário visto, contagem de erros em 24 horas, última mensagem de erro e percentis de latência p50/p95. Requerserver_name.list_degraded— filtra servidores que estão offline ou com latência acima do limite. Aceita uma substituição opcionallatency_threshold.
Histórico (1 ferramenta)
get_history— retorna o histórico bruto de verificações de saúde para um servidor específico, ordenado do mais recente para o mais antigo. Requerserver_name; aceitalimitopcional (padrão: 50, máximo: 500).
Registro de servidores (2 ferramentas)
configure_server— registra um novo servidor MCP para monitoramento. Servidores adicionados dessa forma são armazenados em~/.mcp/extra-servers.jsone mesclados com servidores descobertos automaticamente. Obrigatório:name,command. Opcional:args,env.remove_server— remove um servidor registrado manualmente do monitoramento. Afeta apenas servidores adicionados viaconfigure_server; servidores descobertos automaticamente não são afetados. Requername.
Atualizações (1 ferramenta)
check_updates— detecta desvio de versão calculando hash dos esquemas de ferramentas em cada sondagem e comparando com o último hash armazenado. Retornahas_changed,previous_hash,current_hashechanged_atpor servidor.
Exportação (1 ferramenta)
export_dashboard— gera um painel HTML de arquivo único autocontido com cartões de resumo, tabela de status por servidor com latência p50/p95 e minigráficos de uptime em SVG inline. Aceita umoutput_pathopcional para gravar em disco.
Registro manual de servidores
Além da descoberta automática a partir de arquivos de configuração MCP, você pode registrar servidores que não estão na sua configuração do Claude Desktop usando a ferramenta configure_server. Servidores registrados manualmente são gravados em ~/.mcp/extra-servers.json (armazenados junto ao banco de dados de saúde) e mesclados com servidores descobertos automaticamente a cada sondagem.
Add a server named "my-internal-tool" running with command "node" and args ["/opt/tools/server.js"]
Para parar de monitorar um servidor registrado manualmente:
Remove the server named "my-internal-tool" from monitoring
Servidores descobertos a partir da configuração do Claude Desktop não podem ser removidos via remove_server — edite seu arquivo de configuração MCP diretamente para removê-los.
Configuração
--interval / --interval-seconds
Com que frequência sondar cada servidor MCP, em segundos.
Tipo: number
Padrão: 60
--latency-threshold
Latência em milissegundos acima da qual um servidor é marcado como degradado.
Tipo: number
Padrão: 1000
--db / --db-path
Caminho para o arquivo de banco de dados SQLite usado para armazenar o histórico de saúde.
Tipo: string
Padrão: ~/.mcp/health.db
--daemon
Executar como um daemon de sondagem em segundo plano. Os dados de saúde são coletados continuamente em vez de sob demanda.
Tipo: boolean
Padrão: false
--startup-grace-seconds
Período de carência em segundos antes que um servidor recém-iniciado seja considerado não saudável.
Tipo: number
Padrão: 10
Passe as flags via a propriedade args na sua configuração JSON:
{
"mcpServers": {
"health-monitor": {
"command": "npx",
"args": ["-y", "mcp-server-health-monitor@latest", "--interval=30", "--latency-threshold=500"]
}
}
}
Listagens
- Listado no MCP Registry — procure por
mcp-server-health-monitor. - Listado no MCP Market — procure por
mcp-server-health-monitor.
Verificação
Antes de publicar uma nova versão, verifique o servidor com o MCP Inspector para confirmar que todas as ferramentas estão expostas corretamente e que o handshake do protocolo é bem-sucedido.
Interface interativa (abre o navegador):
npm run build && npm run inspect
Modo CLI (scriptado / amigável para CI):
# List all tools
npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list
# List resources and prompts
npx @modelcontextprotocol/inspector --cli node dist/index.js --method resources/list
npx @modelcontextprotocol/inspector --cli node dist/index.js --method prompts/list
# Call a tool (example — replace with a relevant read-only tool for this plugin)
npx @modelcontextprotocol/inspector --cli node dist/index.js \
--method tools/call --tool-name health_check_all
# Call a tool with arguments
npx @modelcontextprotocol/inspector --cli node dist/index.js \
--method tools/call --tool-name health_check_all --tool-arg key=value
Execute antes de publicar para detectar regressões no registro de ferramentas e na inicialização do runtime.
Contribuindo
Os módulos de sondagem ficam em src/probes/. Cada sonda deve retornar um ProbeResult com status, latencyMs e um message opcional. Mantenha todas as sondas somente leitura — nunca acione efeitos colaterais nos servidores monitorados.
npm install && npm test