health_check_allLABSCO SUMMARY
A green light that means the protocol answered.
A port check tells you a process is up; this tells you the server negotiated MCP and returned a tool schema. Schema drift is the part you cannot get any other way, because it catches a server that still answers but no longer offers the tool your agent depends on.
What it is
A monitor for other MCP servers. It reads the MCP config files you already have, Claude Desktop, Cursor and VS Code, and probes each server by calling list_tools, the same handshake a client uses, then keeps the results and latency in local SQLite.
What you get
- A health sweep across every discovered server (health_check_all)
- The current state of one server (get_server_status) and everything currently degraded (list_degraded)
- Stored latency history, with p50 and p95 computed on demand from it (get_history)
- Version drift detection: tool schemas compared across checks, so a server that changed shape shows up
- A self-contained HTML dashboard with an uptime sparkline per server
- A background daemon, so the data is already fresh when you ask
- Auto-discovery of targets from your existing Claude Desktop, Cursor and VS Code configs
Requirements
The npm package mcp-server-health-monitor. Targets come from the MCP config files already on the machine, and the probe is read-only: it calls list_tools and nothing else. History stays in local SQLite, with no external monitoring service involved.
Setup effort
One command — npx -y mcp-server-health-monitor@latest
USE CASES
01
Finding out which of your servers is the broken one
Run the sweep across everything discovered from your configs and read back the degraded list. A server that fails the list_tools handshake shows up as degraded even though its process is running.
02
Explaining why an agent started failing after an update
Version drift detection compares tool schemas between checks, so a renamed or removed tool is visible as a change rather than as a mysterious failure in the agent that called it.
03
Catching a slowdown before it becomes an outage
Latency history is stored per server and p50 and p95 are computed from it on demand, which is how a server drifting from fast to nearly-timing-out becomes visible while it still works.
04
Keeping health data on your own machine
Discovery reads local config files, probing is a read-only list_tools call, and history lands in local SQLite, so monitoring an internal server does not mean registering it with a vendor.
8 tools
Listed in project docs. Your client may show a different list.
get_server_statuslist_degradedget_historyconfigure_serverremove_servercheck_updatesexport_dashboardBEFORE YOU INSTALL
What to know first
Tools you get
8 tools named in the project's documentation.
Requires
- npx on PATH
- Node.js v20.19 or later
Where it runs
All 4 documented clients run the server on your machine.
INSTALLATION
Connect your client
Server setup
TERMINAL
npx -y mcp-server-health-monitor@latestMCP Clients
Amp
AMP · JSON
{
"amp.mcpServers": {
"health-monitor": {
"command": "npx",
"args": [
"-y",
"mcp-server-health-monitor@latest"
]
}
}
}Claude Code, Cline, Other MCP clients
JSON
{
"mcpServers": {
"health-monitor": {
"command": "npx",
"args": [
"-y",
"mcp-server-health-monitor@latest"
]
}
}
}
