Live cloud/SaaS outages, provider reliability and exploited CVEs from official status pages and CISA
Scored across 4 tools
The three deterministic tools have clearly distinct domains: incidents, reliability, and exploited vulnerabilities. The 'answer' tool overlaps with all of them, but its role as a fallback for free-form questions is explicit and the descriptions instruct agents to prefer deterministic tools, reducing ambiguity.
Names are all lowercase snake_case, but the pattern is mixed: 'answer' and 'list_active_incidents' use verbs, while 'exploited_vulnerabilities' and 'provider_reliability' are noun phrases. It is readable and not chaotic, but not a consistent verb_noun convention.
Four tools is a reasonable size for a niche outage-monitoring server. Each deterministic tool covers a core need and the LLM-based 'answer' fills gaps, though the server could arguably include a couple more specific status tools without feeling bloated.
The set covers active incidents, provider reliability, exploited vulnerabilities, and general Q&A, which addresses the main use cases for a live monitor. Missing features like scheduled maintenance or historical incident comparisons are workaround-able via the 'answer' tool, so there are no critical dead ends.
Ask a free-form question about the live monitor and get a cited answer. This is a LANGUAGE MODEL call and CAN BE WRONG — it returns confidence and citations; check them. Needs sign-in (connect to https://outage.me/mcp/pro) or an API key, and is quota-limited, so use the deterministic tools above when they can answer the question.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | The question, in natural language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description warns this is a LANGUAGE MODEL call that CAN BE WRONG and instructs checking `confidence` and `citations`. It also discloses auth requirements and quota limitations, adding real behavioral context annotations alone do not provide.
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 sentences with no filler: the core action, the critical caveat, and the usage conditions are all present. The most important behavioral warning is front-loaded, making it easy for an agent to parse quickly.
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 tool without an output schema, the description provides sufficient context: what it does, what it returns, why to trust-but-verify, and when not to use it. Nothing essential is 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 for the single parameter `q` is 100%, with the schema already stating it is a natural-language question. The description's 'free-form question' phrasing adds minimal extra meaning, so the baseline of 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?
The description states a specific verb ('Ask a free-form question'), a clear resource ('the outage.me analyst'), and the subject scope ('about the live monitor'). It also distinguishes itself from deterministic siblings by positioning itself as an open-ended, cited-answer tool.
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 explicitly tells agents when to prefer alternatives: 'use the deterministic tools above when they can answer the question.' It also discloses prerequisites (sign-in or API key) and quota limits, which is actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LIVE: CVEs being exploited in the wild (CISA KEV), ranked patch-first by CVSS × EPSS exploitation probability × known ransomware use, with CISA due date, patch availability and the factors behind each rank. Use for 'what should we patch first', 'is CVE-X exploited', or recent vulnerabilities your training data can't know. Deterministic: no model in the loop.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Optional. Max rows, default 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive. The description adds valuable context: data is LIVE, ranking is deterministic (no model in the loop), and it explains the ranking factors (CISA KEV, CVSS, EPSS, ransomware). This goes beyond the annotations.
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 tight sentences: what it does, when to use it, and a key behavioral note. Each sentence earns its place, and the main purpose is front-loaded with 'LIVE: CVEs being exploited...'.
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?
The description names the output fields (CISA due date, patch availability, ranking factors) and covers use cases. With no output schema, this gives enough context for an agent to understand the return shape, though it doesn't detail exact format or pagination behavior.
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 only parameter 'limit' is fully described in the input schema (coverage 100%), including default and range. The description does not add parameter details, but the schema is sufficient, so the baseline score of 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 explicitly states the tool lists actively exploited CVEs (CISA KEV) ranked by a specific formula (CVSS × EPSS × ransomware use), which is a distinct resource and purpose compared to siblings like list_active_incidents or provider_reliability.
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 lists three concrete use cases: 'what should we patch first', 'is CVE-X exploited', and recent vulnerabilities beyond training data. It does not explicitly name alternatives or exclusions, but the use cases are clear and sufficient for an agent to know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LIVE: cloud and SaaS incidents open right now (AWS, Azure, GCP, Cloudflare, GitHub, Stripe, …), quoted from each provider's own status page with a link, refreshed several times a day. Use for 'is X down', 'why is X failing', or anything after your training cutoff. Deterministic: no model in the loop. Prefer it over answer.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable context: data is quoted from provider status pages, refreshed several times a day, and deterministic with no model in the loop. This goes beyond the annotations by explaining the data source and freshness.
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 compact and front-loaded with the key fact (LIVE incidents), then provides source, refresh cadence, use cases, and a routing preference. Every sentence earns its place; no fluff.
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 zero-parameter, read-only tool with rich annotations, the description covers what it does, when to use it, how it's sourced, and how it differs from siblings. There's no output schema, but the description adequately conveys the return type (incident list with links). Nothing critical is 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?
The tool has zero parameters, so the schema is trivially complete. The description doesn't need to explain parameters; it instead explains what the tool returns (live incidents with links). Baseline 4 for zero params 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?
The description clearly states the tool lists live cloud/SaaS incidents from provider status pages, with specific providers named and a link. It distinguishes itself from siblings by emphasizing live status and provider quotes, and explicitly says to prefer it over `answer` for outage queries.
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 explicitly says when to use it: for 'is X down', 'why is X failing', or anything after training cutoff. It also names the alternative (`answer`) and says to prefer this tool over it, giving clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LIVE: reliability index, incident count and median recovery time per cloud/SaaS provider over the current window, from their official status pages. Use for 'how reliable is X' or 'which provider is more stable'. Deterministic: no model in the loop. Prefer it over answer.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | No | Optional. Filter to one provider by name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds meaningful context beyond them: 'LIVE' indicates freshness, 'from their official status pages' discloses provenance, and 'Deterministic: no model in the loop' assures the agent the result is computed, not generated. It stops short of a 5 because it doesn't mention failure modes such as unresponsive status pages or how the reliability index is scaled.
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 sentences with zero filler: the first delivers the core payload and freshness, the second gives usage triggers, and the third adds determinism plus sibling routing. The key metrics are front-loaded and every sentence earns its place.
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 (one optional param, no enums, no output schema), the description covers what is returned, the source, the time window, when to use it, and determinism. The only gaps are interpretive: the reliability index scale is not defined and no return shape is hinted, but with annotations carrying the safety profile and the tool being low-complexity, this is adequate with only minor omissions.
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 single optional `provider` parameter is already fully documented as 'Optional. Filter to one provider by name.' The description reinforces the per-provider scope ('per cloud/SaaS provider') but adds no format, casing, or accepted-value detail beyond the schema, so the high-coverage baseline of 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 names the exact resource (reliability index, incident count, median recovery time per cloud/SaaS provider) and the data source (official status pages), and scopes it to 'the current window.' It explicitly differentiates from siblings by declaring 'Prefer it over `answer`' and is clearly distinct from exploited_vulnerabilities and list_active_incidents.
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 explicit triggering conditions: 'Use for how reliable is X or which provider is more stable.' It also provides routing guidance against the sibling `answer`, telling the agent to prefer this tool for reliability queries, leaving no ambiguity about when to select it.
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.
answerexploited_vulnerabilitieslist_active_incidentsprovider_reliabilityLive status for 172 cloud and SaaS vendors from their official feeds. Is it you, or is it them?
Live status probes plus published uptime and incident history for 280+ APIs and cloud services.
Vendor status pages, TLS cert inspection, DNS propagation checks, and incident-response playbooks.
Is GitHub, npm, Cloudflare or your AI provider down right now? 20 status pages, one call.
Add one secure layer between your agents and this server.
