Uptimeify

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

Annotations already declare readOnlyHint=true, and the description adds meaningful context: it specifies the input type (public IP or domain) and the output (ASN and network owner). It also distinguishes 'public' IPs, implying private IPs may not work. This adds value beyond 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 a single sentence that immediately identifies the tool's purpose, output, and input constraints. Every word contributes 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?

This is a simple lookup tool with one parameter, a read-only annotation, and an output schema. The description fully covers the essential purpose and input scope. It could optionally mention example queries or error behavior, but such details are not necessary given the simplicity and existing schema/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?

Schema coverage is 100%, with the parameter description already stating 'Public IP address or domain name.' The tool description repeats this information almost verbatim ('for a public IP or domain') and does not add new semantics like format examples or validation constraints. Baseline 3 is appropriate since the schema carries the full meaning.

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 performs an 'ASN lookup' for a public IP or domain and returns 'the autonomous system and its network owner.' This is a specific verb + resource + outcome, and it distinguishes itself from sibling tools like whois or ip_geolocation, which focus on different network attributes.

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

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

The description implies when to use the tool (when you need ASN information for a public IP or domain) but does not explicitly mention alternatives or provide exclusion criteria. Usage guidance is implicit rather than explicit, which aligns with a score of 3.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the specific record types, but no limits, return format, or other behavioral details. 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?

A single, front-loaded sentence that clearly states the purpose without any fluff. 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?

For a simple one-parameter tool with an output schema, the description is adequately complete. It could specify what 'and more' includes, but the output schema likely covers 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% for the single 'domain' parameter, and the description adds no parameter semantics beyond what the schema already 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's action ('Check') and resource ('domain's DNS records'), and enumerates specific record types (A/AAAA/CNAME/TXT/NS), which distinguishes it from siblings like mx_lookup (specific record) and dns_propagation (propagation status).

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

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

The description implies use for checking DNS records but gives no explicit guidance on when to choose this tool over siblings like mx_lookup or dns_propagation. No alternatives or exclusions are mentioned.

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 annotations declare readOnlyHint=true, and the description aligns with that. It adds context about optional date-range filtering and the 'recent' nature of the history, but does not disclose other behaviors like limits or ordering. This is adequate given 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 two sentences, front-loaded with the purpose, and includes only the essential optional detail. No wasted words 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?

The tool is simple, with a clear purpose, full schema coverage, and an output schema present. The description covers the main functionality but leaves the default meaning of 'recent' ambiguous. Minor gaps exist but overall adequate.

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 three parameters, including examples for from/to. The description adds no new parameter semantics beyond the schema coverage, which 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 clearly states that the tool retrieves check history for a website monitor, with an optional date range. It uses a specific verb and resource, but does not explicitly distinguish from sibling tools like uptime_summary or website_status.

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

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

There is no guidance on when to use this tool compared to alternatives. The description simply states what it does without any context, exclusions, or mention of sibling 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?

The readOnlyHint annotation already signals a safe read operation, so the description adds value by listing the specific certificate details returned. However, it does not discuss edge cases (e.g., SNI behavior, timeouts) or the trust verdict semantics beyond the minimal list.

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

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

The description is a single, well-structured sentence that gets straight to the point. It is concise, informative, and front-loads the core action and object.

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, the readOnlyHint annotation, and the presence of an output schema, the description sufficiently covers the tool's purpose and key details. It does not need to explain return values because the output schema handles that, and the description provides enough to 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 coverage is 100% for both parameters (host and port), with descriptions including the port default. The description itself does not add parameter-level detail beyond referencing 'host', so it neither detracts nor meaningfully enhances what the schema already 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 uses a specific verb ('Check') and identifies the resource ('host's TLS/SSL certificate'), then enumerates the key attributes examined (issuer, validity dates, expiry, chain, trust verdict). This clearly distinguishes it from sibling tools like check_dns or port_check.

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

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

The description implies the use case (checking SSL certificate details for a host) but does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools such as hsts_check or port_check are not referenced, so the context is clear but not contrasted.

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

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

The readOnlyHint annotation declares the operation is read-only, and the description adds that it fetches and validates the key. However, it does not explain what 'validate' entails, error behavior, or any prerequisites, leaving some gaps beyond the annotation.

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

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

The description is a single sentence that is front-loaded with the action (Check) and the resource (DKIM public key), then clarifies via 'fetch it and validate it.' Every word earns its place, 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?

For a simple two-parameter read-only tool with an output schema and clear annotations, the description provides adequate context. It explains the core behavior, and the output schema covers return values, so no significant detail is missing.

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

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

Schema description coverage is 100%, with both 'domain' and 'selector' already described with examples. The description merely restates these concepts without adding extra semantic detail, so it meets the baseline but does not exceed it.

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 checks a domain's DKIM public key for a given selector, and explains it fetches and validates it. This specific verb+resource combination distinguishes it from sibling tools like dmarc_check, spf_check, and mx_lookup.

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

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

There is no explicit guidance on when to use this tool over alternatives, but the name and description imply usage for DKIM key validation. The sibling list shows related DNS tools, yet no comparisons or exclusions are mentioned.

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

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

readOnlyHint annotation already declares safety; description adds 'fetch' and 'evaluate' steps, but no additional behavioral detail like handling of missing records or response format. It doesn't contradict 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 short sentences, front-loaded with the operation, 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 one-parameter read-only tool with an output schema, the description is adequate and covers the core behavior; could mention when to use but not necessary for completeness.

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 fully describes the single 'domain' parameter with an example; description adds no parameter-level meaning, so baseline 3 applies.

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

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

The description uses specific verbs 'fetch' and 'evaluate' with the resource 'DMARC policy record', clearly distinguishing it from sibling tools like dkim_check and spf_check.

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?

No explicit when-to-use or alternatives are given; usage is implied by the domain-specific resource, but there's no guidance on exclusions or when other DNS tools might be preferable.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to state safety. It adds the constraint that the IP must be public and mentions 'common DNS blacklists', but does not disclose blacklist providers, rate limits, or response structure. With annotations covering the safety profile, the added context is adequate but not rich.

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

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

The description is a single sentence, front-loaded and easy to parse. The opening 'DNSBL check:' is redundant with the tool name but the rest is waste-free, making it appropriately concise.

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

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

For a one-parameter read-only tool with an output schema, the description covers the essential purpose and parameter constraint. It does not explain blacklist providers or output interpretation, but the output schema likely handles that, making it sufficiently complete for this low-complexity 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 provides 100% coverage for the ip parameter, describing it as a public IPv4 or IPv6 address. The description mirrors this without adding extra detail about format, validation, or special cases, so it does not significantly enhance 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 checks whether a public IP is listed on DNS blacklists, distinguishing it from siblings like check_dns or reverse_dns that check other DNS records. The verb 'check' is specific to the resource, making the purpose 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 implies usage for DNSBL checks but provides no explicit guidance on when to use this tool versus alternatives. There are no exclusions or references to sibling tools for related IP reputation checks.

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

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

Annotations already declare readOnlyHint=true, so the safe read nature is known. The description adds the behavioral detail of checking 'multiple public resolvers', which is useful but does not cover aspects like resolver count, timeout, or output details. With annotations present, this is adequate but not rich additional 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?

The description is a single, front-loaded sentence that directly states the tool's purpose. It contains no filler and every word contributes to understanding the tool's functionality.

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 presence of an output schema, and readOnlyHint annotation, the description is fairly complete. It could potentially explain what 'propagation' means in terms of expected behavior, but for a simple read-only tool, the current description suffices.

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 has 100% coverage for the single 'domain' parameter, with a clear example ('deinkunde.com'). The description does not add any additional parameter semantics, so the baseline of 3 applies.

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

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

The description clearly states the tool checks DNS propagation of a domain across multiple public resolvers. The phrase 'across multiple public resolvers' distinguishes it from sibling tools like check_dns, which likely performs basic DNS lookups. This gives a specific verb and resource with clear scope.

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

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

The description implies usage when you need to verify DNS propagation, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternatives are mentioned, so the guidance is only implicit.

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=true, and the description adds no extra behavioral context beyond confirming it is a read operation. It does not mention data sources, potential delays, or failure modes for unregistered/invalid domains, so it provides minimal value 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 a single, concise sentence that directly conveys the purpose without any redundant words or filler. It is appropriately front-loaded and easy to parse.

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, return values are already documented. The simple tool has only one parameter and read-only annotations, so the description is mostly complete. However, it could benefit from a brief mention of how the expiry date is obtained (e.g., via WHOIS) or edge-case behavior, but this is not critical given the schema coverage.

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% with a clear description for the 'domain' parameter including an example. The tool description adds no additional meaning, so the baseline score of 3 is appropriate since the schema fully documents the parameter.

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 action ('Check') and the specific resource ('domain's registration expiry date and the days remaining'). This is specific and distinguishes it from broader sibling tools like whois, which would provide more general registry data.

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 no guidance on when to use this tool versus alternatives (e.g., whois, check_ssl). It merely states what it does without contextual hints or exclusions, so the agent receives no help in selecting this tool over siblings.

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

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

Annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds little behavioral context beyond what's implied by 'check'—it does not mention network calls, failure conditions, or what happens with domains lacking HSTS. 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?

The description is a single sentence that restates the tool name ('HSTS check') and adds the resource. It is concise but somewhat under-informative; it earns its place by specifying the resource, but could be more structured without being verbose.

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 is simple with one parameter and an output schema exists. The description sufficiently defines the purpose for a basic check tool, and the annotations cover the read-only safety. It doesn't need to explain return values since output schema presumably handles 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% for the single 'domain' parameter with an example. The description doesn't add further semantic context, but since the schema fully documents the parameter, a 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 the tool checks a domain's HTTP Strict Transport Security configuration, which is specific and distinct from sibling tools like check_ssl or http_headers. The verb 'check' plus the resource 'domain's HSTS configuration' makes the purpose 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 implies this tool is for checking HSTS configuration, but it does not explicitly state when to use it over alternatives or provide exclusions. It is clear from context that it's for security header checks, but no explicit guidance is given.

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

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

Annotations declare readOnlyHint=true, and the description's 'Fetch' aligns with this read-only behavior. However, the description does not disclose any behavioral nuances such as redirect following, timeouts, or rate limits, so it adds only minimal context beyond the annotation.

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

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

The entire description is an eight-word sentence that states the core function without redundancy. It is appropriately sized for a one-parameter read-only tool and front-loads the key information.

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

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

For a tool with a single required parameter, full schema coverage, a readOnly annotation, and an output schema, the description is sufficiently complete. No additional context is necessary for an agent to select and invoke it 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?

The input schema already documents the only parameter (url) with format guidance ('Full URL, e.g., https://deinkunde.com'), providing 100% coverage. The description adds no parameter-specific details beyond referring to 'a URL,' 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 uses a specific verb ('Fetch') and resource ('HTTP response headers'), clearly identifying what the tool does. It also distinguishes this tool from siblings like check_ssl or whois by focusing on HTTP headers.

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?

No guidance is provided on when to use this tool vs alternatives. The description only states the action and target, with no mention of when it's appropriate, prerequisites, or exclusions.

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

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

Annotations already provide readOnlyHint=true, signaling a safe read operation. The description adds value by naming the output fields (country, region, ASN, org), but does not disclose potential limitations, input validation rules, or rate-level behaviors. This meets the baseline but goes no further.

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

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

The description is a single, concise sentence that front-loads the tool's purpose and output. Every word adds meaning, with no repetition of schema or annotation information.

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

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

Given the tool's simplicity (one well-documented parameter, read-only annotation, and an output schema), the description provides sufficient context by stating input types and output categories. It lacks explicit notes on IP format variations or error behavior, but the complexity is low enough that this is not a significant gap.

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

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

The schema provides full coverage for the single 'query' parameter with a clear description ('Public IP address or domain name'). The tool description adds no additional parameter-level detail, so the schema carries the burden. 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 indicates the tool provides geolocation information for a public IP or domain, listing the main output fields (country, region, ASN, org). While it uses a noun phrase rather than a verb, it distinguishes itself from sibling tools by mentioning the broader scope of results, though it doesn't explicitly contrast with asn_lookup.

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

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

The description implies usage when you need geolocation data for an IP or domain, but it provides no explicit guidance on when to choose this over alternatives like asn_lookup or whois. No exclusions or competitor comparisons are given.

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

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

With readOnlyHint=true, the safety profile is established. The description adds valuable behavioral context beyond annotations: the tool aggregates incidents across all monitors and orders them most-recent-first. 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?

The description is a single sentence that is front-loaded with the key action and resource. Every word adds value with no redundancy or 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?

The tool is simple, has an output schema, complete parameter schema, and read-only annotation. The description covers the essential scope and ordering, making it sufficient for an AI 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 coverage is 100%, with the 'limit' parameter fully documented in the schema (default 100, max 500, min 1). The description does not add additional meaning for this parameter, so the baseline of 3 applies.

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

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

The description clearly states the action (List), the resource (recent incidents), and the scope (across all of the caller's monitors) plus ordering (most recent first). This distinguishes it well from sibling tools like list_monitors.

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 implicitly provides context by specifying 'across all of the caller's monitors,' which signals when to use this tool (for a global incident view) versus alternatives. However, it does not explicitly mention alternatives or when not to use it.

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 the readOnlyHint annotation, the description adds meaningful behavioral detail: the result set depends on whether a customer or organization token is used. This goes beyond the annotation's safety hint, though it does not elaborate on response format or potential errors, which are covered by the 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 single, well-structured sentence, front-loaded with the action ('List the website monitors') and promptly explains scoping. No wasted words, perfect 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?

With zero parameters, an output schema, and a readOnly annotation, the description provides the essential token-scoping context. It fully explains what the caller will see, making it complete for this list-type tool. The output schema handles return values, and no further behavioral details are 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 tool has zero parameters, and the schema coverage is 100% (empty schema). Therefore, the description does not need to explain parameters. The baseline for zero-param tools is 4, and the description adds no irrelevant parameter information.

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 website monitors visible to the caller's API token, with specific mention of token type affecting scope. This is a specific verb and resource, and it distinguishes from sibling tools like list_incidents or monitor_status by focusing on monitors themselves.

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 clear context on when this tool is appropriate by explaining the token-based visibility (customer vs organization). However, it does not explicitly contrast with alternatives or mention when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that it returns status and configuration, which is useful but limited. No mention of rate limits, pagination, or other behavioral traits, but given the simple read operation and existing annotation, the description is adequate.

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, well-structured sentence that front-loads the core action and resource. There is no repetition of schema or annotation information, and 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's simplicity (one parameter, no nested objects), the presence of an output schema, and the readOnlyHint annotation, the description is complete. It covers what the tool does and what it returns, and the schema provides the remaining parameter 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% with a clear description for the single parameter. The param description adds meaningful context by specifying that monitor_id is the 'public id from list_monitors', helping the agent know how to obtain the value. This exceeds basic schema semantics.

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: 'Get a single website monitor by id', with the specific resource being a website monitor. It differentiates from sibling tools like list_monitors by emphasizing 'single' and 'by id', and from status-only tools by including both 'current up/down status and configuration'.

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

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

The description implies usage when you need details for a single monitor, especially since it mentions 'by id' and the id comes from list_monitors in the param description. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, so guidance is only implicit.

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 annotation readOnlyHint=true already signals a safe read operation. The description adds that the tool returns MX records and 'their addresses,' which is useful output detail, but it does not disclose edge-case behavior such as missing MX records or resolved address semantics. With annotations covering safety, this modest additional context warrants a 3.

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, focused sentence without filler. It front-loads the core purpose and includes the key output detail ('their addresses'), earning every word.

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 read-only tool with one fully documented parameter, an output schema, and a read-only annotation, the description is mostly complete. However, it lacks any guidance on how this differs from the many DNS-related siblings (e.g., check_dns), so a sentence about when to use it would make it fully 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?

Input schema coverage is 100% with the 'domain' parameter already well-described ('Domain name, e.g. deinkunde.com'). The tool description does not add any parameter-level detail beyond what the schema provides, so it meets the baseline but does not exceed it.

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 specific action: 'MX lookup for a domain' and specifies what it returns ('its mail exchanger records and their addresses'). This distinguishes it from sibling tools like check_dns (generic DNS), dkim_check, and dmarc_check which focus on other record types.

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 phrase 'for a domain' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusion scenarios (e.g., when to use check_dns instead), so it lacks the explicit when/when-not guidance that would earn a 5.

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

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

Annotations declare readOnlyHint=true, so the safety profile is clear. The description adds meaningful context by specifying that this measures TCP-level reachability (not ICMP ping) and reports round-trip time, which is valuable behavioral information beyond the annotation.

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

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

The description is a single, grammatically efficient sentence that front-loads the core purpose. There is zero extraneous content, and the 'Ping test:' prefix is a helpful label rather than waste.

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, presence of an output schema, and read-only annotation, the description is sufficiently complete. It covers the essential behavior (TCP reachability and RTT), though it could be improved with a brief usage context relative to sibling 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 documents both parameters clearly (host, port with default). The description does not add new parameter-level detail, but with 100% schema coverage, 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 uses a specific verb ('measure') and identifies both the resource (TCP reachability to a host) and the metric (round-trip time). It clearly distinguishes from siblings like port_check (which likely just tests port openness) and response_time (HTTP-level timing).

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

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

The description implies when to use this tool (for TCP reachability and RTT), but does not explicitly contrast it with alternatives such as port_check or response_time. It provides no when-not-to-use guidance or exclusions.

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

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

The annotations already declare readOnlyHint=true, and the description's 'check' action is consistent with this. However, the description adds no additional behavioral context, such as return values or potential network timeouts, though the output schema likely covers return values.

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 sentence with no filler words, efficiently conveying the tool's purpose.

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

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

For a simple read-only network check with two well-defined parameters and an output schema, the description provides the essential information. It lacks guidance on edge cases like firewalls or timeouts, but these are less critical given the annotations and output schema.

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 describes both parameters (host as 'Domain name or host' and port as 'TCP port to test') with 100% coverage. The description merely repeats the parameter names without adding any new semantic detail.

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 the verb 'check' with a specific resource ('TCP port') and scope ('on a host'), making it immediately clear what the tool does and distinguishing it from sibling tools like ping_test or check_ssl.

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 no guidance on when to use this tool versus alternatives such as ping_test or website_status. It simply states the function without any contextual or exclusionary information.

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

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

The readOnlyHint=true annotation already covers the safety profile, and the description adds the behavioral detail that it traces the chain to the final destination. However, it does not disclose potential edge cases like redirect loops, hop limits, or whether relative redirects are handled. It provides minimal extra context beyond the annotation.

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

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

The description is one sentence of 13 words, front-loads the verb and resource, and contains no filler or redundant phrases. It is concise 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?

Given the tool's simplicity (one parameter, read-only annotation, and an output schema), the description sufficiently explains the tool's behavior and purpose. It does not need to explain return values because the output schema handles that. No critical information is missing for effective tool selection and 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 single parameter 'url' is fully described in the schema with a clear example. The description only repeats that it takes a URL, adding no new meaning. With 100% schema coverage, the baseline of 3 is appropriate; the description does not enhance the parameter understanding.

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 specifies a clear verb ('Check') and resource ('HTTP redirect chain for a URL'), and further clarifies the outcome ('tracing it to the final destination'). This distinguishes it from sibling tools like http_headers or website_status, which do not focus specifically on redirect chains.

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

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

The description implies usage when you need to see redirects and the final URL, but it does not explicitly state when to use this tool over alternatives or list exclusions. There is no mention of when not to use it, e.g., if you only need response codes or headers. The context is clear but not elaborated.

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 the description adds value by specifying the measured subcomponents (DNS, connect, TTFB, total). This context helps the agent anticipate the kinds of results returned, going beyond the basic read-only flag.

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, front-loaded sentence that conveys the core purpose without fluff. Every word earns its place, making it highly concise 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?

For a simple tool with one parameter and an output schema, the description is largely complete. It lacks explicit guidance on when to choose it over sibling tools, which prevents a perfect score, but it remains adequate for basic selection and 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 fully describes the only parameter 'url' with a clear example. The description does not add additional parameter-level details, so the baseline of 3 is appropriate given 100% 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 identifies the verb 'measure' and the resource 'website's response time', breaking it down into DNS, connect, TTFB, and total. This specific metric breakdown distinguishes it from sibling tools like ping_test (network latency) and website_status (availability).

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

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

The description implies the tool is for measuring response time components, providing clear context. However, it does not explicitly state when to use this tool over alternatives such as ping_test or http_headers, nor mention any exclusions or prerequisites.

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

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

Annotations already indicate readOnlyHint: true, so the safety profile is covered. The description adds that the tool resolves to a PTR hostname, but it does not disclose edge-case behavior (e.g., what happens if no PTR record exists) or any potential rate limits. 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?

The description is a single sentence, front-loaded with the tool name and core action, with zero wasted words. It is appropriately sized for the tool's simplicity.

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 a single required parameter, a read-only annotation, and an existing output schema (not shown but signaled), the description is complete. It identifies the input type and output format, and no further details are needed for this straightforward lookup 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 input schema provides 100% coverage with the 'ip' parameter described as 'Public IPv4 or IPv6 address'. The description does not add any additional meaning beyond what the schema already states, so the baseline score of 3 applies.

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

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

The description uses a specific verb 'resolve' with a clear object ('public IP address') and outcome ('PTR hostname'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling DNS tools like asn_lookup or mx_lookup by focusing solely on reverse DNS.

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

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

Usage is implied (use when you need a PTR hostname for an IP) but there is no explicit guidance on when to use this tool versus alternatives like check_dns or dns_propagation. With 25 sibling tools, clearer differentiation would help an agent select the correct 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 readOnlyHint=true, and the description adds useful behavioral context: it fetches the record and evaluates the policy. This goes beyond the annotation by clarifying the two-step nature of the operation. 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?

One concise sentence with a colon splitting the action into fetch and evaluate. No wasted words, front-loaded, and the structure aids quick comprehension.

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 single-parameter, read-only DNS lookup tool with an output schema available, the description sufficiently covers the core behavior. It does not need to explain return values because an output schema exists, and the simplicity of the tool means no additional context is required.

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 has 100% coverage for the single 'domain' parameter with an example ('e.g. deinkunde.com'). The description adds no additional parameter-level detail, so it defaults to the baseline score of 3.

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

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

The description clearly states the tool's function: 'Check a domain's SPF record: fetch it and evaluate the policy.' It uses a specific verb ('check') and identifies the resource (domain's SPF record), which differentiates it from sibling tools like dkim_check and dmarc_check that target other DNS records.

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

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

The description implies usage—if you need to check an SPF record, this is the tool—but it gives no explicit when-to-use or when-not-to-use guidance. It does not name alternatives or exclusions, so it falls short of clear contextual 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, so the agent knows it's a read operation. The description adds the period aggregation (day/month/year) but does not detail any edge cases, authentication requirements, or rate limits. With annotations covering the safety profile, this is acceptable but not enhanced.

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?

Single sentence, front-loaded with the action, no fluff. Entire description is 12 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 one-parameter read tool with output schema and readOnlyHint annotation, the description adequately conveys purpose and scope. It doesn't need to detail return values since output schema exists. Minor gap: doesn't mention that results are aggregated over selected periods, but that's implicit.

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

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

Schema coverage is 100% for the single parameter monitor_id, and the schema already provides a description linking it to list_monitors. The tool description reuses the concept of 'website monitor' but adds no new meaning beyond the schema. Baseline 3 applies.

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

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

The description uses the specific verb 'Get' and identifies the resource as 'uptime and average response-time summary' for a website monitor, with clear time granularity (day/month/year). This distinguishes it from siblings like monitor_status or website_status which report current state.

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?

No explicit guidance on when to use this tool versus alternatives like monitor_status or response_time. The description implies it's for historical summary data but doesn't state exclusions or alternatives. This earns a 3 for implied usage.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds value by specifying the three behavioral outputs (up status, HTTP status, timing) but does not disclose details like redirect handling, timeout behavior, or what counts as 'up'. 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?

The description is a single, front-loaded sentence with zero filler. Every word contributes to conveying the tool's purpose, making it highly concise 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?

For a simple, single-parameter, read-only tool with an output schema and full parameter documentation, the description sufficiently communicates the core functionality. It lacks usage guidance, which is scored separately, but is otherwise complete for an agent to select and invoke the 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 fully describes the url parameter with an example, achieving 100% coverage. The description adds no additional parameter-level semantics, so the baseline score of 3 applies.

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

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

Description uses the specific verb 'Check' and identifies the resource (website) and the key outputs (up, HTTP status, response timing). This clearly distinguishes it from siblings like check_ssl, check_dns, and even response_time or http_headers by combining all three aspects into a single tool.

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 no guidance on when to use this tool versus alternatives. It does not mention related siblings such as monitor_status, uptime_summary, or response_time, nor does it describe use cases, exclusions, or prerequisites. An agent gets no decision support beyond the tool's own function.

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 the description consistently describes a read operation. It adds minimal context beyond stating it retrieves 'registration data', but does not disclose any limitations, rate limits, or special behaviors. With annotations present, this is acceptable but not rich.

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

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

The description is a single, focused sentence that is front-loaded with the verb and object. Every word adds value; there is 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?

For a single-parameter tool with a rich output schema and readOnly annotation, the description is sufficient. It clearly names the action and subject, and the 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?

Schema coverage is 100% with a clear description for the 'domain' parameter (including an example). The description only repeats 'domain' without adding new meaning, so it meets the baseline but does not enhance parameter understanding.

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 ('Retrieve') and clearly identifies the resource ('WHOIS registration data for a domain'). It distinguishes from siblings by focusing on WHOIS specifically, which is distinct from DNS, SSL, or expiry checks.

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?

No guidance is given on when to use this tool versus alternatives like domain_expiry or check_dns. The description implies a general WHOIS lookup but provides no exclusions or alternative tool suggestions.

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