MCP Server Health Monitor

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

Key features

• Auto-discovery: Reads your existing MCP config files (Claude Desktop, Cursor, VS Code) with no extra setup.
• Non-intrusive probing: Only calls list_tools on target servers — read-only, no side effects.
• Version drift detection: Compares tool schemas across checks to detect when a server has been updated.
• Historical trends: Stores latency history in SQLite; p50/p95 are computed on-demand from stored history to surface regressions before they become outages.
• HTML dashboard: Generates a self-contained health dashboard with uptime sparklines per server.
• Background polling: Runs as a daemon so health data is always fresh when you ask for it.

Why this over generic uptime monitors?

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.

Requirements

• Node.js v20.19 or newer.
• npm.

Getting started

Add the following config to your MCP client:

{
  "mcpServers": {
    "health-monitor": {
      "command": "npx",
      "args": ["-y", "mcp-server-health-monitor@latest"]
    }
  }
}

The monitor auto-discovers other MCP servers from the same config file it is registered in. No additional setup required.

MCP Client configuration

Amp · Claude Code · Cline · Cursor · VS Code · Windsurf · Zed

Your first prompt

Enter the following in your MCP client to verify everything is working:

Check the health of all my MCP servers.

Your client should return a status table showing each server with its current latency and health state.

Tools

Health checks (3 tools)

• 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.

History (1 tool)

• get_history — returns raw health check history for a specific server, ordered most-recent f

... View full README on GitHub