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?

The annotation readOnlyHint=true already indicates a safe read operation. The description adds a valuable behavioral detail: 'Returns partial results if some blocklists are too slow to answer,' which informs the agent about potential incomplete responses. This goes beyond 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 extremely concise, consisting of two short sentences. It front-loads the primary purpose and includes a brief caveat about partial results, with 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?

The tool is simple with one parameter, an output schema, and a clear annotation. The description covers the core behavior and a key edge case (partial results). It does not mention any prerequisites or error conditions, but these are not critical for this straightforward 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 already provides a clear description for the 'ip' parameter ('Public IPv4 or IPv6 address') with 100% coverage. The description adds no additional semantic detail beyond reiterating 'public IP address,' so 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: checking whether a public IP address is listed on DNS blacklists. It uses a specific verb ('check') and resource ('public IP address' against 'DNS blacklists'), distinguishing it from sibling tools like check_dns or 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?

The description provides clear context for when to use the tool (to determine if an IP is blacklisted) and implies it is for IP reputation checks. It does not explicitly mention alternatives or exclusions, but the context is sufficient for most use cases.

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 readOnlyHint annotation already declares this as a safe read operation, so the description does not need to repeat that. The description adds 'up to 10 per call' which is also present in the schema, and does not disclose additional behavioral traits like connection timeouts or return format. It is consistent with annotations, no contradiction.

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

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

The description is two short sentences, front-loaded with the primary purpose, and includes a necessary usage hint about the port list limit. Every word earns its place with no redundancy or filler.

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

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

For a simple two-parameter read-only tool with full schema descriptions and an output schema, the description provides adequate context for an agent to select and invoke it. Minor omissions like defining 'open' (e.g., TCP handshake success) are covered by the output schema, so the description is sufficiently 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?

Both parameters are fully described in the schema (100% coverage), including an example for the port parameter. The description reinforces the ability to pass a single port or list but does not add meaning beyond the schema. Baseline of 3 is appropriate because the schema handles 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 a specific action ('Check whether one or more TCP ports are open on a host') with a specific resource (TCP ports on a host). It distinguishes from sibling tools by explicitly mentioning TCP ports, which differentiates it from DNS, SSL, ping, and other network 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?

The description implies usage for checking TCP port availability but does not explicitly state when to use it over alternatives or mention exclusions. No comparison to sibling tools like ping_test or check_ssl is provided. Usage context is clear but 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 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 useful context by enumerating the measured network phases (DNS, connect, TTFB, total). It does not describe timeout behavior or response format, but the output schema covers return values, so the added 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?

The description is a single front-loaded sentence: 'Measure a website's response time (DNS, connect, TTFB, total).' Every word contributes to understanding the tool's function, with no redundancy or irrelevant details.

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

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

With only one parameter, a clear output schema, and a simple purpose, the description fully captures what the agent needs to select and invoke the tool. It identifies the tool's niche and the measured metrics, making it complete for the tool's complexity.

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

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

The input schema has 100% description coverage for the only parameter 'url' ('Full URL, e.g. https://deinkunde.com'). The description adds no additional meaning about the parameter, so the baseline score 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 a clearly defined resource 'website's response time', listing specific metrics (DNS, connect, TTFB, total). This distinguishes it from sibling tools such as ping_test or http_headers, which have different objectives.

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 detailed response-time breakdowns are desired, but it does not explicitly mention alternatives, nor does it state when not to use this tool. The context is clear enough to infer the use case, but no exclusions or comparisons are provided.

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?

The annotation readOnlyHint:true already covers safety. The description adds valuable behavioral context by listing exactly what the call returns (up/down verdict, HTTP status, response time, redirect count) and indicating it checks 'right now' (real-time). It does not contradict annotations and provides useful expectations beyond the 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 two short sentences that front-load the core question and immediately follow with usage guidance and output summary. Every phrase earns its place: 'right now' signals real-time, 'start here' gives behavioral priority, and the enumerated outputs set expectations with zero fluff.

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

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

Given the simplicity of the tool (one required parameter, fully documented in schema) and the presence of an output schema, the description is complete. It captures the purpose, usage trigger, and key return fields, and the sibling context makes it clear this is the default entry point for website status checks.

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 for the single 'url' parameter is 100%, with a clear example ('https://deinkunde.com'). The description does not add extra parameter-level information beyond confirming the resource is a website, so it meets the baseline for schema-heavy tools but doesn't 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 uses a specific verb phrase ('Is a website up right now?') and resource ('website'), and lists concrete outputs (up/down verdict, HTTP status, response time, redirect count). It also distinguishes itself from siblings by explicitly positioning itself as the starting point ('Start here') for is-the-site-down questions.

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 usage context: 'Start here for any is-the-site-down question'—this tells when to use the tool. It implies that for more focused checks (e.g., response time alone) other sibling tools might be used, but it does not explicitly name alternatives or exclusions, so it stops short of the highest score.

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.