Explore
Evidence for your next connection.
Independent measurements of remote MCP servers. Every observation has a timestamp.
Read-only probesMCP server · Monitoring & observability
Live status probes plus published uptime and incident history for 280+ APIs and cloud services.
1 failed · 7 not measured
Median of successful probes over 7 days
Share of countable probes over 30 days, including daily rollups. Auth challenges are excluded.
Tool definitions returned by this server
Independent monitoring
Responded
The server completed its last measured handshake. This is an observation, not a guarantee.
Last checked| Test area | Passed | Failed | Unmeasured |
|---|---|---|---|
ConnectionCan a client connect and discover tools? | 5 | 0 | 0 |
Reliability & speedDoes it respond consistently and quickly? | 1 | 0 | 3 |
Access & authenticationWhat is required to use this server? | 1 | 0 | 2 |
Tool qualityAre the tool definitions usable by an agent? | 3 | 1 | 0 |
Publisher identityCan the publisher be traced to its source? | 4 | 0 | 2 |
Unmeasured means there is not enough evidence to decide. How these checks work
Start using API Status Check
Choose your client, copy the configuration, then enable the server in your client’s MCP settings.
Run this command in your terminal, then restart Claude Code.
Claude Code
claude mcp add --transport http api-status-check https://apistatuscheck.com/api/mcpCapabilities
Probe a monitored API endpoint at call time and return up/degraded/down with the response time. This is the tool to reach for when a user asks "is X down?" — it makes a real request rather than reading the hourly cache.
DiscoveredReal incidents a vendor published on its own status page, newest first, with start/end times, duration, severity, affected components and a link to the vendor’s incident page. Use this for "has X been flaky lately?" — it is the vendor’s own record, not our probes. Services without a public Statuspage endpoint return covered:false rather than an empty list.
DiscoveredUptime percentages, response-time stats and recorded data points for one API over a time range. History is retained for 30 days; an API added recently will have few or no data points, which reads as null percentages rather than 100%.
DiscoveredList the APIs and developer platforms this service monitors, optionally filtered by category. Statuses come from the most recently published monitor snapshot, not a live probe, and can be up to a day old — check monitorCheckedAt, and call get_api_status when the caller needs the status right now.
DiscoveredCategory slugs and how many monitored APIs sit in each. Use the slugs with list_apis.
DiscoveredEverything the most recent monitor run found down or degraded, across all categories. Returns an empty list when the monitor snapshot is missing or stale — an empty list is therefore not proof that everything is healthy; check monitorLastRun.
DiscoveredGiven several service slugs, return a scorecard ranked worst-first: incident count, total downtime minutes, mean time to resolve, and the longest incident over a window. Use this to answer "which vendor in my stack is least reliable?" — it compares services across vendors, which a vendor’s own monitoring tool cannot. Services with no archive are listed separately as uncovered instead of being ranked as flawless.
DiscoveredFind monitored APIs by name, slug, category or description. Use this to resolve a product name the user mentioned into the slug the other tools take.
DiscoveredRecent measurements
| Checked | Result | Response | Tools |
|---|---|---|---|
| Connected | 483 ms | 8 | |
| Connected | 1132 ms | 8 |