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

Annotations already indicate non-read-only, non-idempotent, and non-destructive behavior. The description does not add extra context about side effects like authentication or rate limits, but it remains consistent with the annotations and adequately conveys the action of creating a monitor.

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, consisting of two sentences that efficiently convey the purpose and usage context. It is well-structured and free of 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?

The description covers the core functionality and usage scenarios adequately. While it does not mention the output or return value, the tool's simplicity and the presence of an output schema (even if not shown) reduce the need for such explanation.

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 full descriptions for all five parameters, covering the essential semantics. The tool description itself does not add further parameter-specific details, so it stays at the baseline for well-covered schemas.

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: to monitor JSON or REST endpoints where response content matters. It also distinguishes it from the simpler HTTP monitor, making the intent unambiguous.

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 specifies when to use this tool (health endpoints, webhooks, APIs with content-dependent failures) and when not to use it (plain web pages, where the lighter HTTP monitor suffices). This gives clear guidance on alternative choices.

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 adds meaningful behavioral context beyond annotations by disclosing the WHOIS data source and the registration-vs-certificate distinction. It aligns with readOnlyHint=false (creating a monitor) and does not contradict annotations, though it doesn't detail side effects beyond creating the monitor.

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, front-loaded with the central purpose, and every sentence earns its place: it states the function, explains the unique value, and distinguishes from the closest sibling. No wasted 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?

Given the presence of a full input schema, output schema, and annotations, the description provides sufficient context for selecting the tool and understanding its domain. It could mention the alerting/expiry threshold behavior, but that is not essential for correct invocation.

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

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

The input schema provides 100% coverage with descriptive parameter documentation, so the description doesn't need to add param-specific details. It adds no extra parameter semantics beyond what the schema already supplies, justifying the baseline score.

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 ('watch') and resource ('domain registration'), explicitly states it reads from WHOIS, and clearly distinguishes it from create_ssl_monitor by contrasting registration vs certificate expiry.

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 explicit guidance on when to use this tool: to monitor domain registration expiry, and explicitly names the alternative (create_ssl_monitor) with a clear rationale for why both may be needed. It also explains why uptime checks are insufficient.

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 non-read-only and non-idempotent, and the description adds context: checks run from probes in several countries, what counts as downtime (unexpected status code, timeout, connection failure), and the risk of duplicates. This goes beyond the structured annotations without contradicting them.

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, front-loaded with the core purpose, followed by sibling differentiation and operational context. Every sentence earns its place with 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?

The description covers the tool's purpose, key alternative, operational details (geographic probes), and a pre-check step. Output schema exists, so return values are covered there. It does not exhaustively discuss all sibling tools, but it's complete enough for correct invocation.

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

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

Input schema coverage is 100%, with all parameters described. The description adds context about general behavior (e.g., 'anything a browser would open') but does not provide parameter-specific meaning beyond what the schema already documents. 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 the tool's function: 'Watch a web page or endpoint over HTTP/HTTPS and treat an unexpected status code, a timeout or a connection failure as downtime.' It also distinguishes from siblings by explicitly naming create_api_monitor as the alternative when response body matters, and the URL schema note references create_ping_monitor for bare hostnames.

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 provides explicit when-to-use guidance: 'This is the right type for anything a browser would open' and 'Choose create_api_monitor instead when the response body matters as well as the status code.' It also instructs to call list_monitors first to avoid duplicate URLs, giving a clear 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?

Discloses that the monitor uses ICMP, reports network-level metrics, and will show as down if ICMP is blocked, providing clear expectations about what the monitor does and its limitations.

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, concise, and places the primary purpose first, with usage guidance and caveats following.

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 simple tool and fully described schema, the description covers purpose, usage, and limitations, making it complete for an agent to decide when and how to use it.

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 descriptions already cover the parameters (url, name, isActive, frequency). The tool description does not add specific parameter-level semantics beyond the overall context, so it does not exceed the baseline 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?

Clearly states the tool creates a ping monitor for a host using ICMP, reports round-trip time and packet loss, and distinguishes from HTTP monitors by noting it doesn't check services.

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 states when to use (for servers, routers, anything without a web service) and warns about ICMP blocking, which helps decide between ping and 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?

Adds behavioral detail beyond annotations: the monitor only reports 'up' when the service actually answers, and UDP requires a real reply. This clarifies success semantics that the schema doesn't convey. Annotations are minimal (e.g., readOnlyHint=false implicitly write), so the description adds meaningful context.

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 behavior and then concrete examples. No wasted words, though the third sentence could be seen as slightly redundant with the schema's protocol description, but it reinforces a common pitfall.

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 2-required-param tool with a well-documented schema and an output schema present, the description covers the essential behavioral context and protocol nuances. It doesn't mention failure modes or pagination, but those are not critical for a creation endpoint.

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 documents all parameters with useful descriptions (url format, name length, protocol default). The description adds extra real-world guidance on choosing UDP for game servers and reiterates the port requirement, complementing but not duplicating schema.

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

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

Description uses a specific verb ('watch') with a clear resource ('one TCP/UDP port') and explicitly differentiates from HTTP monitors by stating it's for game servers, databases, mail, etc. The examples (Minecraft, Rust, CS2) make it unmistakable what this tool does.

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 context for when to use this monitor type ('rather than HTTP') and why UDP is needed for game servers. It doesn't name sibling tools, but the clear distinction and protocol guidance make the intended scope obvious.

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 this is not read-only (readOnlyHint=false) and not destructive, so the description need not repeat those. It adds value by disclosing that the monitor has two independent states (reachability and expiry) and that the check can read 'up' while the certificate is expiring. While this is useful, it does not fully detail all behavioral aspects (e.g., alerting), but given annotations cover the safety profile, this is well above baseline.

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 single paragraph of two sentences, directly conveying the purpose, scope, and a key behavioral nuance. Every sentence adds value, 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?

Given the annotations (readOnlyHint=false, destructiveHint=false) and the rich output schema (not shown but indicated as present), the description covers the essential conceptual nuance (certificate vs reachability) that is not evident from the schema. It is complete for the tool's scope and context, as the output schema handles return value details.

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

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

Schema coverage is 100%, so the description does not need to explain parameters individually. It does not add extra meaning beyond the schema, but the schema already provides clear descriptions for url, name, and isActive. Therefore, a score of 3 is appropriate as the description does not repeat parameter details.

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 precisely that the tool creates a monitor that watches a TLS certificate's validity, issuer, and days to expiry. It distinguishes its scope from site reachability and explicitly names the sibling tool create_http_monitor for that complementary purpose.

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 clear guidance: use this for certificate-focused monitoring reliable, and pair it with create_http_monitor when both certificate and site reachability are needed. This explicitly states when to use and when not to use, directly addressing the sibling comparison.

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?

Beyond annotations (destructiveHint=true), the description explains the full scope of destruction: entire check history, incidents, and statistics, and emphasizes irreversibility with 'no trash to restore from.' It adds meaningful behavioral context about data wipe and confirmation requirement, exceeding 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?

Three sentences, each earning its place: a clear action statement, an irreversibility warning, and a usage guideline. Front-loaded with the core action, 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?

Given the simple single-parameter schema with 100% coverage and an existing output schema, the description fully covers all essential contextual aspects: purpose, consequences, alternatives, and user confirmation. Nothing else is needed for careful use.

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 a full description for the only parameter, including the id, source (list_monitors), and irreversibility. The description adds no additional parameter-level detail, so the baseline of 3 applies (schema coverage is 100%).

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 precisely what the tool does: permanently delete a monitor, including its history, incidents, and statistics. It clearly distinguishes from siblings by noting the preference for pause_monitor when only temporary suspension is needed.

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: confirm with the user before calling, and prefer pause_monitor for temporary stopping. This gives clear when-to-use and when-not-to-use instructions, naming the alternative 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 and destructiveHint=false, and the description adds meaningful behavioral context: the kinds of failure details returned and the relationship to surrounding stats. No pagination behavior is disclosed, but the output schema covers return shape, so the additional context is sufficient.

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 focused sentences with no filler. The opening sentence states the core purpose, the second gives common use cases, and the third targets a specific follow-up tool. 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?

For a read-only incidents/history tool with rich annotations, a fully self-describing schema (100% parameter coverage), and an output schema, this description is complete. It covers what the tool returns, when to use it, and how it relates to get_stats_hourly.

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 clear descriptions for both monitorId and page including defaults and references to list_monitors. The description adds no additional parameter-level detail, but the baseline of 3 applies because the schema already carries the full semantic burden.

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-resource pair ('Read the downtime history of one monitor') and enumerates the concrete data included (start/end times, duration, HTTP status, error text, probe). This clearly distinguishes it from siblings like get_stats_hourly and 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?

It explicitly states when to use the tool ('This is the tool for "what happened" and "how often does this break"') and gives a specific follow-up direction to get_stats_hourly for response-time shapes. It does not explicitly mention alternatives like get_monitor for current status, so it misses the 'when not to use' edge.

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 the tool is read-only and idempotent, so the description does not need to repeat safety guarantees. It adds meaningful behavioral context by describing what 'full' means and the type-specific fields the list view omits, going beyond the annotation baseline.

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 core purpose and then adding usage guidance and type-specific detail examples. Every clause earns its place with no fluff or repetition.

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 one well-documented parameter, strong annotations, and an output schema, the description sufficiently covers what makes this tool valuable and when to invoke it. It does not need to explain return values because the output schema exists.

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 fully documents the single parameter 'id' as 'Monitor id, as returned by list_monitors' with 100% coverage, so the description does not need to repeat parameter syntax. It adds related context about using it after list_monitors but does not expand on the parameter itself beyond schema coverage, matching the baseline.

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

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

The description states a specific action ('Read one monitor in full') and clearly identifies the resource and added value over list_monitors by naming type-specific details (HTTP status codes, PORT protocol/port, SSL/DOMAIN expiry). This distinguishes it from sibling tools and the list view.

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 tells the agent when to use the tool: 'Use it after list_monitors when the answer depends on how the check is configured' and gives concrete examples like timeout tightness or watched port. This provides clear situational guidance and implicitly contrasts it with the list 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 read-only and idempotent nature, so the bar is lower. The description adds context about returning delivery outcomes and whole-account scope, and explicitly mentions the ability to detect silent failures, which is behavioral insight beyond the annotations. No contradictions 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, each earning its place. The first states the action and scope; the second gives concrete use cases and adds the nuance of silent failure detection. No fluff, efficiently 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 read tool with an output schema, the description covers purpose, scope, and use cases well. It doesn't mention time ranges or pagination, but these are likely covered by the output schema and parameters (page). The description sufficiently completes the context for an agent to decide when to invoke.

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 baseline is 3. The description mentions the channel list (email, Telegram, webhook, web) matching the enum, and alludes to 'delivery outcome' which relates to the status parameter, but doesn't add significant new meaning beyond the schema. It does not compensate with extra details on parameter usage.

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 that it reads alerts sent by the account with delivery outcomes across channels. It names specific channels and the key use case of identifying silent delivery failures, setting it apart from sibling tools like get_incidents or monitor management 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?

Explicitly provides two concrete use cases: answering whether the user was actually notified, and finding a silently failing channel. Also clarifies that it covers the whole account, not just one monitor, which helps differentiate from monitor-scoped 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds behavioral context by specifying the aggregation granularity (per day) and the metrics (min, max, average, p95), which goes beyond the annotations. It doesn't mention pagination or default date ranges, but the schema covers those. Given the strong annotation coverage, a 4 is appropriate for the added context about the data shape.

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 core purpose, and every sentence earns its place. The first sentence states what it does, the second provides usage guidance and points to the alternative. No fluff, no repetition of schema details. This is a model of conciseness.

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 tool has a rich output schema (not shown but indicated), 100% schema coverage, and strong annotations. The description covers the key behavioral aspects: daily aggregation, metrics, and comparison use case. It doesn't explicitly mention pagination or default date ranges, but those are in the schema. For a read-only reporting tool with good structured metadata, the description is complete enough. A 4 is justified because it could mention the output format (e.g., array of daily records) but the output schema likely 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?

Schema description coverage is 100%, so all four parameters (monitorId, dateFrom, dateTo, page) are already documented in the schema with descriptions. The tool description doesn't add parameter-specific semantics beyond what the schema provides, but it does clarify the overall purpose of the date range (daily aggregation) and the monitorId context. Per the rubric, with high schema coverage, baseline is 3, and the description doesn't significantly exceed that.

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: 'Response time and uptime for one monitor aggregated per day, with min, max, average and p95.' It specifies the resource (one monitor), the aggregation level (per day), and the metrics included. It also distinguishes itself from siblings by noting it's for reports/trends over weeks/months and comparing monitors, while get_stats_hourly is for zooming into a single day.

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 provides explicit usage guidance: 'This is the tool for reports and trends over weeks or months, and for comparing one monitor against another over the same window. When a single day looks wrong, zoom into it with get_stats_hourly.' This clearly states when to use this tool and when to use the alternative (get_stats_hourly), which is exactly what the dimension asks for.

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 non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral context: the granularity (hourly), the included statistics (min, max, avg, p95), and the implication of high row counts ('returns far fewer rows' for daily). It does not discuss pagination behavior explicitly, but the page parameter exists in the schema, so the incremental value is strong without being exhaustive.

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 with no filler. Each sentence serves a distinct purpose: the first explains what the tool returns, the second illustrates why you'd use it, and the third directs to an alternative for longer ranges. It is front-loaded with the core action and scale, making it easy to parse quickly.

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 moderate complexity, full schema coverage, rich annotations (read-only, idempotent), and presence of an output schema, the description covers all essential context. It explains the granularity, the metrics, the intended use cases, and the sibling differentiation. An agent can confidently select and invoke this tool without needing additional information.

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 clear descriptions for all four parameters including defaults and format (e.g., 'YYYY-MM-DD'). The description adds no parameter-specific details beyond what the schema already provides. It implicitly references monitorId by saying 'for one monitor,' but the schema already documents it as required. Baseline 3 is appropriate because 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?

The description clearly states the tool's function: 'Response time and uptime for one monitor broken down by hour, with min, max, average and p95 per bucket.' It uses a specific verb-resource structure and distinguishes from sibling get_stats_daily by explicitly noting the appropriate time range (hours/days vs weeks/months). This leaves no ambiguity about what the tool does.

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 provides explicit usage guidance: 'Best over hours or days; for weeks and months use get_stats_daily instead, which returns far fewer rows.' It also offers concrete use cases (spotting degradation, outage clustering, incident duration) that help the agent decide when to invoke this tool. This is a model of clear when-to-use versus alternative 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=true and destructiveHint=false, but the description adds useful behavioral context: pagination (30 per page), ordering (newest first), and the behavior of returning an empty list instead of an error when nothing matches. It also clarifies the 'pending' and 'paused' statuses. This goes beyond the annotations without contradicting them.

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 and structured: 3 sentences. It front-loads the main purpose and pagination, then the field contents, and ends with a practical tip. Every sentence adds value without 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 a good schema and annotations, the description is complete. It covers ordering, pagination, field contents, usage context, filtering semantics, and error behavior (empty list). The existence of an output schema covers return values, so no further detail is needed.

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 100% coverage of all three parameters with descriptions and enums. The description adds context on how parameters map to use cases (e.g., using status='down' to find broken monitors) and explains the meaning of special enum values like 'pending' and 'paused', which is not fully explicit in the schema.

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

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

The description clearly states the tool lists monitors on the account with specific ordering and pagination. It explicitly mentions the fields included and immediately distinguishes itself from siblings by stating 'Start here when the request names a monitor by name rather than by id' and 'when asked what is broken' – differentiating from get_monitor and other create/pause/delete 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?

The description provides explicit guidance on 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'. It also suggests filtering by status 'down' to answer what is broken in one call. This directly addresses usage context versus alternatives like get_monitor.

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 non-readOnly and non-destructive, and idempotentHint:true. The description adds behavioral detail: history/config survive, and paused monitors report neither up nor down. It doesn't explicitly mention idempotency or any side effects, but given annotations cover safety, the description supplements with operational behavior. Slight deduction for not stating that pausing is reversible via resume_monitor (it implies it) and not disclosing potential edge cases, but overall strong.

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 (3 sentences), front-loaded with the core purpose, and every sentence adds value: purpose, usage context, and a behavioral warning. No fluff or repetition.

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 (1 param, full schema coverage, output schema present) and strong annotations, the description covers the key aspects: what it does, when to use, how it affects monitoring, and what persists. The output schema presumably describes the response, so no need to elaborate. This is complete for a 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?

The schema already fully covers the single 'id' parameter with description ('Monitor id to pause, as returned by list_monitors.') and constraints (exclusiveMinimum:0). The description doesn't add extra parameter semantics beyond what's in schema, but with 100% coverage, baseline 3 is appropriate. The description does not discuss the id format or behavior if id is invalid, but schema covers the basics.

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 with a specific verb+resource ('Stop checking a monitor without deleting it'), and distinguishes it from delete_monitor, resume_monitor, and create_* siblings. It explicitly notes that history/config survive, which differentiates it from destructive operations.

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 when-to-use guidance ('Use this around planned maintenance') and explains the reasoning (avoid downtime impacting uptime figures or firing alerts). It contrasts with resume_monitor and delete_monitor implicitly, and the mention of 'paused monitor reports neither up nor down' helps an agent decide when to use 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 provide idempotentHint=true and destructiveHint=false. The description adds valuable behavioral detail: 'The first check runs immediately rather than after the usual interval,' which is not present in annotations. It also reinforces idempotency with 'Safe to call on a monitor that is already running.' No contradictions.

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 concise sentences, each adding essential information: purpose, the immediate-check behavior, and idempotency. There is no redundant or verbose language; it is front-loaded and efficient.

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 tool with one parameter and an output schema, the description covers all essential aspects: what it does, when to call it, and the immediate-check behavior. The idempotency note is critical. It does not need to describe return values given the output schema, and error handling is not required for this context.

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 ('Monitor id to resume, as returned by list_monitors.') with 100% coverage. The description does not add extra meaning or examples beyond the schema, which is acceptable given the high coverage. 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 explicitly states the action: 'Start checking a paused monitor again' with the nuance of using its previous configuration. It clearly distinguishes from sibling pause_monitor and other monitor creation tools. The verb+resource combination is specific and unambiguous.

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 clearly implies when to use: when a monitor is paused and needs to be resumed. It also notes 'Safe to call on a monitor that is already running,' indicating idempotent usage. However, it does not explicitly contrast with alternatives like create_* or state when not to use it (e.g., if the monitor does not exist), but given the sibling context, the usage is well implied.

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