API Status Check

Remote MCP server that answers whether an API or cloud service is down right now: probes 280+ monitored services at call time, lists what is currently down or degraded, and returns recorded uptime history and vendor-published incidents. Read-only, no auth. Endpoint: https://apistatuscheck.com/api/mcp

Hosted MCP Server

npx add-mcp 'https://apistatuscheck.com/api/mcp'

Installs into Claude Code, Codex, Cursor and more

Documentation

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: false when 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_status is a single request from a single place. It is evidence, not consensus — compare it against the monitor field in the same response before calling an outage.
  • An empty list is not an all-clear. list_down_apis returns nothing when the monitor snapshot is missing or stale as well as when everything is healthy. Check monitorLastRun.
  • 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.