UptyBots

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

Annotations declare openWorldHint=true and readOnlyHint=false, and the description appropriately explains the tool watches endpoints where the response matters but doesn't go into details like authentication requirements or rate limits. The description does add value by clarifying the semantics of what 'monitor' means here (response content matters, not just host availability), which goes beyond the annotations. However, it could have mentioned whether creation is idempotent or what happens on duplicate monitors, though the annotations cover idempotentHint=false.

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

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

Three sentences total. The first states the core purpose, the second gives concrete examples, and the third provides the pointer to the sibling tool. Every word 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?

Given the tool has only 5 simple parameters (all covered by schema), an output schema, and useful sibling tools, the description is complete. It explains the tool's purpose, gives usage guidance, and points to an alternative without unnecessary details about return values (since output schema exists) or parameter syntax (since schema covers them).

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 parameters are well-documented in the schema. The description adds conceptual context for the 'name' parameter ('Something recognisable months later beats the bare hostname') and clarifies the tool focuses on response content. While the description itself doesn't enumerate parameters, it works with the fully-covered schema to give complete semantic understanding. The description could have added more behavioral details about how parameters like frequency interact with monitoring behavior, but the schema covers the basics well.

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

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

The description clearly states this tool watches JSON/REST endpoints where the response content matters, distinguishing it from a plain page check. It names the specific use case (health endpoints, webhooks, APIs) and explicitly contrasts with create_http_monitor, making the purpose and differentiation clear.

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

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

The description explicitly says when to use this tool ('for health endpoints, webhooks and any API whose failure would be invisible to a plain page check') and provides a concrete alternative ('For an ordinary web page, create_http_monitor is lighter and enough'). This is a model example of usage 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 already indicate readOnlyHint=false (creates a resource), openWorldHint=true (external WHOIS dependency), and non-idempotent. The description adds context beyond annotations by explaining that WHOIS data is read externallyais and why this monitor is valuable (detecting expiry that uptime checks miss). It also implicitly warns about the WHOIS dependency without contradiction.

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 sentences, front-loaded with the purpose and a valuable differentiator. Every word contributes: the WHOIS source, the unique failure mode, and the explicit comparison to create_ssl_monitor. No redundant phrases or 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?

Given the tool's moderate complexity (3 params, output schema present, annotations covering read-only/destructive hints), the description covers all essential aspects: purpose, use case, differentiation from a sibling, and external behavior. The output schema handles return values, and the annotations cover safety profile, so the description is complete for agent 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?

The input schema provides 100% coverage with detailed descriptions for all three parameters (url, name, isActive). The description reinforces the meaning of 'url' by stating it reads WHOIS data, but adds no extra semantics beyond the schema's own descriptions. Since schema coverage is high, a baseline of 3 is appropriate; the description does not enrich parameter understanding further.

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

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

The description clearly states the tool's function: watching a domain registration and reporting time until expiry via WHOIS. It uses a specific verb-resource pair ('watch a domain registration') and immediately distinguishes itself from the sibling tool create_ssl_monitor by contrasting registration vs. certificate expiry. This avoids any ambiguity and makes the purpose unmistakable.

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

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

The description explicitly tells the agent when to use this tool ('catches the failure no uptime check can see') and provides a clear alternative: 'Distinct from create_ssl_monitor, which watches the certificate rather than the registration'. It also advises that both are worth watching, giving contextual rationale for choosing this over other monitor types.

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 indicate non-read-only, open-world, non-idempotent behavior. The description adds valuable behavioral context: checks run from probes in several countries, downtime semantics, and the duplicate-risk warning. It does not mention response details, but the output schema likely covers those and no annotation contradiction exists.

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, information-dense sentences, each earning its place. It tackles purpose, alternative selection, probe geography, and duplicate-avoidance without verbosity.

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?

Combined with a fully self-describing schema and output schema, the description gives a complete picture for a create tool: what it creates, when to use it, how to avoid duplicates, and the geographical context. It just misses a brief note on what the successful response contains, but that is largely available through the schema structure.

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 tool-level description does not add parameter-specific semantics beyond what the schema already provides. The url field description itself adds the bare-hostname exclusion, but that is not part of the main tool description.

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 uses a specific verb and resource: 'Watch a web page or endpoint over HTTP/HTTPS' and defines what counts as downtime ('unexpected status code, a timeout or a connection failure'). It also clearly distinguishes itself from create_api_monitor, its closest sibling.

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 explicit usage boundaries: 'This is the right type for anything a browser would open' and directs to create_api_monitor when the response body matters. It also tells the agent to call list_monitors first to avoid duplicates, a clear when-to-use prerequisite.

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 description goes beyond the annotation bounds by explaining the scope of what a ping reports (network reachability only), clarifying that a host can ping while a web server is down, and revealing that providers blocking ICMP cause monitors to show 'down'. These failure-behaviors are concrete and useful.

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

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

Three sentences deliver the core action, use cases, and limitations without redundant words. Each sentence adds distinct information, though the sentence listing use cases and the sentence on service status could be more tightly merged.

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

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

The description fully accounts around when to choose ping vs. other personal agents and identifies real-world failure modes. Since an output schema is present, the absence of response field details is acceptable; the description lacks only an explicit pointer to the service-monitor sub-tools.

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 input schema already covers all four parameters with rich, specific descriptions (e.g., URL no scheme/port, frequency range, name max length, isActive default). The tool description does not add new parameter-level semantics beyond the schema, so the baseline coverage score 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 opens with a specific action and resource: 'Watch a host with ICMP ping' plus the exact metrics reported (round-trip time, packet loss). It clearly differentiates from service-level by stating it only checks machine reachability, distinguishing it from HTTP, port, and API monitor 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?

It explicitly says when to use the tool: 'servers, routers and anything with no web service on top,' and warns that it reveals nothing about whether a hosted service is working. The ICMP-blocking provider caveat also sets correct expectations for when the monitor may misreport.

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 signal that this is a non-read-only, non-destructive operation, so the description doesn't need to repeat those. It adds valuable behavioral nuance: the monitor reports 'up' only when the service actually answers, and UDP behavior is clarified (only up when the server replies). This goes beyond what annotations or schema provide.

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

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

The description is three sentences, each earning its place: first the core purpose, second the concrete use cases, third the crucial port and UDP guidance. It is front-loaded and avoids 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?

Given the tool's complexity (5 params, 2 required, output schema present, sibling monitor tools), the description fully covers the essential context: what to monitor, when to use it, how to specify the target, and a key protocol setting. The output schema handles return values, and annotations cover safety, so no gaps remain.

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 schema already documents all parameters with 100% coverage, so a baseline of 3 applies. The description enhances the semantics by emphasizing that the port must be part of the URL and advising to set protocol to UDP for game servers, which directly aids correct usage of the 'url' and 'protocol' 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?

The description opens with a specific action: 'Watch one TCP or UDP port on a host and report it up only when the service behind it actually answers.' This clearly distinguishes the tool from HTTP or other monitor types by specifying the protocol and the 'actually answers' behavior, and it names concrete use cases like game servers and databases.

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

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

The description explicitly explains when to use this monitor: for non-HTTP services like Minecraft, Postgres, or SMTP. It also provides an exclusion ('rather than HTTP') and gives protocol-specific advice for UDP game servers. This goes beyond a general context statement and helps the agent choose between this and sibling monitor tools.

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?

Adds meaningful behavioral nuance beyond the annotations by explaining that the monitor carries two independent states (reachability and expiry), so a certificate can be nearly expired while the check still appears up. It does not contradict the readOnlyHint=false or openWorldHint annotations.

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

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

Three tight sentences, each earning its place: the core purpose, the distinction from HTTP monitoring, and a non-obvious behavioral caveat. No fluff 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?

The description is complete enough for a create tool with a full output schema and well-covered parameters. It explains the key conceptual caveat and provides usage context, though it does not mention prerequisites or post-creation effect details, which are partly covered by annotations.

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 input schema already provides full descriptions for all three parameters, so the description adds little parameter-level detail. It does give useful context about certificate-focused semantics, but that is not parameter-specific enough to raise the score above 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?

Describes exactly what the tool does: watches a TLS certificate for validity, issuer, and days to expiry. It clearly distinguishes itself from HTTP/site-reachability monitoring by explicitly scoping it to the certificate.

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?

Provides explicit guidance on when to use this tool versus an alternative: it is about the certificate, not site reachability, and recommends pairing with create_http_monitor when both aspects are needed. This is strong sibling differentiation.

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?

Goes beyond the destructiveHint annotation by detailing what is destroyed (entire check history, incidents, statistics), explicitly stating irreversibility and lack of trash, and adding a safety guideline to confirm. No contradiction with 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 sentences with no wasted words. All information is essential, front-loaded with the core purpose and then critical caveats.

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 destructive action, the description covers consequences, confirmation requirement, and alternative tool. With output schema present and only one fully-described parameter, it is 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?

The id parameter is fully described in the schema (with 'Monitor id to delete, as returned by list_monitors. Deletion is irreversible.'), and the tool description adds no additional parameter semantics beyond that. Baseline 3 for high schema coverage.

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

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

The description clearly states the tool 'Permanently delete a monitor' and specifies what is deleted (check history, incidents, statistics), distinguishing it from sibling tools like pause_monitor which only temporarily stop checking.

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 says to prefer pause_monitor when only temporary stopping is intended, and instructs to confirm with the user before calling, providing clear when-to-use and when-not-to-use 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 already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds behavioral value by disclosing the specific failure details returned, including probe attribution and error text, which goes beyond the structured annotations.

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

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

Three sentences, front-loaded with the core purpose, followed by concrete data points and a single useful redirect to a sibling tool. No filler or repetition of schema details.

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 two-parameter tool with an output schema and full annotation coverage, the description is complete: it explains what data is returned, when to use it, and what to use for complementary data. No meaningful gaps remain.

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 (monitorId and page) have clear descriptions. The tool description reinforces 'one monitor' but does not add meaning beyond the schema's parameter documentation, so 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?

The description states a specific verb and resource: 'Read the downtime history of one monitor', enumerating exact data returned (outage start/end, duration, HTTP status, error text, probe). It clearly distinguishes this from sibling tools by contrasting with get_stats_hourly.

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 frames when to use: 'This is the tool for "what happened" and "how often does this break"', and names the alternative for response-time shape: 'follow up with get_stats_hourly'. This gives clear decision 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 already declare it as read-only, idempotent, and non-destructive. The description adds behavioral context beyond annotations by detailing that it returns type-specific fields (HTTP status codes, port/protocol, expiry dates) that the list view omits, which is valuable for expected side effects on response content.

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 primary action and purpose, then provides usage context. No redundant phrasing or filler; every sentence earns its place.

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

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

Given the single parameter, rich annotations, and existence of an output schema, the description covers the purpose, usage context, and additional behavioral detail (type-specific fields) sufficiently. It does not need to explain return values because the output schema covers that.

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 only one parameter (id) with full schema description ('Monitor id, as returned by list_monitors.'). The description does not add further meaning beyond the schema, but since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description clearly states it reads a single monitor in full, including configuration, status, and type-specific details omitted by the list view. It distinguishes from list_monitors and other monitor tools by specifying exactly what extra information it returns.

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

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

The description explicitly says to use it after list_monitors when the answer depends on how the check is configured, giving concrete examples like timeout tightness or watched port. This provides clear when-to-use guidance and implies the alternative.

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 read-only, idempotent, and non-destructive. The description adds context about delivery outcome and whole-account scope, enriching the behavioral picture without contradicting annotations.

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

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

Three sentences, front-loaded with the primary action, then usage examples, then scope. Every sentence serves a purpose, with no filler or 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?

With an output schema present and strong annotations, the description covers purpose, use cases, and scope thoroughly. It doesn't need to repeat return details or safety hints. Complete for a read-only query 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 all parameters are documented. The description adds context (e.g., channels, delivery outcome) but doesn't significantly enhance parameter understanding beyond the schema. 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 clearly states it reads alerts sent by the account across all channels with delivery outcomes. It distinguishes from siblings by focusing on notifications rather than monitors, and explicitly says it covers the whole account, not one monitor.

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 gives explicit use cases: answering 'was I actually told about this outage' and finding silently failing channels. It also contrasts with monitor detection issues, implying when this tool is appropriate, and clarifies it is not monitor-specific.

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 this as a safe read/idempotent operation, and the description adds meaningful behavioral context: daily aggregation, the included metrics (min, max, average, p95), and the suggested zoom-in workflow with hourly stats. It does not discuss pagination, but the output schema and parameter descriptions partially cover operational details.

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 pack the core purpose, metrics, use case, and the relationship to the hourly tool with no filler. The most important 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?

Given the output schema exists, the complete parameter schema, and the strong usage guidance, the description is sufficient for an agent to select and invoke the tool correctly. It covers what the tool returns, when to use it, and how it relates to the sibling hourly 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 parameters are already well documented with defaults and types. The description adds context around date windows for reports/trends, but it does not add meaningfully new details for individual parameters beyond what the schema provides.

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

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

The description clearly states the tool aggregates response time and uptime per day with min, max, average, and p95, identifying the resource as monitor statistics. It also distinguishes itself from get_stats_hourly by specifying daily aggregation.

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

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

The description explicitly says this is the tool for reports and trends over weeks or months and for comparing monitors over the same window. It also gives a concrete exclusion: when a single day looks wrong, use get_stats_hourly instead.

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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which broadly cover safety. The description adds valuable behavioral context by explaining what the data can reveal (e.g., 'shape of a problem', outage clustering), which goes beyond the annotations. For a read-only analytics tool, this is sufficient transparency, though it doesn't detail pagination or row limits (which are partially covered by the schema and 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?

The description is a compact three sentences, front-loaded with the core purpose and metrics, then usage hints and alternative. Every sentence adds value, with no filler. It meets the standard of 'every sentence earns its place'.

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

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

Given the tool's moderate complexity (4 params, 1 required), full schema coverage, rich annotations, and an output schema, the description is complete. It covers purpose, usage scenarios, and alternatives, leaving no critical gaps for an agent to select and invoke the tool correctly.

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 4 parameters are documented in the schema. The description adds a high-level note about the time range ('hour' granularity, 'days' as best) but does not elaborate on parameter formats or interactions beyond the schema. 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?

The description uses a specific verb ('Get') and resource ('response time and uptime for one monitor broken down by hour'), clearly distinguishing it from siblings like get_stats_daily. It also enumerates the metrics (min, max, average, p95) and the time granularity, leaving no ambiguity about what the tool returns.

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

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

The description explicitly states when to use it ('Best over hours or days') and when not to ('for weeks and months use get_stats_daily instead'), naming the alternative tool. This is a model of clear usage guidance, providing both context and exclusion.

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 description enriches the annotations (readOnlyHint, idempotentHint) with non-obvious details: default page size (30), sorting (newest first), fields included (id, name, url, type, status, check frequency, uptime), and notably that an empty list is returned instead of an error when no monitors match. This goes well beyond what annotations convey.

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 three sentences long, each adding unique value: core function, entry field details, and usage guidance plus edge behavior. It's front-loaded with the primary purpose and wastes no words.

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 well-annotated parameters and a provided output schema, the description covers all necessary aspects: pagination, sorting, filtering capabilities, entry fields, and error behavior. It leaves no significant gaps for an agent to understand how to use the tool effectively.

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 input schema already documents all three parameters with clear descriptions and enums, giving 100% coverage. The description adds value by stating the default page size ('30 per page') and the empty-list behavior for no matches, which are not in the schema. However, these are minor additions relative to the schema's completeness.

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

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

The description clearly states the tool's purpose: 'List the monitors on the account, newest first, 30 per page.' It further distinguishes itself by noting the returned 'id needed by every other tool' and provides a concrete use case for the status filter. This makes it highly specific and separates it from sibling tools like get_monitor.

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

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

The description explicitly states when to use this tool: 'Start here when the request names a monitor by name rather than by id, and when asked what is broken - filtering by status "down" answers that in one call.' It provides clear contextual guidance, even though it doesn't mention alternatives by name. The 'start here' and specific use case give strong usage direction.

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 indicate readOnlyHint=false, destructive=false, and idempotent=true. The description adds that the monitor is not deleted, history/config survive, and it reports neither up nor down while paused. This enriches 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?

The description is concise, three sentences, each adding value: what it does, when to use it, and behavioral nuance. No fluff.

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

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

Given the tool's simplicity (one parameter), the description adequately covers purpose, usage, and behavior. The output schema exists, so return values are presumably covered there. It's complete enough.

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 schema fully describes the 'id' parameter (100% coverage) with a clear description. The tool description doesn't add much beyond that, but since schema coverage is high, 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?

The description clearly states it stops checking a monitor without deleting it, while preserving history and configuration. It distinguishes itself from delete_monitor and resume_monitor by explicitly mentioning these sibling 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?

It provides context for use around planned maintenance to avoid downtime affecting uptime figures or triggering alerts. It doesn't explicitly exclude other tools or state when not to use, but the context implies use cases. Sibling tools are listed, giving alternatives.

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?

Adds transparency beyond annotations by noting immediate check and safe on running monitor, consistent with idempotent and non-destructive hints.

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 concise sentences with no redundancy. Clear and well-structured.

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?

Covers the effect, immediate behavior, and safety. Does not mention error scenarios, but that's not critical for this simple 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 already fully describes the id parameter. Description adds no extra parameter details, so baseline score 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?

Clearly states the action: resumes a paused monitor and specifies immediate first check. Distinguishes from pause_monitor (sibling) implicitly.

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?

Provides guidance on safety when already running, but does not explicitly compare with alternatives or state when not to use. Still clear enough.

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