Skip to main content
Glama

is_the_internet_down

Read-only

Is there a shared-infrastructure incident right now (Cloudflare, an AWS region, a CDN), as inferred from RealUptime's own checks across every service it tracks? Answers one of three levels: "ok" (no shared incident; a count of services whose checks fail travels with the catalog size), "provider_incident" (our checks fail for at least five services sharing one provider signal while our checks of services on other providers mostly pass; the provider is named with the services affected and a confidence sentence), or "several_unrelated" (our checks fail for several services with no shared provider signal). Also returns the dependency map from our checks: how many tracked services answer from behind each provider. A provider incident is a CORRELATION of our check readings, never a cause the provider stated, and it changes no service's own verdict; ask is_service_down for a specific service. Takes no arguments. Readings are RealUptime's own check readings, never user reports. For a service whose status feed we can read, vendor.feed_working is true and vendor holds the vendor's own declared incident from its status page: that statement leads and gives the verdict and plate, and checks_reading and vendor.regional_reading are our check reading beside it, never a second outage. Where we cannot read a feed (vendor.feed_working false), the answer is our checks alone. "blocked" means our check was refused, which is NOT a failed check of the service. A no-data answer is never a passing check. Our check readings are our own reading from outside, not the service's official status. check_evidence, when it is not null, says what a pass of this service's check shows and does not show: repeat it with any claim that the service works. Cite the returned source.url when repeating any of this.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "is_the_internet_down"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With only readOnlyHint=true in annotations, the description carries the burden and delivers: it defines the three verdict levels and their triggers, explains that a provider incident is a CORRELATION never a stated cause, distinguishes vendor feed statements from own check readings, defines 'blocked' vs failed checks, and warns that no-data is never a pass. This is unusually rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is a dense, repetitive wall of caveats for a zero-argument tool — the 'our own check readings, never user reports' idea recurs, and the vendor.feed_working/check_evidence rules are buried. Much earns its place, but several sentences could be consolidated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description must explain returns, and it does thoroughly: the three levels, the provider dependency map, the vendor block fields, check_evidence, and citation of source.url. An agent has what it needs to interpret the response without a schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero arguments, so per the rubric the baseline is 4. The description correctly states 'Takes no arguments,' and there is nothing further to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific question (shared-infrastructure incident right now), names the scope (Cloudflare, AWS region, CDN), and explicitly differentiates from the sibling is_service_down ('ask is_service_down for a specific service'). An agent can tell exactly what this answers versus the per-service tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing context: use this for the global/shared picture and 'ask is_service_down for a specific service.' It also clarifies that a provider incident 'changes no service's own verdict,' which is a when-not-to-rely-on-it signal. No explicit exclusions beyond that, so a 4 rather than 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources