This MCP server lets you monitor the real-time operational status of 114+ cloud services and APIs right from your AI assistant.
Check a specific API (check_status): Look up a service's current status by its slug (e.g., github, openai, stripe).
List all monitored APIs (list_apis): Get the full list of supported APIs and their status.
List service categories (list_categories): Browse groupings like cloud or payments.
Check a category (check_category): Retrieve the status of all APIs within a given category slug.
Check any public URL (check_url): Verify the availability of arbitrary endpoints.
Allows checking the real-time operational status and availability of Cloudflare services.
Provides tools to check the current operational status and service availability for Datadog.
Enables real-time status monitoring and availability checks for GitHub services.
Allows checking the real-time operational status and availability of OpenAI's API and services.
Provides the ability to check the real-time status and operational availability of PagerDuty.
Allows monitoring the real-time operational status and availability of Shopify services.
Enables checking the current operational status and availability for Slack.
Allows checking the real-time operational status and availability of Stripe's payment services and APIs.
Provides tools for checking the real-time status and availability of Twilio's communication services.
Allows checking the operational status and availability of Vercel's hosting and edge platform.
Enables real-time status and availability monitoring for Zoom services.
An MCP (Model Context Protocol) server for checking real-time operational status of 285 cloud services and APIs directly from AI coding assistants.
Tool | Description |
| Check the status of a specific API (e.g. |
| List all monitored APIs and their current status |
| List available service categories (cloud, payments, etc.) |
| Check all APIs in a specific category |
| Check any public URL for availability |
Related MCP server: GetMonitor MCP Server
AWS, GitHub, Stripe, OpenAI, Vercel, Cloudflare, Datadog, PagerDuty, Twilio, Shopify, Slack, Zoom, and 270+ more. Full list at apistatuscheck.com.
The server is also hosted, so the fastest path is the remote Streamable HTTP
endpoint. This is the same entry the official MCP Registry advertises as
io.github.shibley/apistatuscheck.
claude mcp add --transport http apistatuscheck https://apistatuscheck.com/api/mcpFor stdio-only clients:
npx -y mcp-remote https://apistatuscheck.com/api/mcpnpx -y apistatuscheck-mcp-serverBroken on published version
0.1.0. That tarball'sdist/index.jsshipped without a#!/usr/bin/env nodeshebang, so the shim was executed byshinstead of Node and the command failed withcommand not found. Fixed in this repo (shebang added, plus anapistatuscheck-mcp-serverbin alias so the command matches the package name), but the fix is not on npm yet —0.1.1needs to be published. Until then, build from source:git clone https://github.com/shibley/apistatuscheck-mcp-server.git cd apistatuscheck-mcp-server && npm install && npm run build node dist/index.js
docker build -t apistatuscheck-mcp .
docker run -i apistatuscheck-mcpAdd to your claude_desktop_config.json. This points at the hosted endpoint —
do not use "args": ["-y", "apistatuscheck-mcp-server"], because the only version
on npm (0.1.0) is the broken one described above and fails silently.
{
"mcpServers": {
"apistatuscheck": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://apistatuscheck.com/api/mcp"]
}
}
}Same hosted endpoint via mcp-remote:
{
"mcpServers": {
"apistatuscheck": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://apistatuscheck.com/api/mcp"]
}
}
}Variable | Default | Description |
|
| Base URL for the API |
git clone https://github.com/shibley/apistatuscheck-mcp-server.git
cd apistatuscheck-mcp-server
npm install
npm run build
node dist/index.jsMIT — Bity LLC
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Category slug, e.g. 'cloud', 'payments'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | API slug, e.g. 'cloudflare', 'github', 'openai'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL to check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0check_categorycheck_statuscheck_urllist_apislist_categoriesScored across 5 tools
The tools have distinct purposes based on their names: checking categories, statuses, URLs, and listing APIs and categories. While 'check_category' and 'list_categories' might overlap slightly (both relate to categories), they appear to serve different functions (checking vs. listing), so ambiguity is minimal.
All tool names follow a consistent verb_noun pattern with 'check_' or 'list_' prefixes, using snake_case throughout. This makes the naming predictable and easy to understand, with no deviations in style.
With 5 tools, the count is well-scoped for an API status check server. It covers core operations like checking and listing without being overly sparse or bloated, fitting typical expectations for such a domain.
The tools cover checking and listing operations, but there are notable gaps for a full API status management system. For example, there are no tools for creating, updating, or deleting APIs or categories, which limits lifecycle coverage and could lead to dead ends in agent workflows.
Real-time status for 75+ AI services (OpenAI, Anthropic, Cursor). No auth, CORS-enabled.
Is GitHub, npm, Cloudflare or your AI provider down right now? 20 status pages, one call.
Real-time status & uptime monitoring for 294 popular APIs — is it down, and how reliable?
Live status and health checks for AI coding providers: Claude, Cursor, Copilot, Codex and more.
