Health monitoring for all your MCP servers
Health Monitor MCP server is a hosted integration for AI assistants that speak the Model Context Protocol. Health monitoring for all your MCP servers.
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.
Being a remote server, there is no local install. You register the endpoint with your client, authorise it once, and the tools appear.
Once Health Monitor is connected, these are the calls the assistant has available:
health_check_all — probes all configured servers in parallel via list_tools, measures latency, and stores results. Accepts an optional timeout_ms parameter (defaultget_server_status — returns per-server detail including latency, last seen time, 24-hour error count, last error message, and p50/p95 latency percentiles. Requireslist_degraded — filters to servers that are offline or have latency above the threshold. Accepts an optional latency_threshold overrideconfigure_server — registers a new MCP server to monitor. Servers added this way are stored in ~/.mcp/extra-servers.json and merged with auto-discovered serversremove_server — removes a manually registered server from monitoring. Only affects servers added via configure_server; auto-discovered servers are not affectedPlenty of monitoring and observability servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Health Monitor's toolset — health_check_all, get_server_status, list_degraded and 2 more — is a fair guide to whether it matches your workflow. It is maintained by dbsectrainer; worth a glance at recent repository activity before you build anything load-bearing on it.
We check each listing at SyncDev against the project's documentation before it goes live — if something here drifts out of date, it is a bug worth reporting.
| Tool | What it does |
|---|---|
| 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. |
| 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. |
{
"mcpServers": {
"health-monitor": {
"command": "npx",
"args": ["-y", "mcp-server-health-monitor@latest"]
}
}
}Configuration as documented by the project. Restart the client after saving.
Give your coding agent the full DevTools toolbox: traces, network, console, heap snapshots and Lighthouse.
Dashboards, Prometheus and Loki queries, incidents and alerts — observability by conversation.
Errors with full context — stack traces, issue triage and AI-powered root-cause analysis from Sentry's server.
Enables enhanced web research capabilities for large language models through intelligent search queuing and advanced content extraction.
Automates browser interactions and enables Large Language Models (LLMs) to interact with web pages through Playwright and Chrome DevTools Protocol
Guides tool usage by providing recommendations for MCP tools at each problem-solving stage.