API Status Check
रिमोट MCP सर्वर जो बताता है कि कोई API या क्लाउड सेवा अभी डाउन है या नहीं: कॉल के समय 280+ निगरानी वाली सेवाओं की जाँच करता है, वर्तमान में कौन-सी सेवाएँ डाउन या डिग्रेडेड हैं उनकी सूची देता है, और दर्ज अपटाइम इतिहास तथा विक्रेता द्वारा प्रकाशित घटनाएँ लौटाता है। रीड-ओनली, कोई ऑथ नहीं। एंडपॉइंट: https://apistatuscheck.com/api/mcp
होस्ट किया गया MCP सर्वर
npx add-mcp 'https://apistatuscheck.com/api/mcp'Claude Code, Codex, Cursor और अन्य में इंस्टॉल होता है
दस्तावेज़
API Status Check MCP Server
Let Claude, Cursor or any MCP client answer “is this API down right now?” with a real probe instead of a guess. Hosted, public, no API key, nothing to install.
Endpoint (streamable HTTP, POST)
https://apistatuscheck.com/api/mcp
Why an agent wants this
A model asked whether a provider is down has three bad options: answer from training data that predates the outage, fetch a status page written for humans and hedge, or say it cannot know. This server gives it a fourth — a call that returns up, degraded or down with a response time and a timestamp, across 285 APIs in 30 categories.
Setup
Claude Code
claude mcp add --transport http apistatuscheck https://apistatuscheck.com/api/mcp
Claude Desktop, Cursor, Windsurf and other config-file clients
{
"mcpServers": {
"apistatuscheck": {
"type": "http",
"url": "https://apistatuscheck.com/api/mcp"
}
}
}
Verify it from a terminal
curl -s -X POST https://apistatuscheck.com/api/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Claude connector (claude.ai)
The connector listed in Claude’s directory uses a smaller, chat-focused endpoint with two read-only tools. It needs no account and no authentication. To add it by hand, open Claude → Customize → Connectors → Add custom connector and paste:
https://apistatuscheck.com/api/mcp/claude
- check_service_status — reads a service’s own status page during the call and returns its overall state, affected components and active incidents. When a service publishes no readable status feed, it checks whether the service’s API endpoint responds instead and says so.
- list_recent_incidents — incidents the vendor published in the last 1–90 days (default 14), newest first. Reports
covered: falsewhen no incident record exists, which is not the same as zero incidents.
Both tools cover a fixed list of about 285 services and accept a name or a domain (“GitHub”, “stripe.com”). Results reflect what each vendor has acknowledged on its status page; a problem limited to one region, network or account may not appear there. We do not store your conversation or the service names you ask about — see the privacy policy. Questions: support.
Alert Pro
14-day free trial
The MCP server only answers when something asks it
Every tool on this page is pull-only: an agent has to be running, and someone has to think to ask. Alert Pro is the push half — pick up to 10 of the same 285 APIs and get an email within 60 seconds of one going down, whether or not anyone is at a prompt. $9/mo after the trial, card required to start, cancel anytime.
The MCP endpoint stays free and unauthenticated either way.
Tools
get_api_status Check an API right now
Probes the API endpoint at call time and returns up/degraded/down with a response time, alongside the last hourly monitor reading so an agent can see the two disagree instead of reporting a blip as an outage.
Arguments: slug
search_apis Search monitored APIs
Resolves a product name a user mentioned ("OpenAI", "payments") into the slug the other tools take. Matches on name, slug, category and description.
Arguments: query, limit?
list_apis List monitored APIs
The monitored catalog, optionally filtered by category. Statuses come from the most recent hourly run and carry a timestamp.
Arguments: category?, limit?
list_down_apis List APIs currently down or degraded
Everything the latest monitor run found unhealthy, across all categories. Returns monitorLastRun so an empty list can be told apart from a stale snapshot.
Arguments: —
get_uptime_history Get retained uptime history
Uptime percentage, response-time stats and raw data points over 24h, 7d or 30d. History is retained 30 days; a recently added API reads as null rather than a misleading 100%.
Arguments: slug, range?
get_incident_history Get a service’s published incident history
The incidents a vendor published on its own status page — start and end times, duration, severity, affected components and a link to the vendor’s incident page — newest first over 7d to all-time. Services with no public incident feed return covered:false rather than an empty list.
Arguments: service, window?, limit?
rank_reliability Rank vendors by reliability
Compare several services at once: incident count, total published downtime minutes, mean time to resolve and the longest incident over a window, ranked worst-first. This is the cross-vendor question a single vendor’s own monitoring tool cannot answer. Services with no archive are listed as uncovered instead of ranked as flawless.
Arguments: services[], window?
list_categories List API categories
The 30 category slugs and how many monitored APIs sit in each.
Arguments: —
Example response
get_api_status for openai. Note that errorMessage can be set on a healthy result: an authenticated endpoint answering 401 is proof it is reachable, which is the point of the probe.
{
"slug": "openai",
"name": "OpenAI",
"live": {
"status": "up",
"responseTimeMs": 89,
"checkedAt": "2026-08-01T18:34:26.261Z",
"errorMessage": "HTTP 401 (reachable)"
},
"monitor": {
"status": "up",
"description": "All Systems Operational",
"lastChecked": "2026-08-01T14:07:52.457Z"
},
"officialStatusPage": "https://status.openai.com",
"url": "https://apistatuscheck.com/openai"
}
Limits worth knowing before you rely on it
- One region, one probe.
get_api_statusis a single request from a single place. It is evidence, not consensus — compare it against themonitorfield in the same response before calling an outage. - An empty list is not an all-clear.
list_down_apisreturns nothing when the monitor snapshot is missing or stale as well as when everything is healthy. CheckmonitorLastRun. - History is 30 days. Recently added APIs return null uptime percentages rather than a flattering 100%.
- POST only. The transport is stateless streamable HTTP with JSON responses. GET and DELETE return 405; SSE-only clients will not connect.
FAQ
Do I need an API key to use the API Status Check MCP server?
No. The endpoint at https://apistatuscheck.com/api/mcp is public and unauthenticated. Add the URL to your MCP client and the eight tools are available immediately.
Is there anything to install?
No. This is a hosted remote MCP server over the streamable-HTTP transport, not an npm package. There is no local process, no Node version to match and nothing to keep updated — the tool list your agent sees is always the deployed one.
How is get_api_status different from the hourly monitor?
get_api_status makes a real outbound request when your agent calls it, so it reflects the moment of the question. list_apis and list_down_apis read the most recent hourly monitor run and carry a timestamp. get_api_status returns both values side by side, because a single probe from one region is weak evidence on its own.
Which APIs are covered?
The catalog is 285 APIs and developer platforms across 30 categories — AI providers, cloud, payments, communication, developer tools, databases, email and more. Call list_categories or search_apis to see what is monitored.
Does it support the SSE transport?
No. The endpoint is POST-only streamable HTTP with JSON responses; it is stateless so that it stays correct across serverless instances. GET and DELETE return a 405. Clients that require the older SSE transport will not connect.
Prefer plain REST? The same data is available without MCP — see the JSON API docs and the status badges.