StatusCraft is an MCP server that provides real-time status checks for 4066+ software services, pulling data from official status pages. It offers five tools:
get_status: Check the live status of a single service (e.g., GitHub, Stripe, OpenAI). Returns a normalized status (operational, degraded, partial_outage, major_outage, maintenance, unknown) plus structured incident details (name, impact, affected components, latest update) when non-operational.
get_all_status: Fetch the status of all 4066+ tracked services at once, grouped by status category. Results are cached for 60 seconds.
list_services: Browse all tracked services with their IDs and tags. Supports pagination (100 per page), name/ID search, and tag-based filtering (e.g., ai, payments, cloud, monitoring).
check_multiple: Check a specific list of services concurrently (e.g., ['github', 'stripe', 'openai']) — faster than checking each individually.
refresh_status: Force a live re-fetch bypassing the 60-second cache, for one service or all services — useful during active incidents or after an outage resolves.
MCP server that checks the live status of 3355 software services in real time. Ask your AI agent "is GitHub down?" or "what's wrong with Sentry?" — and get a live answer pulled directly from official status pages, including full incident detail when something is broken.
Install: npx -y github:jabbawocky/statuscraft (no API key needed)
Works with: Claude Desktop, Claude Code, Cursor, Windsurf, any MCP-compatible client
StatusCraft gives your AI client 5 tools that fetch live status from 3355 major services:
Tool | What it does |
| Check one service — returns normalized status + incident detail when non-operational |
| Check all 3355 services at once, grouped by status (cached 60s) |
| List all tracked services with IDs and tags — filter by category |
| Check a specific list of services in parallel |
| Force a live re-fetch, bypassing the 60s cache — useful during active incidents |
When a service is non-operational, StatusCraft automatically fetches the incidents API and returns structured detail alongside the status:
{
"id": "sentry",
"name": "Sentry",
"status": "degraded",
"description": "Partially Degraded Service",
"incident": {
"name": "Notification delivery",
"impact": "minor",
"status": "monitoring",
"started_at": "2026-06-11T09:50:38.604Z",
"latest_update": "Notifications delivery is now close to fully functional. Root cause identified as a cloud provider issue — monitoring closely.",
"affected_components": ["Notifications"]
},
"last_checked": "2026-06-11T13:20:00.000Z",
"source_url": "https://status.sentry.io"
}No extra latency when everything is green — the incident fetch only fires for non-operational services.
Related MCP server: API Status Check MCP Server
ID | Service |
| Anthropic |
| OpenAI |
| Google AI |
| Cohere |
| Replicate |
ID | Service |
| AWS |
| Azure |
| Google Cloud |
| DigitalOcean |
ID | Service |
| Vercel |
| Netlify |
| Render |
| Fly.io |
| Heroku |
| Railway |
ID | Service |
| GitHub |
| Postman |
| Clerk |
| LaunchDarkly |
| Linear |
| Atlassian |
| Jira Cloud |
| Confluence |
| Bitbucket |
ID | Service |
| Supabase |
| Neon |
| MongoDB Atlas |
| PlanetScale |
ID | Service |
| Stripe |
| Brex |
ID | Service |
| Slack |
| Discord |
| Twilio |
| SendGrid |
| Resend |
ID | Service |
| Datadog |
| Sentry |
| New Relic |
| Grafana Cloud |
| PagerDuty |
ID | Service |
| Segment |
| Amplitude |
| Mixpanel |
ID | Service |
| Cloudflare |
| Cloudinary |
ID | Service |
| Notion |
| Airtable |
| Zapier |
| HubSpot |
| Intercom |
| Shopify |
| Figma |
| Loom |
| Zoom |
| 1Password |
| Box |
| Dropbox |
ID | Service |
| Auth0 |
| Okta |
ID | Service |
| Asana |
| Miro |
| monday.com |
ID | Service |
| Webflow |
ID | Service |
| ActiveCampaign |
| Typeform |
ID | Service |
| Elastic Cloud |
ID | Service |
| Plaid |
ID | Service |
| Snyk |
ID | Service |
| Tailscale |
ID | Service |
| HashiCorp |
ID | Service |
| Snowflake |
ID | Service |
| Retool |
| Make |
ID | Service |
| Courier |
| Inngest |
ID | Service |
| Temporal Cloud |
ID | Service |
| Fivetran |
| dbt Cloud |
ID | Service |
| BrowserStack |
| Sauce Labs |
ID | Service |
| DocuSign |
ID | Service |
| Smartsheet |
| Shortcut |
| Productboard |
ID | Service |
| Coda |
ID | Service |
| Contentful |
ID | Service |
| Rollbar |
| Honeybadger |
ID | Service |
| incident.io |
ID | Service |
| Xero |
ID | Service |
| Iterable |
| Klaviyo |
| Mailgun |
| SparkPost |
ID | Service |
| Vanta |
| Drata |
| Secureframe |
ID | Service |
| LiveKit |
| Daily |
| Bandwidth |
| Plivo |
ID | Service |
| CircleCI |
| npm |
ID | Service |
| Twitch |
ID | Service |
| Heap |
| Hotjar |
| FullStory |
| LogRocket |
| Contentsquare |
| Appcues |
| Pendo |
ID | Service |
| Pinecone |
ID | Service |
| Mezmo |
| Sumo Logic |
ID | Service |
| Metabase |
ID | Service |
| Chargebee |
ID | Service |
| Salesloft |
| Gong |
| Clearbit |
| Close |
ID | Service |
| Help Scout |
| Talkdesk |
ID | Service |
| Teamwork |
ID | Service |
| JotForm |
| SurveyMonkey |
| Qualtrics |
ID | Service |
| Mode |
| Sisense |
| Hex |
ID | Service |
| Crowdin |
| Lokalise |
ID | Service |
| Mux |
| Bunny.net |
| Imgix |
ID | Service |
| Prismic |
ID | Service |
| Neo4j Aura |
ID | Service |
| Coveralls |
| HTML/CSS to Image |
| Rainforest QA |
| Applitools |
| Testsigma |
| Katalon |
| Bugfender |
ID | Service |
| Singular |
| Airbridge |
ID | Service |
| Mono |
| Tink |
| Yapily |
ID | Service |
| Leadfeeder |
| PhantomBuster |
| UpLead |
| BookYourData |
ID | Service |
| Dyspatch |
| Movable Ink |
| Beefree |
| Stripo |
ID | Service |
| Tyk Cloud |
ID | Service |
| Bitstamp |
| Crypto.com |
ID | Service |
| HelpDesk |
ID | Service |
| Torq |
ID | Service |
| Lumar |
ID | Service |
| Lightning AI |
ID | Service |
| StackOne |
ID | Service |
| Authzed |
ID | Service |
| Stan |
ID | Service |
| Cognigy |
ID | Service |
| Dremio Cloud |
ID | Service |
| Alation |
Add to your claude_desktop_config.json:
{
"mcpServers": {
"statuscraft": {
"command": "npx",
"args": ["-y", "github:jabbawocky/statuscraft"]
}
}
}claude mcp add statuscraft npx -- -y github:jabbawocky/statuscraftNo API key required.
"Is GitHub down right now?"
"Check the status of all my services"
"What's wrong with Sentry?"
"Are Stripe and SendGrid both operational?"
"Which AI services are having issues?"
"Show me all observability services"
"Check openai, anthropic, and github"
"Is Grafana Cloud having a major outage?"
"Is CircleCI down? What's the current incident?"
"Check Figma, Notion, and Loom status"
"Is Jira Cloud having issues?"
"Check Box and Dropbox"
"Is Okta down?"
"Check Asana, Miro, and monday.com"
Value | Meaning |
| All systems normal |
| Performance issues or minor disruption |
| Some features or regions affected |
| Widespread outage |
| Scheduled maintenance in progress |
| Could not reach status page |
Most services that run Statuspage expose a standard /api/v2/status.json endpoint — adding a new service is a 6-line entry in src/index.ts:
{
id: "myservice",
name: "My Service",
tags: ["hosting", "api"],
status_url: "https://status.myservice.com/api/v2/status.json",
page_url: "https://status.myservice.com",
type: "statuspage",
}Services using non-standard status pages (Azure RSS, AWS JSON, Slack, incident.io) use custom handler types already implemented in the codebase.
PRs welcome.
Node.js 18+
Claude Desktop or any MCP-compatible client
MIT
Check the live status of a specific list of services in parallel. Faster than calling get_status repeatedly.
| Name | Required | Description | Default |
|---|---|---|---|
| services | Yes | Array of service IDs to check (e.g. ['github', 'stripe', 'openai']). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. It discloses that checks are performed in parallel, which is a key behavioral trait. However, it does not mention any other important behaviors such as error handling, rate limits, or whether the tool is read-only (though checking status implies no mutation). The parallelism is a positive addition, but more context would be beneficial.
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?
The description is extremely concise: one sentence stating the purpose and a second sentence providing a usage benefit. Every word earns its place; there is no fluff or repetition. The key information is front-loaded.
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?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description is fairly complete. It explains what the tool does and its advantage. However, it lacks details on failure modes or output format, which might be needed for an agent to handle it correctly. Still, for a straightforward batch status check, it is adequate.
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?
Schema coverage for the single parameter 'services' is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema provides; it only repeats 'specific list of services'. No extra syntax, formatting, or constraints are described.
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?
The description clearly states the tool's action: 'Check the live status of a specific list of services in parallel.' It specifies the resource (live status of services), the verb (check), and the scope (specific list, in parallel). Additionally, it distinguishes from sibling tools by noting it is faster than calling get_status repeatedly.
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?
The description provides a usage guideline by comparing with get_status: 'Faster than calling get_status repeatedly.' This implies the tool should be used when checking multiple services instead of calling get_status individually. However, it does not explicitly exclude other siblings like get_all_status or list_services, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the live status of ALL tracked services at once. Returns a summary grouped by status — useful for a quick health check across the stack.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool checks 'live' status and returns a grouped summary, suggesting a read-only operation. While it does not explicitly state safety or side effects, the behavior is transparent and non-destructive.
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?
The description is two sentences long, front-loading the action and result in the first sentence. The second sentence adds a use case without any wasted words.
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?
Given no parameters or output schema, the description adequately covers the tool's purpose and output format. It is complete for a simple health check tool, though it could mention error handling or caching for higher completeness.
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?
The input schema has zero parameters, so schema coverage is 100%. Per guidelines, 0 parameters earns a baseline score of 4 since no parameter description is needed.
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?
The description clearly states the tool checks live status of all tracked services and returns a summary grouped by status. The use of 'ALL' in caps distinguishes it from sibling tools like get_status (single service) and check_multiple (likely multiple but not all).
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?
The description provides context by stating it is useful for a quick health check across the stack, implying it is for overall status rather than individual services. No explicit exclusions or alternatives are mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the live status of a specific service (e.g. 'github', 'openai', 'stripe'). Returns operational/degraded/partial_outage/major_outage/maintenance.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | Service ID or name (e.g. 'github', 'openai', 'stripe', 'cloudflare'). Use list_services to see all available IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses the return values (operational/degraded/partial_outage/major_outage/maintenance) and implies read-only behavior. It does not mention caching or authentication, but for a simple status check, this is sufficient.
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?
The description is a single sentence that immediately conveys the purpose, scope, and return values. No extraneous information, perfectly front-loaded.
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?
Given the tool's simplicity (one parameter, no output schema), the description covers the necessary aspects: what it does, what services it works with, and what it returns. It is complete and informative for agent selection and invocation.
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?
The schema description coverage is 100% with the parameter having a clear description including reference to 'list_services'. The tool description adds examples ('github', 'openai', 'stripe'), which provides additional clarity but does not significantly enhance the schema's inherent meaning. Baseline 3 applies.
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?
The description uses the verb 'Check' and specifies the resource 'live status of a specific service' with examples. It clearly distinguishes from siblings like 'check_multiple' (multiple services) and 'get_all_status' (all services).
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?
The description does not explicitly state when to use this tool versus alternatives. While the sibling names imply different use cases, no direct guidance is provided. There is a hint in the parameter description to use 'list_services' for service IDs, but that is parameter-level, not tool-level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List services tracked by StatusCraft, with their IDs and tags. Use this to discover service IDs for get_status. Supports name/ID search and tag filtering. Results are paginated (100 per page) — pass page to get more.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional name/ID search query. Filters services whose name or ID contains this string (case-insensitive). E.g. 'stripe', 'amazon', 'cloud'. Use this to find a service when you don't know its exact ID. | |
| filter_tag | No | Optional tag filter. E.g. 'ai', 'payments', 'hosting', 'monitoring', 'communication'. Returns only services matching this tag. | |
| page | No | Page number (1-based, default 1). Each page returns up to 100 services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses pagination (100 per page), search case-insensitivity, and tag filtering. Does not explicitly state read-only nature, but listing tools are implicitly read-only. Adequate transparency.
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?
Three short, focused sentences. Purpose is front-loaded. No redundant or extraneous content.
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?
Given detailed schema descriptions and no output schema, the description covers purpose, use case, search/pagination behavior, and provides usage context. Could mention if any default tag behavior or link to full tag list, but overall complete for a simple list tool.
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?
Schema description coverage is 100%, so schema already documents each parameter. Description adds overall context and examples (e.g., 'stripe', 'amazon') but does not significantly augment semantic meaning beyond what is in the schema. Baseline 3 is appropriate.
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?
Clearly states it lists services with IDs and tags, and explicitly differentiates by noting its role in discovering service IDs for get_status. Distinct from siblings like get_status which retrieves status for a given service.
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?
Provides a clear use case ('discover service IDs for get_status') and describes search, tag filtering, and pagination behavior. Could be more explicit about when not to use, but context is sufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force a fresh live fetch for one or all services, bypassing the 60-second cache. Use this when you need the absolute latest status — e.g. during an active incident or immediately after a known outage ends.
| Name | Required | Description | Default |
|---|---|---|---|
| service | No | Optional: service ID to refresh (e.g. 'github'). If omitted, refreshes all 3653 services. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cache bypass and the scope of refresh (one vs all 3653 services). It does not mention rate limits or authentication, but for a simple forced fetch, the disclosed behavior is sufficient.
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?
Two concise sentences. First sentence states the action and key behavior (cache bypass). Second provides usage guidance. No wasted words.
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?
For a simple tool with one optional parameter and no output schema, the description adequately covers purpose, usage, and parameter behavior. Could mention expected output format or that subsequent status checks reflect the update, but not essential.
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?
Schema coverage is 100% for the single parameter. Description adds value by providing an example ('github') and stating the default behavior (refreshes all 3653 services if omitted), which enhances understanding beyond the schema's 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?
Description explicitly states verb 'refresh' and resource 'services', and specifies action: 'Force a fresh live fetch for one or all services, bypassing the 60-second cache.' It clearly distinguishes from sibling tools like get_status (which likely uses cache) and check_multiple.
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?
Description provides context: 'Use this when you need the absolute latest status — e.g. during an active incident or immediately after a known outage ends.' This implies when to use, but does not explicitly state when not to use or name alternative tools for normal cached reads.
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. Dates show when Glama detected each change.
v2.78.0check_multipleget_all_statusget_statuslist_servicesrefresh_statusTools are mostly distinct. get_status, get_all_status, and check_multiple all retrieve statuses but with different scopes (single, all, custom list). Descriptions clarify the differences, though an agent might still confuse get_all_status and check_multiple.
Naming follows verb_noun pattern generally, but verbs are inconsistent (check, get, list, refresh). 'check_multiple' uses an adjective instead of a noun, breaking the pattern. Overall readable but not fully consistent.
5 tools is well-scoped for a service status checking server. Each tool serves a clear purpose without excess, covering listing, single/get-all/custom status checks, and cache refresh.
Covers core needs: discover services, fetch status (individual, all, custom list), and force refresh. Minor gaps like historical statuses or adding/removing services are absent but not critical for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Is GitHub, npm, Cloudflare or your AI provider down right now? 20 status pages, one call.
Real-time status for 75+ AI services (OpenAI, Anthropic, Cursor). No auth, CORS-enabled.
Check real-time uptime and incident status for 275+ APIs and cloud services.
Real-time status & uptime monitoring for 200+ popular APIs — is it down, and how reliable?
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jabbawocky/statuscraft'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
