health_check_all
Ping every configured MCP server via list_tools, measure latency, and store results. Returns a summary of all servers.
timeout_ms
io.github.dbsectrainerPublished by GitHub account dbsectrainerv1.0.1Updated Nov 4, 2026
Health monitoring for all your MCP servers
Monitors the health of your other MCP servers by probing them over the MCP protocol, tracking latency and schema drift, and exporting a local HTML dashboard.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Follow the launch instructions in the repository.
npm mcp-server-health-monitor package
MCP-native health monitoring that speaks the protocol, not just HTTP. Instead of pinging a port, it calls list_tools on each server — the same handshake your agent uses — so a green status means the server is actually ready to serve MCP requests. All health history stays local in SQLite; no external monitoring service required.
Tool reference | Configuration | Contributing | Troubleshooting
list_tools on target servers — read-only, no side effects.Generic uptime monitors (UptimeRobot, Pingdom, BetterStack) check whether a port is open or an HTTP endpoint returns 200. That's not enough for MCP servers — a server can be running but failing to negotiate the MCP protocol or returning a broken tool schema.
If you want to know that your MCP servers are genuinely healthy — not just "the process is running" — this is the right tool.
Add the following config to your MCP client:
The monitor auto-discovers other MCP servers from the same config file it is registered in. No additional setup required.
Amp · Claude Code · Cline · Cursor · VS Code · Windsurf · Zed
Enter the following in your MCP client to verify everything is working:
Your client should return a status table showing each server with its current latency and health state.
health_check_all — probes all configured servers in parallel via list_tools, measures latency, and stores results. Accepts an optional timeout_ms parameter (default: 5000).get_server_status — returns per-server detail including latency, last seen time, 24-hour error count, last error message, and p50/p95 latency percentiles. Requires server_name.list_degraded — filters to servers that are offline or have latency above the threshold. Accepts an optional latency_threshold override.get_history — returns raw health check history for a specific server, ordered most-recent first. Requires server_name; accepts optional limit (default: 50, max: 500).configure_server — registers a new MCP server to monitor. Servers added this way are stored in ~/.mcp/extra-servers.json and merged with auto-discovered servers. Required: name, command. Optional: args, env.remove_server — removes a manually registered server from monitoring. Only affects servers added via configure_server; auto-discovered servers are not affected. Requires name.check_updates — detects version drift by hashing tool schemas on each probe and comparing against the last stored hash. Returns has_changed, previous_hash, current_hash, and changed_at per server.export_dashboard — generates a self-contained single-file HTML dashboard with summary cards, per-server status table with p50/p95 latency, and inline SVG uptime sparklines. Accepts an optional output_path to write to disk.In addition to auto-discovery from MCP config files, you can register servers that are not in your Claude Desktop config using the configure_server tool. Manually registered servers are written to ~/.mcp/extra-servers.json (stored alongside the health database) and merged with auto-discovered servers on every probe.
To stop monitoring a manually registered server:
Servers discovered from Claude Desktop's config cannot be removed via remove_server — edit your MCP config file directly to remove those.
--interval / --interval-secondsHow often to poll each MCP server, in seconds.
Type: number
Default: 60
--latency-thresholdLatency in milliseconds above which a server is marked as degraded.
Type: number
Default: 1000
--db / --db-pathPath to the SQLite database file used to store health history.
Type: string
Default: ~/.mcp/health.db
--daemonRun as a background polling daemon. Health data is collected continuously rather than on-demand.
Type: boolean
Default: false
--startup-grace-secondsGrace period in seconds before a newly started server is considered unhealthy.
Type: number
Default: 10
Pass flags via the args property in your JSON config:
mcp-server-health-monitor.mcp-server-health-monitor.Before publishing a new version, verify the server with MCP Inspector to confirm all tools are exposed correctly and the protocol handshake succeeds.
Interactive UI (opens browser):
CLI mode (scripted / CI-friendly):
Run before publishing to catch regressions in tool registration and runtime startup.
Probe modules live in src/probes/. Each probe must return a ProbeResult with status, latencyMs, and an optional message. Keep all probes read-only — never trigger side effects on monitored servers.
Source: README.md at commit e9184e3
Ping every configured MCP server via list_tools, measure latency, and store results. Returns a summary of all servers.
timeout_msGet detailed health status for a specific MCP server by name.
server_namerequiredList all MCP servers that are offline or have latency above the threshold.
latency_thresholdCompare current tool schemas against last stored schemas to detect version drift across MCP servers.
timeout_msGenerate a self-contained HTML health dashboard with server status, latency trends, and uptime sparklines.
output_pathReturn the raw health check history for a specific MCP server, ordered most-recent first.
limitserver_namerequiredRegister a new MCP server to monitor. Servers added this way are stored in a supplementary config file alongside the database and are merged with servers discovered from Claude's config. Use this to monitor servers not present in Claude Desktop's config.
envargsnamerequiredcommandrequiredRemove a manually configured MCP server from monitoring. Only affects servers added via configure_server — servers discovered from Claude's config are not affected.
namerequired90% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
{ "mcpServers": { "health-monitor": { "command": "npx", "args": ["-y", "mcp-server-health-monitor@latest"] } }}Check the health of all my MCP servers.Add a server named "my-internal-tool" running with command "node" and args ["/opt/tools/server.js"]Remove the server named "my-internal-tool" from monitoring{ "mcpServers": { "health-monitor": { "command": "npx", "args": ["-y", "mcp-server-health-monitor@latest", "--interval=30", "--latency-threshold=500"] } }}npm run build && npm run inspect# List all toolsnpx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list
# List resources and promptsnpx @modelcontextprotocol/inspector --cli node dist/index.js --method resources/listnpx @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 argumentsnpx @modelcontextprotocol/inspector --cli node dist/index.js \ --method tools/call --tool-name health_check_all --tool-arg key=valuenpm install && npm test