Check if any website is down, from two continents, with uptime history and TLS expiry
Scored across 5 tools
check_site and site_history both surface current state and user-report counts, but the descriptions explicitly bound site_history to monitored sites and check_site to anything else, so misselection is unlikely. check_certificate, list_monitored_sites, and list_outages each target clearly distinct resources.
Four of five tools follow a verb_noun pattern (check_certificate, check_site, list_monitored_sites, list_outages). site_history drops the verb and uses noun_noun, a minor but noticeable deviation.
Five tools is well-scoped for a focused up/down monitoring service, with no redundancy and each tool covering a distinct facet (cert, live check, inventory, outages, history).
The read-only surface covers live checks, certificate expiry, monitored inventory, current outages, and historical uptime — essentially full lifecycle for this domain. Minor gap: no bulk/multi-domain check and no way to follow a non-monitored site's history over time.
Reads the HTTPS certificate of a public domain and reports days until expiry, the expiry date and the issuer.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain to inspect, e.g. "example.com". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and openWorld, and the description is consistent with them. It adds real context beyond the annotations by enumerating the returned values (days until expiry, expiry date, issuer), which matters since 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?
One sentence, front-loaded with the verb and resource, with no filler. Every clause 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 one-parameter, no-output-schema tool the description substitutes for the missing output schema by naming the returned fields. It does not mention failure behavior (e.g., unreachable domain or self-signed cert), which is a minor gap.
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 "domain" parameter, so the schema already carries the semantics. The description adds only the constraint that the domain must be public, which is a modest but genuine addition over the schema's example.
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 ("Reads the HTTPS certificate of a public domain") plus the exact outputs (days until expiry, expiry date, issuer). An agent can tell what it does without opening the schema. It does not, however, explicitly distinguish itself from the sibling check_site, which likely overlaps.
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 gives no when-to-use or when-not-to-use guidance and never names an alternative such as check_site. Usage is only implied by the name and the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live up/down check of any public website from an independent server (Singapore; Boston for sites that geo-block Singapore). Returns a one-sentence verdict plus status code, latency, resolved IP, redirect target, the view from the other region when available, and how many users reported problems in the last hour. Results are cached 30 s per domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain or URL to check, e.g. "github.com" or "https://www.reddit.com/r/all". Scheme, path, port and query are ignored; the host is checked as given. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent/open-world semantics, and the description adds substantial behavioral context beyond that: the independent server vantage points, the automatic Boston fallback for geo-blocked sites, the 30-second per-domain cache, and the user-report count. These are operationally relevant facts an agent could not infer from the 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?
Two sentences, front-loaded with the core action before the return-value inventory. The first sentence is dense but every clause carries information; it is slightly long rather than padded.
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 no output schema, the description compensates by enumerating what comes back (verdict, status code, latency, resolved IP, redirect target, other-region view, report count) and discloses the caching window. Nothing essential for correct invocation or interpretation 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 is 100%, so the schema itself already documents that scheme, path, port and query are ignored and the host is checked as given. The description adds no additional parameter meaning, so the 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 states a specific verb and resource (live up/down check of any public website) with explicit scope and vantage point (independent server, Singapore with Boston fallback). An agent can immediately distinguish this from siblings like site_history (historical) or list_outages (aggregate reports).
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 'live' framing and 'check any public website' context make the usage scenario clear, and the geo-block fallback signals the intended coverage. However, it never explicitly names when to prefer a sibling such as site_history for past incidents, so the routing guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 634 sites checked every 5 minutes, grouped in 17 categories. Without arguments returns the category list with counts; filter by category or a text query to get domains (at most 200 per call).
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Case-insensitive substring of the domain or display name, e.g. "bank" or "google". | |
| category | No | Category slug or name: social, streaming, ai, work, developer, shopping, finance, banks, gaming, telecom, government, education, messaging, news, travel, health, dating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, closed-world), but the description adds genuinely new behavior: the 5-minute check cadence and the hard cap of at most 200 domains per call. Those are real operational constraints the agent cannot infer 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?
Two dense sentences, front-loaded with the scale of the resource and immediately followed by the no-arg vs filtered behavior. Every clause carries information an agent would otherwise have to guess.
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 no output schema, the description does the correct work of describing both return shapes (category list with counts, domain lists). Minor omissions remain, such as whether query and category can be combined in one call, but nothing critical is missing for correct 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?
Schema description coverage is 100% and both parameters are well documented there, so the description adds little per-parameter meaning. Its only contribution is the 200-result cap, which relates to result size rather than argument syntax.
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 ('634 sites checked every 5 minutes, grouped in 17 categories') and gives the result shape, so the agent knows it is listing monitored sites rather than outages or certs. It never names a sibling to distinguish itself explicitly, which is the only gap.
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?
Explicitly explains the two invocation modes: no arguments yields the category list with counts, and filtering by category or text query yields domains. That is clear operational context, though it does not say when to prefer this over check_site or site_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the monitored sites (634 across 17 categories) that are confirmed down right now: two consecutive failed checks from their home region and no other region seeing them up in the last 15 minutes. Optional category filter.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Optional category slug or name: social, streaming, ai, work, developer, shopping, finance, banks, gaming, telecom, government, education, messaging, news, travel, health, dating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false). The description adds meaningful behavioral context beyond that: the exact confirmation criteria (two consecutive failed checks from home region, no other region seeing them up in last 15 minutes), which explains what 'down' means and how freshness is judged.
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?
A single dense sentence that front-loads the core purpose (sites confirmed down right now) and appends the filter note. Zero filler.
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 list tool with one optional parameter, the description covers purpose, scope, and the definition of 'down.' No output schema exists, but the return is self-evident (a list of monitored sites). Missing only potential return-shape or pagination notes.
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 schema itself enumerates the category slugs. The description only notes the filter is optional, adding no syntax or value details beyond the schema. 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?
Specific verb (Lists) plus resource (monitored sites that are confirmed down right now) and precise scope (634 across 17 categories, with region-based confirmation criteria). Distinguishes clearly from siblings like list_monitored_sites (which lists all sites) and check_site.
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?
States the tool's scope ('currently confirmed down') and mentions the optional category filter, giving clear context for when it applies. It doesn't explicitly name alternatives (e.g., list_monitored_sites for all sites), but the scope is well defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uptime percentage over 24 h and over the requested window (up to 7 days), the list of outages in that window, when the site was last seen down, the current state and user-report counts. Only for monitored sites (see list_monitored_sites); use check_site for anything else.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Window in days (1–7, default 7). | |
| domain | Yes | A monitored domain, e.g. "github.com". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the lower bar applies. The description still adds real operational context: this only works for monitored domains and the window is capped at 7 days, which tells the agent when calls will fail.
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?
A single dense sentence with no filler, and the return-value enumeration is front-loaded. The list of returned fields is slightly run-on, but every clause carries information.
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 no output schema, the description must enumerate return values, and it does so completely: uptime percentages, outage list, last-down timestamp, current state, and report counts. The monitored-site precondition is also stated, so the definition is self-sufficient.
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 1-7 day range and default, so the schema carries the parameter burden. The description reinforces the window semantics ('over 24 h and over the requested window') but adds no syntax or edge-case detail 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?
States a specific verb-and-resource combination plus the exact payload: uptime percentages, outage list, last-seen-down, current state, and user-report counts. It is clearly distinguishable from siblings like list_outages and check_site.
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?
Explicitly bounds usage: 'Only for monitored sites (see list_monitored_sites); use check_site for anything else.' This names both the precondition and the alternative tool, leaving nothing to inference.
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.
check_certificatecheck_sitelist_monitored_siteslist_outagessite_historyWebsite uptime monitoring: run checks from 300+ locations, manage monitors, alerts and incidents
Uptime monitoring: create and manage HTTP, API, SSL, ping, port and domain checks
DNS lookups, health reports, SSL certs, security scans, GEO scoring, uptime checks
Uptime monitoring for developers — monitors, incidents, heartbeats and status pages
