MCP Health Monitor
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HEALTH_MONITOR_DB | No | Override the default database path for the SQLite database (default: ~/.mcp-health-monitor/health.db) | |
| HEALTH_MONITOR_AUTO_CHECK | No | Enable the optional background scheduler for automatic health checks when set to 1 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_azure_pipelinesB | Register Azure DevOps pipelines to monitor for CI, publish, and mirror status. |
| register_serverA | Register an MCP server to monitor. Supports http, sse, and stdio transports. |
| check_pipeline_statusA | Get the latest run status of registered Azure DevOps pipelines for one group or all groups. |
| check_serverC | Check the health of a registered MCP server, list tools, and measure response time. |
| check_allB | Check health of all registered MCP servers in parallel. |
| get_pipeline_logsA | Fetch logs from a specific Azure DevOps build to investigate pipeline failures. |
| get_uptimeA | Get uptime history and statistics for a registered MCP server. |
| check_all_projectsA | Check both MCP server health and Azure DevOps pipeline status across all registered projects. |
| get_dashboardA | Get a dashboard overview of all registered MCP servers with uptime and performance stats. |
| get_reportA | Get a human-readable Markdown health report for all servers. Paste directly into chat or docs. |
| list_serversC | List all registered MCP servers with their current status. |
| unregister_serverB | Remove a server from monitoring. |
| get_monitor_statsA | Get statistics about the health monitor itself, including database activity. |
| set_alertA | Configure alert thresholds for response time, uptime, and consecutive failures. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 14 tools
Most tools are clearly distinct: registration, checks, logs, alerts, reports, and stats each target a different concern. However, 'get_dashboard' and 'get_report' overlap significantly (both provide overviews of monitored servers), and 'check_all' vs 'check_all_projects' could be confused by an agent (one covers only servers, the other covers servers plus pipelines).
All tools follow a consistent verb_noun pattern (register_*, check_*, get_*, set_*, list_*, unregister_*). Even the compound 'check_all_projects' fits the pattern as a verb with a clear object. There are no mixed naming conventions or vague verbs like 'process' or 'execute'.
14 tools is well within the ideal 3-15 range. Each tool has a specific purpose in the monitoring domain, and the count supports comprehensive coverage without overwhelming an agent. The tool set is broad enough to cover registration, health checks, pipeline status, logs, reports, alerts, and stats.
The tool surface covers the core lifecycle: register, check, unregister, get logs, get history, get reports, and set alerts. Minor gaps include lack of explicit update/edit for registered servers or pipelines (e.g., changing transport or platform), and no tool to pause/resume monitoring, but agents can often work around those by re-registering.