What Does MCP Server Status Mean?
MCP server status is a representation of the latest observed condition of a monitored MCP endpoint, derived from a monitoring check that tested connection, handshake, and protocol-level capability discovery.
Status reflects what was observed during the most recent monitoring check, not an assumption about an endpoint that has not been observed. The status shown by MCPServerStatus is based on monitoring evidence.
It is critical to distinguish two concepts:
- Current status: The single latest observed state recorded for a monitored endpoint.
- Historical observations: The sequence of stored monitoring checks and status transitions recorded over time.
For how those observations are collected, see our MCP Server Monitoring guide.
HEALTHY, DEGRADED, and DOWN
HEALTHY, DEGRADED, and DOWN are the three status states used by MCPServerStatus. These states represent monitoring observations for a specific endpoint, not a universal statement about every possible client or use case.
HEALTHY: The monitoring check successfully connected, completed the MCP handshake, and observed declared capabilities without errors.
DEGRADED: The endpoint responded, but the observation indicated a partial failure — for example, a handshake that completed with warnings or a capability observation that returned incomplete results.
DOWN: The monitoring check could not complete observation — for example, the connection failed, the handshake failed, or the endpoint was unreachable.
These states are scoped to observed monitoring behavior. A server marked HEALTHY on one endpoint is not implicitly healthy on every possible connection path.
How Current Status Is Determined
Current status is determined by observing a monitoring check result that tested connection, handshake, and protocol-level capability discovery for a monitored endpoint, then recording the outcome as a monitoring check.
The conceptual flow is:
- An MCP endpoint receives a monitoring check.
- The check tests connection and handshake, observes protocol and capability information.
- The observation result maps to a status: HEALTHY, DEGRADED, or DOWN.
- The result is persisted as a monitoring check record.
- The latest persisted record becomes the current status.
Current status does not describe the detailed collection process — for that, see our monitoring guide.
Status Transitions
A status transition is the change from one observed status to a different observed status across successive monitoring checks. Transitions such as UNKNOWN → HEALTHY, HEALTHY → DOWN, and DOWN → HEALTHY are recorded when the observation state changes.
Transitions are useful because they indicate when an observed condition changed, rather than simply reporting the latest state. A stable HEALTHY status with no transitions suggests continuous observed connectivity; a transition to DOWN indicates a change that warrants review.
Only observed transitions are recorded. Repeated checks at the same status do not generate new transition records.
MCP Incidents and Recovery
Incidents are associated with observed status transitions. When a monitored endpoint transitions from HEALTHY to DOWN, an open incident can be created. Repeated DOWN observations do not create duplicate incidents.
When the endpoint returns from DOWN to HEALTHY, the open incident is resolved and recovery timing is recorded based on the observed transition.
Incidents are scoped per endpoint. A status change on one endpoint does not affect incident state on another endpoint of the same MCP server. Do not interpret an incident as meaning the server was continuously unavailable outside observed checks.
Observed Availability Is Not a Guarantee
Observed availability is derived from actual monitoring observations and is not a guaranteed uptime or SLA.
Observed availability is calculated from the proportion of successful checks among observed checks. Missing observation periods are excluded rather than automatically counted as failures. This means availability reflects only what was actually measured, not assumptions about unobserved time.
MCPServerStatus does not provide an SLA or uptime guarantee. Observed availability describes historical monitoring evidence, not a contractual commitment.
Understanding MCP Server Latency
MCP server latency is recorded as an observation per check, and historical latency reflects variation across observations, but a single latency measurement is not a universal performance guarantee.
Each monitoring check records the round-trip delay observed during that check. When multiple checks exist, latency history shows how observed latency varied over time for that endpoint from the monitoring location.
Latency is an observation, not a universal guarantee. A single latency value does not represent every user or geographic region, and latency does not alone indicate whether a server is operational or down.
Why No Observation Does Not Mean DOWN
No observation ≠ DOWN. An endpoint with no recent observations may not have been monitored at all, or the monitoring scheduler may not have run, or the endpoint was not applicable to remote monitoring.
MCPServerStatus does not automatically treat missing observations as downtime. Possible causes of an observation gap include:
- Monitoring is not running for that endpoint.
- The endpoint was not enrolled as a monitoring target.
- The scheduler has a temporary observation gap.
- The endpoint is not applicable to remote monitoring.
For local stdio-only servers, remote monitoring is generally not available. This is not an error and should not be displayed as DOWN.
Status Pages vs Monitoring History
A status page communicates current state at a glance, while historical monitoring provides evidence about observed behavior over time.
Current status is useful for operational awareness — knowing whether an endpoint is currently observable as HEALTHY, DEGRADED, or DOWN. Historical monitoring shows patterns: how often an endpoint has been observed in each state, how quickly it recovers from transitions, and how latency has varied.
MCPServerStatus provides both: a status page for current state and detailed monitoring history for evidence-based analysis. Neither replaces the other; they serve complementary purposes in understanding MCP infrastructure.
What MCPServerStatus Status Data Can Establish
MCPServerStatus status data can establish observed facts about MCP endpoints based on actual monitoring checks.
Specifically, the platform can establish:
- Latest observed status (HEALTHY, DEGRADED, or DOWN)
- Observed connection result from the most recent check
- Observed handshake result from the most recent check
- Observed latency from the most recent check
- Observed status transitions over time
- Recorded incidents and their resolution timestamps
- Historical observations and status timeline
- Observed availability calculated from actual monitoring checks
These establish what was actually observed by the monitoring system, not what might be true in all circumstances or for all users.
What MCPServerStatus Status Data Cannot Establish
Status data alone cannot prove many important properties about MCP endpoints or their broader ecosystem.
MCPServerStatus status data cannot establish:
- Absence of vulnerabilities in the endpoint or its dependencies
- Absence of malicious behavior or backdoors
- Correctness of every tool, resource, or prompt provided by the endpoint
- Complete client compatibility across all MCP implementations
- Security of external systems the endpoint might interact with
- Behavior between monitoring observations (what happens when we are not checking)
- Guaranteed availability for every geographic region or network path
- SLA compliance unless an actual SLA measurement system exists and is integrated
For deeper analysis of security properties, see our MCP Server Security guide. For compatibility considerations, see our MCP Server Compatibility guide.