Is my broadband down? Live UK provider status and the last 30 days of outages
Scored across 3 tools
The three tools have clearly different scopes: history for past incidents, overview for a current all-provider snapshot, and provider status for detailed single-provider data. There is minor overlap between overview and provider status on current status, but the descriptions clarify that one is hub-wide and the other is provider-deep.
All tools follow a consistent get_<domain>_<aspect> snake_case pattern: get_outage_history, get_outage_overview, get_provider_outage_status. The verb and noun structure is predictable throughout.
Three tools are well matched to this narrow outage-lookup domain: one for history, one for a multi-provider overview, and one for per-provider detail. Each tool earns its place without redundancy or bloat.
The surface covers current status at both hub and provider level, plus 30-day history, which are the core operations for an outage lookup service. Minor gaps exist, such as no explicit tool for listing all tracked providers or querying by location, but these are largely workable through the overview.
Returns the outage incidents each provider's FindBroadband page lists, for the last 30 days, a shorter window or one day: current first, then newest first, with start and end times, places and the provider's own words, plus a count per provider when no provider is given. Covers the last 30 days only. Entries with source public_reports rest on public reports the provider never confirmed.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Only incidents that touched this UK calendar day, as YYYY-MM-DD. Must be within the last 30 days. Overrides days. | |
| days | No | How many days to look back, counting today, up to 30. Leave it out for everything we hold (the last 30 days). | |
| provider | No | Only incidents for this provider. Leave it out to search every provider we track. |
| Name | Required | Description |
|---|---|---|
| to | No | |
| days | No | |
| from | No | |
| note | Yes | |
| entries | Yes | |
| page_url | Yes | |
| provider | No | |
| truncated | Yes | |
| checked_at | Yes | |
| to_date_uk | No | |
| by_provider | No | |
| entry_count | Yes | |
| from_date_uk | No | |
| provider_name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety bar is low; the description nonetheless adds real behavior beyond them: result ordering, the roll-up count when no provider is supplied, and a provenance caveat that public_reports entries are unconfirmed by the provider. That last point materially affects how an agent should present results.
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 scope constraint is front-loaded, but the core is a single convoluted sentence with an awkward list ('a shorter window or one day') that is hard to parse. The line 'Covers the last 30 days only' repeats the window already stated and could be cut.
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 read tool with full schema coverage, annotations, and an output schema, the description supplies the ordering and the data-quality caveat an agent needs to answer correctly. Only the relationship to the two sibling tools 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 description coverage is 100%, including the date-overrides-days rule and the 1-30 day bound, so the baseline is 3. The description reinforces the 30-day cap but adds no parameter syntax or precedence detail the schema does not already carry.
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: returns outage incidents listed on each provider's FindBroadband page, with ordering (current first, then newest first) and the fields returned. It never names the sibling tools (get_outage_overview, get_provider_outage_status), so the boundary with those is left to inference.
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 30-day ceiling and the 'a shorter window or one day' phrasing imply when narrowing is appropriate, and the count-per-provider behavior hints at the unfiltered case. But there is no explicit statement of when to choose this over the overview or per-provider status tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current status of every UK broadband provider FindBroadband tracks (Down, Issues earlier or Working fine) in the outage hub's order, with the place where the provider named one, each affected provider's headline, the hub headline and a link to each provider's page. Down includes incidents limited to the places named.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| as_of | Yes | |
| stale | Yes | |
| hub_url | Yes | |
| as_of_uk | Yes | |
| headline | Yes | |
| providers | Yes | |
| checked_at | Yes | |
| down_count | Yes | |
| issues_earlier_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and closed-world behaviour, so the description only needed to add the non-obvious parts — and it does: result ordering follows 'the outage hub's order', and 'Down' is explicitly defined to include incidents limited to named places. That status-semantics definition is real value an agent could not get from the schema or 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?
It is a single sentence with the core action front-loaded and no filler, but it is a ~60-word run-on whose later clauses are hard to parse ('the place where the provider named one', 'each affected provider's headline, the hub headline') and would read better as a short list of returned fields.
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?
With an output schema present, the description does not need to enumerate return fields, and it correctly focuses on what the schema won't convey: ordering, provider coverage, and the inclusion rule for 'Down'. Nothing essential for a correct zero-argument call 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 takes zero parameters, so the baseline is 4; there is no parameter meaning for the description to add or omit.
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 and full scope: 'Returns the current status of every UK broadband provider FindBroadband tracks'. The word 'every' plus 'current' implicitly separates it from get_provider_outage_status (single provider) and get_outage_history (past data), though neither sibling is named, so an agent must infer the routing.
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 snapshot-of-all-providers framing implies when this tool fits, but there is no explicit 'use this when X, use get_provider_outage_status when Y' guidance and no stated exclusions. The alternative paths are inferable rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one UK broadband provider's outage status as its FindBroadband page shows it: the status and headline, current incidents and the latest past ones in the provider's own words with the places they named, a day by day picture of the last 30 days and links. status_based_on says whether the status comes from the provider's own status page or from public reports, which the provider hasn't confirmed. The status covers home broadband; scope_note, when present, says where the provider's mobile network or TV status is.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | The broadband provider the user means, as they said it (e.g. 'BT', 'Virgin Media', 'zen'). Free text is fine. |
| Name | Required | Description |
|---|---|---|
| as_of | Yes | |
| place | No | |
| detail | Yes | |
| status | Yes | |
| as_of_uk | Yes | |
| headline | Yes | |
| page_url | Yes | |
| provider | Yes | |
| checked_at | Yes | |
| down_since | No | |
| scope_note | No | |
| last_30_days | Yes | |
| down_since_uk | No | |
| provider_name | Yes | |
| past_incidents | Yes | |
| status_based_on | Yes | |
| current_incidents | Yes | |
| past_incident_count | Yes | |
| provider_status_page | No | |
| current_incident_count | Yes | |
| shares_status_page_with | No | |
| provider_status_page_needs | No | |
| current_incidents_truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive), so the description's job is added context, and it delivers: it discloses data provenance ('as its FindBroadband page shows it'), the reliability caveat that status_based_on may reflect unconfirmed public reports rather than the provider's own page, and the scope limit to home broadband with scope_note for mobile/TV.
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?
Front-loaded with the return content, and the two trailing caveats (status_based_on and scope_note) each add real decision-relevant meaning. It is a single dense sentence, though, and the enumeration of returned elements runs long enough to be slightly harder to parse than needed.
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 lookup with an output schema, the description covers the important non-structural facts: provenance, confirmation status of the status, and the mobile/TV scope boundary. Pagination and error behavior for an unknown provider are unaddressed but are minor for this tool type.
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?
There is a single parameter with 100% schema description coverage, including examples and the note that free text is fine, so the schema carries the meaning. The description adds nothing about how 'provider' is interpreted or matched, which keeps this at the baseline.
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 a specific verb and resource ('Returns one UK broadband provider's outage status') and pins the data source ('as its FindBroadband page shows it'). It implicitly scopes to a single provider, which separates it from the overview/history siblings, but it never names those siblings to make the distinction explicit.
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?
Usage is only implied: an agent can infer this is the tool for 'is provider X down right now', but there is no statement of when to prefer get_outage_overview or get_outage_history, and no prerequisites or exclusions are given.
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_provider_outage_status1 field changedOutput schema / properties / scope_noteAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "link_label": {
+ "type": "string"
+ },
+ "link_url": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text"
+ ],
+ "type": "object"
+}get_outage_historyget_outage_overviewget_provider_outage_statusIs a service down right now? Live status, incidents and component health from official pages
Is it down? Live status and outages of 259 cloud, AI and developer providers, from status pages.
Live service status, active incidents, search, and outage history from Downtester.
Live status for 172 cloud and SaaS vendors from their official feeds. Is it you, or is it them?
Add one secure layer between your agents and this server.
