What Is MCP Server Monitoring?
MCP server monitoring consists of repeated, structured observations of an MCP endpoint over time, producing a historical record of status transitions and capability snapshots rather than a single connectivity ping.
A single health check captures the endpoint state at one moment. Continuous historical monitoring records successive checks across time, enabling trend analysis, status transition tracking, and capability change detection. Monitoring is meaningful only when observations are persisted and compared against prior results.
For foundational context on MCP server components and the protocol handshake that monitoring inspects, review our foundational guide on MCP servers and our protocol mechanics guide.
What Is a Monitoring Target?
MCPServerStatus uses a three-tier hierarchy: Directory Server, Monitorable Endpoint, and Monitoring Target. A Directory Server can exist in the directory even when it cannot be remotely monitored. A monitorable endpoint is a network-accessible HTTP(S) MCP endpoint. A Monitoring Target is an endpoint explicitly enrolled for recurring monitoring.
These are separate concepts because a server may publish multiple endpoints, yet only some are enrolled for monitoring. For local stdio servers, remote monitoring is generally Not available. This is not an error; stdio servers execute as local subprocesses and are not reachable over the network.
Explore registered servers and their monitoring status in our MCP Server Directory.
How an MCP Monitoring Check Works
MCPServerStatus monitoring is read-only. It does NOT call MCP tools through call_tool. The actual monitoring flow proceeds as follows:
- Endpoint: The monitoring scheduler dispatches a connection request to the monitorable endpoint.
- Connection: The scheduler establishes a transport connection (Streamable HTTP or SSE) with strict timeout handling.
- MCP Initialization: The monitor sends an
initializerequest and captures the server's protocol version and returned capabilities. - Protocol Information: The check records the negotiated protocol version, server name, server version, and transport type.
- Capability Discovery: The monitor catalogs advertised tools, resources, and prompts without executing any tool operations.
- Tools / Resources / Prompts Observation: The check records which capabilities are declared, their schemas, and their metadata.
- Result Persistence: The observation is persisted as a monitoring check record, then an incident detection step evaluates status transitions.
What Monitoring Measures
MCPServerStatus stores the following observed properties per check: status, connection success, handshake success, latency, check duration, protocol version, server name, server version, transport, capability information (tools, resources, prompts), and timestamps.
Latency measures the round-trip delay of an individual check. Availability is derived from the proportion of successful checks over observed checks. These are distinct concepts: a server can exhibit low latency yet low availability if checks fail frequently, or high latency yet high availability if checks succeed despite slower response times.
Health Checks and Status
An individual observation produces a status such as HEALTHY, DEGRADED, or DOWN. These represent the observed state for that specific check, not a long-term reliability guarantee. One observation is not the same thing as long-term reliability.
Status semantics are grounded in observed protocol behavior. A check that successfully connects and initializes with tools/resources/prompts declared typically records HEALTHY. A check where connection or handshake fails records DOWN. A check that connects but reports partial or degraded capability declarations may record DEGRADED.
Historical Monitoring
Repeated observations matter because they transform a single connectivity snapshot into a historical record. Historical monitoring covers historical checks, latency trends, status transitions, availability over observed checks, capability snapshots, and historical protocol/capability changes.
Critically, missing observations do not automatically represent downtime. A gap in the observation record may mean the scheduler did not run, the target was not monitored, or there was another gap in observation. Observed availability should be calculated from actual observations rather than assuming unobserved intervals were failures.
Incidents and Recovery
The incident model operates on observed status transitions. A transition from HEALTHY → DOWN creates an open incident. Repeated DOWN observations do not create duplicate incidents. A transition from DOWN → HEALTHY resolves the incident and records recovery timing. Endpoint isolation is preserved: incidents are tracked per endpoint, so one endpoint going down does not affect incident state for another endpoint on the same server.
The platform does not invent incident severity levels. Incident state is derived solely from observed status transitions recorded by the monitoring scheduler.
Detecting MCP Capability Changes
Historical capability snapshots can reveal changes to tools, tool schemas, resources, prompts, and advertised capabilities over time. When a subsequent observation records a different tool list, altered parameter schemas, or modified resource/prompt declarations, the change is represented as a historical server change.
The platform does not determine whether a capability change is good or bad. A removed tool may indicate a breaking change for dependent clients, but the monitoring system records the factual difference without prescribing operational judgment.
Why Missing Observations Are Not Automatically Downtime
No observation ≠ DOWN. Missing observations may mean the scheduler did not run, the target was not monitored, or there was another gap in observation. This is an important conceptual distinction because conflating unobserved intervals with failures inflates availability calculations and produces misleading reliability records.
MCPServerStatus calculates observed availability from actual observations rather than assuming unobserved intervals were failures. If a monitoring target was enrolled but never observed, the availability metric reflects that absence rather than fabricating failure data for missing periods.
What MCP Monitoring Cannot Prove
Monitoring does not automatically prove the absence of vulnerabilities, the absence of malicious behavior, the correctness of every tool, the security of external systems, the semantic correctness of tool outputs, complete client compatibility, or the absence of intermittent failures between checks.
For a deeper understanding of what monitoring evidence can and cannot establish about security boundaries, review our MCP Server Security guide. For protocol-level compatibility considerations, see our MCP Server Compatibility guide.
How MCPServerStatus Monitors MCP Servers
MCPServerStatus monitors MCP servers through the following operational components: monitoring targets enrolled for recurring checks, a scheduler that dispatches checks at configured intervals, leases and concurrency protection that prevent overlapping check executions against the same target, historical observations persisted per check, incidents derived from observed status transitions, capability snapshots recorded per observation, hourly and daily aggregates supporting longer-range historical views, and public monitoring history accessible through the MCP Server Directory.
The platform does not expose secrets or internal credentials. Monitoring checks do not execute MCP tools and do not perform destructive operations. All observations are read-only protocol inspections that record what the server declares during initialization, not what the server might execute under arbitrary client requests.
For information on actual health check specifications and the SSRF protections applied to every endpoint, review the Health Check Specifications.