Is it down? Live status and outages of 259 cloud, AI and developer providers, from status pages.
Scored across 5 tools
get_provider (one provider's detail) and list_feed (cross-provider incident list) are clearly separated, and send_feedback is unmistakable. The only real overlap is report_affected vs report_outage, both writing to outages.live, but their descriptions sharply define when each applies (user says they're affected vs. user asks to report a broken provider).
All five names follow a clean verb_noun snake_case pattern: get_provider, list_feed, report_affected, report_outage, send_feedback. The verbs also semantically match the operation type (get/list for reads, report/send for writes).
Five tools is well-scoped for a read-mostly outage-status API with a thin write surface. Each tool covers a distinct capability with no filler.
Core lifecycle is covered: read a provider, browse incidents, mark affected, file a report, and give feedback. The one notable gap is a direct list-providers endpoint, though the get_provider description notes an unknown name returns every tracked id, so agents can work around it.
Get one provider (for example GitHub, AWS, Vercel, OpenAI): a one-line verdict on whether it reports a problem now, its active incidents, what people reported about it on outages.live in the last 24 hours (reviewed reports only, with a spike flag when many arrive in an hour), maintenance in progress, its last 10 incidents, and 90 days of daily history. Give region or component to keep only active incidents that name it, for example us-east-1 or Actions. Call it when a request to the provider fails, before you change code. An unknown name returns every tracked id.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Optional region to match, for example us-east-1 | |
| provider | Yes | Provider id or name, for example github, aws, Google Cloud, openai | |
| component | No | Optional component or product to match, for example Actions, S3, Chat Completions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, idempotent operation, so the description's burden is lower, but it adds substantial detail: it describes the one-line verdict, active incidents, reviewed reports from outages.live in the last 24 hours with spike flags, maintenance, last 10 incidents, and 90 days of history. It also discloses that an unknown name returns every tracked id and that region or component filtering applies only to active incidents.
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 front-loaded with the tool's core purpose and every sentence adds useful information, especially the return payload details needed because there is no output schema. The first sentence is long and dense, which slightly reduces readability, but there is little wasted wording.
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 read-only status lookup with no output schema, the description is complete: it explains what is returned, how region and component filters behave, when to call the tool, and what happens with an unknown provider name. The annotations already cover safety and idempotency, and nothing critical appears missing.
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%, so the baseline is 3, but the description adds meaningful semantics beyond the schema: region or component keeps only active incidents that name that region/component, with examples like us-east-1 and Actions. It also clarifies the special behavior for an unknown provider name.
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 opens with a specific verb and resource: 'Get one provider' and names concrete examples (GitHub, AWS, Vercel, OpenAI). It clearly distinguishes this status lookup from sibling tools such as list_feed, report_affected, report_outage, and send_feedback.
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?
It gives a clear usage trigger: 'Call it when a request to the provider fails, before you change code.' It does not explicitly state when not to use it or name sibling alternatives, so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List incidents across providers, the most recently updated first. By default only incidents that are open now. Narrow it with providers, category, and a minimum impact; set state to recent to add incidents resolved in the last days.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window for state recent | |
| limit | No | ||
| state | No | active: open now. recent: everything updated in the last days. | active |
| impact | No | Minimum impact: partial_outage keeps partial and major outages | |
| category | No | ||
| providers | No | Provider ids or names, for example github, vercel | |
| include_maintenance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavioral facts the annotations cannot convey: the implicit 'active only' filter and the most-recently-updated sort order. It does not disclose pagination behavior or what an incident record contains, which matters given there is no output schema.
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 sentences, zero filler, and the most decision-relevant facts — scope, default filter, narrowing options — are front-loaded. Each clause maps to an actionable choice the caller must make.
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 7-parameter, no-required-parameter list tool with no output schema, the description leaves two parameters (limit, include_maintenance) entirely unexplained and gives no sense of the return shape or result size. The core filtering story is complete, but these gaps mean an agent cannot call it fully informed.
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 only 57%, but the description compensates well: it explains 'state' (recent adds incidents resolved in the last days), 'impact' as a minimum threshold, and providers/category as narrowing filters. It leaves 'limit' and 'include_maintenance' completely unmentioned, and the interaction between 'state=recent' and 'days' is only hinted at ('the last days').
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?
States a specific verb and resource ('List incidents across providers') plus scope and ordering ('most recently updated first'), so an agent knows exactly what the call returns conceptually. It never names or contrasts a sibling such as get_provider or report_outage, so differentiation is inferred from the resource rather than stated.
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?
Gives clear default behavior ('By default only incidents that are open now') and explicit narrowing levers (providers, category, minimum impact) plus the switch to 'recent' to widen the window. It stops short of saying when NOT to use this tool or which sibling to prefer for single-provider lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell outages.live that an outage affects your user, as the "I'm affected" button on the outage page does. Call it only when your user says that the outage affects them, never on your own. Give the outage id that get_provider or list_feed returns. The count shows on the outage page at once, and each user counts once for each outage, so a second call changes nothing. Returns the new affected count.
| Name | Required | Description | Default |
|---|---|---|---|
| outage_id | Yes | The outage id from get_provider or list_feed, for example github-abc123 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the supplied annotations: it explains that the count appears immediately, that deduplication is per-user-per-outage so repeat calls are no-ops, and that the return value is the new affected count (important since there is no output schema). The dedup statement is consistent with idempotentHint=true rather than contradicting it.
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?
Four short sentences, front-loaded with the action, then the guardrail, then the input source, then the effect. No filler, no repetition of the title.
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 one-parameter mutation with no output schema, the description covers action, precondition, input provenance, idempotency, and return value. An agent has everything needed to call it correctly and to know when not to.
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% and the single parameter is fully documented in the schema, so the baseline is 3. The description adds genuine value by specifying provenance — the id comes from get_provider or list_feed — which the schema only partially states.
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?
Names a specific verb and resource ("Tell outages.live that an outage affects your user") and anchors it with a concrete UI analogue, the "I'm affected" button. An agent can immediately distinguish this from siblings like report_outage or send_feedback.
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?
Gives an explicit precondition ("only when your user says that the outage affects them, never on your own") plus the exclusion, and separately routes the agent to get_provider or list_feed as the source of the id. When-to-call and where-to-get-input are both covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report that a provider does not work for your user, as "Report an outage" on outages.live does, also when its status page shows no problem. Call it only when your user asks you to report it, never on your own. The outages.live team reviews each report, and only approved reports show on outages.live, in the API, and in get_provider. One report for each provider each hour.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | What does not work: api (an API or service), website (the website or dashboard), sign_in, or other | |
| note | No | Optional short note from your user about what they see, for example Pushes time out | |
| provider | Yes | Provider id or name, for example github, aws, openai |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (which only say this is a non-read-only, open-world write), the description discloses the moderation workflow: the outages.live team reviews each report and only approved reports surface on the site, in the API, and in get_provider. It also discloses a rate constraint of one report per provider per hour. That is substantive behavioral context that cannot be derived from structured fields.
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 purpose comes first, followed by the usage constraint, then the review and rate-limit behavior, so it is well front-loaded. The phrase 'as "Report an outage" on outages.live does' is slightly redundant with the title but does real work in grounding the semantics for an agent that knows the site.
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 three-parameter write tool with no output schema, the definition covers what the tool does, when it may be called, what happens afterwards (review and public visibility), and how often it may be called. The main residual gap is that it does not say what the immediate response looks like, e.g. whether a report id or pending status is returned.
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 provider, kind, and note are already fully documented with examples and an enum, which is the baseline of 3. The description adds only a loose scoping hint ('one report for each provider each hour') and says nothing extra about how to choose among kind values or what to put in note, though note's user-voice framing is already in the schema.
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 a specific verb and resource ('Report that a provider does not work for your user') and anchors it to the familiar 'Report an outage' feature on outages.live. It also clarifies an important edge case, that a report is valid even when the status page shows no problem. It stops short of naming the sibling report_affected, so the boundary with that tool is left for the agent to infer.
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?
It gives a strong, explicit trigger condition ('only when your user asks you to report it, never on your own'), which is exactly the guidance an agent needs for a write tool. It does not compare itself to sibling tools like report_affected or send_feedback, so the alternative-routing half of the guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send feedback to the outages.live team: a provider to add, data that looks wrong (a status that does not match the provider's own page, a missing or stale incident), or an idea. The team reads every message. Send only what the user agreed to share.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | missing_provider, wrong_data, idea, or other | |
| message | Yes | What to add, what looks wrong and where, or the idea | |
| provider | No | Optional provider the feedback is about, tracked or not, for example stripe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-destructive write, but the description adds meaningful behavior: the team reads every message and only user-approved content should be shared. It still does not describe confirmation, editability, or rate limits.
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 front-loaded sentences with no filler; the type list and consent constraint both contribute to correct invocation.
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 three-parameter feedback submission with full schema coverage and annotations, the description supplies purpose, content guidance, and a privacy constraint. It is nearly complete, though it omits what the agent should expect after sending.
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 the schema already defines kind, message, and provider. The description's feedback examples loosely map to the kind enum but add no syntax or constraints beyond the schema.
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 a specific verb and resource ('Send feedback to the outages.live team') and lists the feedback categories, so the agent can distinguish it from read-only siblings like get_provider and list_feed. It does not explicitly contrast with report_outage or report_affected, so sibling differentiation is incomplete.
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?
It gives concrete cases for using the tool (provider to add, wrong data, idea), but does not state when not to use it or name report_outage/report_affected as alternatives. Usage is therefore implied rather than fully guided.
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.
get_providerlist_feedreport_affectedreport_outagesend_feedbackLive status for 172 cloud and SaaS vendors from their official feeds. Is it you, or is it them?
Live status, incidents and maintenance windows for 8,000+ cloud and SaaS status pages.
Is GitHub, npm, Cloudflare or your AI provider down right now? 20 status pages, one call.
Live status probes plus published uptime and incident history for 280+ APIs and cloud services.
Add one secure layer between your agents and this server.
