StatusCake MCP by usefulapi

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

Goes beyond the annotations by explaining the tool's operational semantics (the check goes down if not pinged within `period` seconds) and disclosing the return shape (data.new_id). With annotations only providing destructiveHint=true, the description usefully adds the key consequence and the follow-up workflow, though it doesn't cover auth or error behavior.

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 tightly packed sentences: purpose front-loaded, then the return value, then the underlying endpoint. Every sentence carries actionable information with no 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?

With no output schema, the description fills that gap by stating the return value (data.new_id) and pointing to the tool that yields the ping URL. Nothing an agent needs to invoke and follow up on this create 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?

Schema description coverage is 100%, so the baseline is 3; the description slightly exceeds it by reinforcing the meaning of `period` (the down-threshold in seconds) in conceptual terms. It does not add syntax or format detail beyond what the schema already provides for the other five parameters.

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 ('Create a heartbeat (push) check') and clarifies the mechanism (goes down if not pinged within period seconds). This distinguishes it cleanly from sibling creation tools like statuscake_create_uptime_check and statuscake_create_ssl_check without needing to open their schemas.

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?

Clearly scopes the tool to 'a cron job or worker' and routes the agent to the next step (statuscake_get_heartbeat_check for the ping URL). It stops short of stating when not to use it or contrasting it explicitly with the other create_* siblings, so it is clear context but not 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.

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

Annotations only supply destructiveHint=true, so the description must carry the rest, and it does: it discloses the actual effect (alert silencing), the non-obvious time handling (RFC3339 values read as local time in `timezone`), and an account-level feature gate. It stops short of covering repeat semantics or whether the window can later be edited/removed, but it adds substantially beyond the single annotation.

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 action and effect, then constraints, then the API mapping. Four short clauses, no filler, and the most decision-relevant facts (silencing behavior, timezone interpretation, tests-or-tags requirement) come first.

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 mutation with no output schema, the description covers the effect, prerequisites, timing semantics, and target scoping. Minor gaps remain: it does not indicate what is returned (e.g. an id for later get/update), nor whether repeat_interval has a default or whether omitted optional fields behave in any surprising way.

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 a 3 would be the baseline, but the description goes further: it clarifies that start_at/end_at only use the date and time component and are interpreted in `timezone`, and it supplies a cross-parameter requirement (tests and/or tags) that the schema does not express at all — neither field is in the required list.

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 ('Schedule a maintenance window') plus its functional effect ('silences alerts for the given uptime checks'). An agent can immediately distinguish this from the sibling read tools (get_maintenance_window, list_maintenance_windows) and the other create_* check tools.

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 a concrete selection constraint ('At least one of tests or tags is required') and a hard precondition ('Only works on accounts using the newer maintenance-windows feature'), which tells the agent when this call will fail. It does not explicitly name an alternative tool, but for a create operation among mostly read siblings the routing need is low.

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

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

With only destructiveHint=true in the annotations and no output schema, the description usefully discloses the return path ('Returns the new id as data.new_id'), which the structured fields do not. It still says nothing about permissions, alerting defaults, duplicate checks, or what the destructiveHint implies for an SSL check.

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 short sentences, front-loaded with the purpose, then the return value, then the API mapping. Nothing is padded and every line 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?

For a 12-parameter creation tool with no output schema, the description covers the essential missing piece (the new id location) and the schema covers parameters fully. Auth requirements and failure behavior are the only notable 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 coverage is 100%, so all 12 parameters including the required website_url/check_rate/alert_at trio are already documented in the schema. The description adds no parameter-level meaning beyond that, 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?

States a specific verb and resource ('Start monitoring a site's SSL certificate') and adds the underlying endpoint 'StatusCake: POST /ssl'. The SSL resource inherently separates it from the uptime/heartbeat create siblings, though it never names an alternative explicitly.

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 implied by the resource being monitored (SSL certificate expiry/problems), but there is no statement of when to pick this over statuscake_create_uptime_check or statuscake_create_heartbeat_check, 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.

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

With no output schema, calling out 'Returns the new check's id as data.new_id' adds real value about the response. It also flags plan-gated check rates and regions. However, it does not explain the destructiveHint creation semantics or the fact that many of the 29 params are conditionally relevant by test_type.

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 with the core action front-loaded and no padding. The trailing 'StatusCake: POST /uptime' is arguably internal detail but is cheap and confirms the creation endpoint.

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 29-parameter creation tool with no output schema, the description covers the return value and plan constraints reasonably. It does not clarify which parameters apply to which test_type, leaving a notable gap given the tool's complexity.

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 each parameter is already documented in the schema, including enums for check_rate and test_type. The description's 'URL, host or IP' loosely echoes website_url but adds no meaning beyond the schema, so the 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 states a concrete verb and resource: 'Start monitoring a URL, host or IP,' which is specific enough to be actionable. The tool name 'uptime_check' distinguishes it from the heartbeat and ssl sibling creators, though the description itself never explicitly names those alternatives.

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?

There is no explicit when-to-use guidance or comparison to sibling creators like statuscake_create_heartbeat_check or statuscake_create_ssl_check. The only usage-adjacent note is that 'faster check rates and some regions depend on the plan,' which is a constraint rather than guidance on choosing this tool.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying the returned fields (ping URL, period, status, last ping) and the underlying endpoint, though it does not cover error handling or authorization requirements.

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 with zero waste, front-loading the core operation before naming returned fields and the endpoint. Every element 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?

With no output schema, the description usefully names the key returned fields, which is enough for an agent to understand the response. It stops short of covering not-found behavior or authentication requirements, but is otherwise complete for a simple read operation.

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 test_id parameter is already documented in the schema. The description adds no additional parameter syntax or format details beyond what the schema provides, making the baseline 3 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?

States a specific verb (Fetch) and resource (one heartbeat check), lists the fields returned, and is clearly distinct from list_heartbeat_checks and other get_* checks by resource. An agent can identify the operation without opening the schema.

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 implies usage for retrieving a single heartbeat check in full, but it does not explicitly say when to use this versus list_heartbeat_checks or other lookup tools, nor does it state prerequisites.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is known. The description adds the HTTP endpoint (GET /maintenance-windows/{window_id}), which corroborates the read-only nature but discloses no further behavior such as error cases or what happens with an unknown id.

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 short sentences, zero waste, and the core purpose is front-loaded before the API path detail. Nothing to trim.

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 single-parameter read tool with no output schema, annotations carrying readOnlyHint, and a fully described parameter, the description covers purpose and identity adequately. It could mention the returned resource shape or error behavior, but that 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 description coverage is 100% and the single window_id parameter is fully documented in the schema. The description's 'by id' adds no syntax or format detail beyond what the schema already provides, 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?

States a specific verb and resource ('Fetch one maintenance window') plus a scoping qualifier ('by id'), which is enough to distinguish it from the sibling statuscake_list_maintenance_windows by inference. It stops short of naming the alternative explicitly, so it is clear but not fully differentiated.

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 'by id' phrasing implies the tool is used when a window_id is already known, but there is no explicit statement of when to prefer this over statuscake_list_maintenance_windows or what prerequisites apply. Usage is only implied.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower; the description adds real value by naming the fields the history returns (including the saved HAR file location), which matters because there is no output schema. It does not mention pagination behavior, but the schema already covers limit/before/links.next.

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 tight sentences that lead with the purpose and return content, followed by the endpoint mapping. Nothing is wasted, though the raw 'StatusCake: GET /pagespeed/{test_id}/history' is somewhat redundant with the stated purpose.

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 history tool with fully documented params and no output schema, the description supplies the missing return-field context and identifies the source endpoint. It stops short of noting pagination or that history may be empty, but nothing critical to calling it correctly is absent.

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 test_id, limit, after and before are all documented in the schema itself; the description adds no syntax or format detail for them. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('past runs of one pagespeed check') and enumerates the returned metrics (load time, file size, request count, throttling, HAR location). This cleanly distinguishes it from sibling statuscake_list_pagespeed_checks (lists checks) and statuscake_get_uptime_history (uptime history, not pagespeed).

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?

Implicit selection is clear from 'one pagespeed check' and the required test_id, so an agent can infer it is per-check history rather than a listing. However, there is no explicit when-to-use versus statuscake_get_uptime_history or statuscake_list_pagespeed_checks, and no stated prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by spelling out what the payload contains ('in full — expiry, issuer, cipher, scores, flags, mixed-content resources') and naming the underlying REST operation, but says nothing about error behavior or whether the result is live-cached.

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 front-loaded sentence with the return payload up front, plus a short trailing API reference. The 'StatusCake: GET /ssl/{test_id}.' clause lightly duplicates the schema path information but costs little and helps REST-oriented agents map the call.

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 usefully enumerates the returned fields, which is the main gap a single-resource getter has. For a one-required-param read tool with a readOnlyHint annotation, what remains missing (pagination is irrelevant; error/ownership semantics) is minor.

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 test_id is documented as 'The SSL check id.' The description only restates it as the {test_id} path segment in 'GET /ssl/{test_id}', adding no format or source guidance 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?

States a specific verb (Fetch) and resource (one SSL certificate check) and enumerates the contents returned (expiry, issuer, cipher, scores, flags, mixed-content resources). The scope word 'one' implicitly separates it from statuscake_list_ssl_checks, but no sibling is named explicitly.

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?

There is no statement of when to use this versus statuscake_list_ssl_checks or statuscake_get_uptime_check, and no prerequisites (e.g. whether the check must exist, or whether an id from a list call is required). Usage can only be inferred from 'one' in the first clause.

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

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

Annotations only declare readOnlyHint=true, so the description carries the rest of the burden and does add value: it discloses that the full record is returned, including current status, last test time, next location and the monitoring servers. With no output schema, this enumeration of the response contents is meaningful behavioral context rather than a restatement of 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?

Two compact sentences: the retrieval scope and returned fields lead, and the underlying endpoint (GET /uptime/{test_id}) trails as useful provenance. No filler and nothing buried.

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 partially compensates by naming the fields returned; with a single required param and a read-only annotation, an agent has what it needs to call this correctly. It stops short of describing error behavior (e.g. invalid or missing test_id), which is the only notable gap for an otherwise simple tool.

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?

Only one parameter and schema description coverage is 100% ('The uptime check id.'), so the schema already does the work. The description adds nothing beyond the {test_id} path template; baseline 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?

States a specific verb ('Fetch') and a singular, scoped resource ('one uptime check in full'), which cleanly separates it from statuscake_list_uptime_checks and from the history/periods siblings. It even enumerates the payload surface, so an agent knows exactly what this returns versus a list or history call.

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: you call this to get detail on a known test_id as opposed to listing all checks. There is no explicit when-to-use or when-not-to-use statement and no sibling is named as an alternative (e.g. get_uptime_history for trend data), so the agent must infer the routing from the tool name.

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

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

Annotations only declare readOnlyHint=true; the description adds the ordering guarantee (newest first) and the pagination mechanic (links.next / before), which an agent needs to traverse results. With no output schema, describing the returned fields is genuinely additive, though auth/rate-limit behavior is unstated.

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 resource identity and payload, followed by the paging instruction. No filler and no redundancy.

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 fully documented params and no output schema, the description covers the important extras (ordering, paging, payload fields). Only minor gaps remain, such as default page size behavior and the shape of links.next.

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 each of the four params is already documented, including the 'use with links.next' note on before. The description echoes that paging guidance without adding new syntax or format detail, so it sits at the high-coverage 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?

States a precise resource (individual test runs for one uptime check) and enumerates the payload fields (when, location, status code, response time ms), which separates it from config-oriented siblings like statuscake_get_uptime_check and aggregate siblings like statuscake_get_uptime_periods.

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 tells the agent how to page ('follow links.next (or pass before) to page back') but never states when to choose this tool over alternatives such as statuscake_get_uptime_periods. Usage is implied rather than contrasted.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the bar for added behavior is lower. The description contributes useful payload context (each period has start, end, duration in ms), but says nothing about ordering, pagination behavior across time, or result volume limits beyond what the schema states.

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 tight sentences, with the resource scoping and payload contents front-loaded before the API mapping. The trailing 'StatusCake: GET /uptime/{test_id}/periods.' is mildly redundant but cheap and useful for endpoint identification.

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 correctly compensates by naming the returned fields. For a simple read-only, single-resource lookup with fully documented params, this is nearly sufficient; only paging/ordering conventions are left unstated.

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 every parameter (after, before, limit, test_id) carries its own schema description, so the baseline of 3 applies. The description adds no parameter-level semantics such as time-window defaults or how before/after interact with paging.

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+resource ('the up and down periods of one uptime check') with the returned fields (start, end, duration in ms) and scopes it to a single test via the required test_id. The phrase 'The direct answer to "how long was it down?"' pins the intent, which separates it from the broader statuscake_get_uptime_history and statuscake_get_uptime_check siblings.

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 'how long was it down?' framing implies the intended usage scenario, but the description never states when to prefer this over statuscake_get_uptime_history or statuscake_get_uptime_check, and gives no exclusions or prerequisites. Usage is inferable but not directed.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lower. The description adds the backing endpoint (GET /contact-groups) and the shape of the alerting data returned, which is useful context, but it says nothing about pagination behavior 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 tight sentences, front-loaded with the verb and resource, followed by the practical payoff (the ids). No filler and nothing repeated from 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?

There is no output schema, so the description carries the burden of describing returns — and it does list the relevant fields of a contact group. Pagination specifics live in the schema, so the only gap is that it doesn't outline the overall response envelope.

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% — page (starts at 1) and limit (1-100, default 25) are both documented in the schema. The description adds no syntax or format detail beyond that, 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?

States a specific verb+resource ('List contact groups') and then defines what a contact group actually contains — alerting email addresses, mobile numbers, integration ids and ping URL. No sibling covers contact groups, so there is nothing to confuse it with, and the agent knows exactly what comes back.

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 tells the agent what to do with the result: 'Use their ids in a check's contact_groups.' That is clear context and an actionable next step. It stops short of explicit when-not guidance (e.g. paging vs. searching), but no obvious alternative tool exists for this resource.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results include status, period and ping URL, and cites the backing endpoint, but says nothing about pagination behavior, auth needs or rate limits — useful but not rich context 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?

Two tight sentences with the purpose front-loaded; the endpoint citation 'StatusCake: GET /heartbeat' is arguably internal detail but is compact. Nothing is padded or repeated.

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 no output schema, the description names the returned fields (status, period, ping URL) and defines the resource, and all parameters are schema-documented. It is nearly complete; only filtering/pagination nuance is left unexplained.

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 all six parameters (page, limit, tags, status, matchany, nouptime) are already fully documented in the schema. The description only names returned fields, not filter behavior, so it adds no meaningful parameter semantics beyond the structured data — the baseline 3.

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 gives a specific verb (List) plus resource (heartbeat/push checks) and even defines the concept — jobs that must ping a StatusCake URL within a period — so an agent understands what a heartbeat check is. It doesn't explicitly contrast itself with sibling listers like statuscake_list_uptime_checks, so the differentiation is only implicit in the resource name.

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?

There is no statement of when to use this tool versus alternatives such as statuscake_get_heartbeat_check for a single check, nor any note about prerequisites. Usage is only implied by the name and the 'List' verb, which is weak given the surrounding family of similar list/get pairs.

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

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

readOnlyHint=true already establishes safety, so the description's contribution is the account-feature restriction and the disclosure of what the records contain (start/end, timezone, repeat interval, state, covered checks/tags). It does not discuss pagination behavior or rate limits, which would have raised it further.

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 tight sentences: the resource definition and return fields come first, the account constraint second, and the API endpoint last. No filler and nothing repeated from the title or schema.

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 usefully enumerates the return fields and flags the feature-gate constraint, covering what an agent needs to call and interpret it. Pagination semantics live in the schema, but result ordering and total-count behavior are unaddressed.

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% with all three parameters (page, limit, state) documented and an enum on state, so the schema already carries parameter meaning. The description's mentions of "state" and coverage are about returned fields, not parameter usage, so it adds nothing 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+resource ("List maintenance windows"), plus a clarifying gloss ("scheduled alert silences") and an enumeration of the fields returned. This lets an agent distinguish it from statuscake_get_maintenance_window (singular fetch) without opening either schema.

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?

"Only works on accounts using the newer maintenance-windows feature" is an explicit eligibility precondition that prevents wasted calls on legacy accounts. It gives clear context but does not route the agent to alternatives (e.g., get_maintenance_window for a single window) or state exclusions beyond the feature-gate.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful context by naming the concrete fields returned (load time ms, page size kb, request count, latest issue), but says nothing about pagination behavior, result volume, or rate limits beyond the endpoint mapping.

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 purpose and field list, with the raw endpoint ("StatusCake: GET /pagespeed") appended as a compact mapping hint. Nothing is wasted or buried.

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 usefully compensates by enumerating the return fields. Combined with readOnly annotations and full schema coverage on the two pagination params, it is nearly complete, though pagination semantics and total-count behavior remain unstated.

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%: both `page` and `limit` are fully documented in the schema, including defaults and bounds. The description adds no parameter-level information, 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 gives a specific verb+resource ("List pagespeed checks") and enumerates the returned fields (location, alert thresholds, load time, page size, request count, latest issue), so the agent knows exactly what the tool returns. It does not, however, differentiate itself from close siblings such as statuscake_get_pagespeed_history or statuscake_list_pagespeed_locations.

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?

There is no statement of when to use this tool versus the sibling list/get tools, and no preconditions or exclusions are mentioned. The description is purely descriptive of content, leaving usage entirely to inference from the tool name.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the safety profile is covered. The description adds the concrete return contents (region, IPs, status), which is useful context, but it says nothing about whether the list is paginated, whether results are cached, or any auth requirement beyond the implicit token.

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 short clauses: purpose plus returned fields, then the underlying StatusCake endpoint. No filler, and the key information is front-loaded.

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 read-only list tool with a fully documented schema and a readOnlyHint annotation, the description is essentially complete. The only omissions are pagination behavior and explicit routing against the uptime-locations sibling, which are minor for this tool.

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 'location' parameter (ISO 3166-1 alpha-2 country code) is fully documented in the schema. The description adds no further parameter semantics, 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?

Specific verb ('List') plus resource ('pagespeed monitoring servers') plus the fields returned (region, IPs and status). It is clearly distinguished from the sibling statuscake_list_pagespeed_checks and from statuscake_list_uptime_locations, which covers a different check type.

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 implies this is a lookup of available monitoring regions, but it gives no explicit when-to-use guidance and does not mention the sibling statuscake_list_uptime_locations as the alternative for uptime servers. Usage is inferable from the name and content only.

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

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

readOnlyHint=true is consistent with a listing operation, so the safety profile is covered by annotations. The description goes beyond that by disclosing the returned payload content (validity window, issuer, cipher, score, expired/broken/revoked/mixed-content flags), which is genuinely useful since no output schema exists; it stops short of describing pagination behavior 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 tight sentences with the resource and its returned content front-loaded, followed by an endpoint mapping. Nothing is padded, though the endpoint reference adds limited value for an agent.

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 carries the burden of describing return values and does so reasonably well via the field list. It omits pagination metadata (e.g., total counts) and result ordering, which are minor gaps for a straightforward paginated list tool.

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?

Both parameters (page, limit) are fully documented in the schema at 100% coverage, including defaults and ranges, so the description need not repeat them. The description adds no additional parameter meaning, making the baseline 3 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 gives a specific verb and resource ('List SSL certificate checks') and enumerates what each record contains (validity window, issuer, cipher, score, status flags), so the agent knows exactly what comes back. It does not explicitly distinguish itself from the sibling statuscake_get_ssl_check, leaving the list-vs-single retrieval choice to inference from the names.

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?

There is no statement of when to use this tool versus statuscake_get_ssl_check (single check) or statuscake_create_ssl_check, and no preconditions or exclusions are given. Usage is only implied by the word 'List'.

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

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

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the API endpoint and return fields, which is useful context beyond annotations, but it does not disclose pagination behavior, authentication needs, 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?

The description is two tightly written sentences with zero waste. The core resource and scope are front-loaded, followed by the useful API endpoint reference.

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 naming the returned fields (when, status, status code). The input schema fully documents the parameters, including pagination hints, so the main remaining gap is that usage context and pagination response details are not explained in the description itself.

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 all four parameters are already well documented in the input schema. The description does not add syntax or meaning beyond what the schema provides, 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 states a specific resource — alerts triggered by one uptime check — and lists the returned fields (when, status changed to, status code). It is distinguishable from sibling tools like list_uptime_checks and get_uptime_history, though it does not explicitly name alternatives.

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 indicates the tool retrieves alerts for a single uptime check, implying its usage context. However, it offers no explicit when-to-use guidance, prerequisites, or comparison with sibling retrieval tools such as get_uptime_history or list_uptime_checks.

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

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

readOnlyHint=true already declares the safe-read profile, so the description doesn't need to re-establish that. It adds the StatusCake API mapping (GET /uptime) and confirms uptime percentages are computed, but says nothing about pagination defaults beyond what the schema documents or about cost of the uptime calculation. Some added context, but not rich.

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 returned-field list comes first, then the filter capability. The trailing 'StatusCake: GET /uptime' is the only borderline element, mildly redundant but cheap.

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 usefully enumerates the shape of each returned check, compensating for the missing return documentation. Pagination behavior (page/limit defaults) is left entirely to the schema, and there's no mention of result volume, but for a 6-param optional-filter list tool this is nearly complete.

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 baseline is 3. The description's 'Filter by status or tags' mirrors the status/tags schema entries without adding syntax, defaults, or interaction rules (e.g. how matchany pairs with tags, or the nouptime tradeoff) beyond what the schema already 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?

States a specific verb and resource ('List uptime checks') and then enumerates the returned fields (status, type, URL, check rate, tags, uptime percentage), which cleanly separates it from get_uptime_check and the ssl/heartbeat/pagespeed list tools. An agent knows exactly what this tool produces without opening the schema.

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 notes the filtering capability ('Filter by status or tags') which implies the intended browsing/filtering use case, but never states when to prefer this over statuscake_get_uptime_check or the other list_* siblings, and gives no exclusions. Usage is inferable rather than stated.

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

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

Annotations only declare readOnlyHint=true; the description adds the field-level shape of the response (region, region code, IPv4/IPv6, status) and the backing endpoint GET /uptime-locations. Since no output schema exists, this return-value disclosure is genuinely additive, though it omits any note on caching or stability of the location list.

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, with the resource scope and returned fields front-loaded before the practical usage notes.

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 carries the burden of return-value disclosure and does so by naming the returned fields, plus its usage and endpoint. It is nearly complete; only edge details like pagination or list size are absent, and those likely do not apply to a small static location set.

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 param's purpose is documented in the schema ('Only servers in this region code'). The description adds no syntax, valid-code list, or filter examples, 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?

Names a specific verb and resource ('List StatusCake's uptime monitoring servers') and enumerates the returned fields (region, region code, IPv4/IPv6, status). This clearly distinguishes it from the sibling statuscake_list_pagespeed_locations.

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 concrete downstream usage: 'Use region codes in a check's regions; use the IPs for firewall allowlists,' which tells the agent why and when to call it. It does not name an alternative tool or state an exclusion, so it falls short of a 5.

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

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

Annotations only supply destructiveHint=true, and the description goes well beyond that by disclosing the exact destructive nuance: list fields (tags, contact_groups, regions, dns_ips) are REPLACED and an empty list clears them. It also explains the paused toggle semantics, which is critical to avoid accidentally disabling alerting.

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 short sentences plus an endpoint reference, with the core partial-update rule front-loaded before the list-replacement warning. No filler or repetition of schema content.

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 29-parameter destructive mutation with no output schema and full schema coverage, the description covers the highest-risk behaviors (list replacement, pause toggle). It omits permissions/auth requirements and any indication of the response, which would be nice but is not essential here.

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 baseline is 3, but the description adds cross-parameter semantics the schema does not state—the replace-on-write behavior for regions and dns_ips (schema only mentions clearing for tags/contact_groups) and the pause/resume meaning of paused.

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 ("Change an uptime check's settings") and even names the underlying API call ("StatusCake: PUT /uptime/{test_id}"). The verb "Change" implicitly separates it from the create/get/list siblings, but no sibling is named explicitly, so it stops short of full differentiation.

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 operational context: only passed fields change, list fields are replaced wholesale, and paused=true/false toggles the check state. However, it never says when to prefer this over siblings (e.g. fetching the check first with statuscake_get_uptime_check) or any prerequisite/precondition for calling it.

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