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

With no annotations provided, the description carries the full burden. It discloses the backend service (Team Cymru's whois), notes that no API key or GeoIP database is needed, and constrains inputs. However, it does not describe the output shape, pagination, or failure behavior, and does not explicitly state that this is a read-only operation.

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

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

Three tight sentences with no filler. The core purpose is front-loaded, the service fact and input constraints follow naturally, and every sentence earns its place.

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

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

For a single-parameter lookup tool with no output schema and no annotations, the description is quite complete: it gives the service, the accepted input forms, the exclusions, and the fallback resolution path. The only clear gap is the exact return structure, though the purpose line already hints at ASN, country code, and org info.

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 only provides 'target' with no description (0% coverage), so the description must compensate. It does: it explains that target can be an IP literal, an ASN like AS15169, or a bare number like 15169, and clarifies what is not acceptable (hostname). This adds real meaning beyond 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 names a specific verb+resource: 'ASN + country-code lookup for an IP, or org info for an AS number'. It immediately tells the agent what the tool does and distinguishes it from sibling tools like dns_lookup or whois_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?

Explicitly states the input domain: takes an IP literal or AS number, not a hostname, and directs the agent to 'resolve first with dns_lookup if you only have a name'. This gives clear when-to-use guidance and names the alternative.

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

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

No annotations are supplied, so the description carries the full burden, and it does most of the work: it enumerates the returned payload (date, 24h time, weekday in English and Japanese, offset, UTC, epoch) and even surfaces a secondary use as a clock check on the server. It never states the operation is a safe read, but for a time query that is self-evident.

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

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

Front-loaded with what it returns, then the routing advice, then the return payload — a sensible order with no filler. The return-field enumeration is slightly listy but each item is informative, so nothing is clearly wasteful.

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

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

There is no output schema and no annotations, so the description takes on both jobs and does so: it lists the return fields and justifies the tool's existence versus computing the date locally. Nothing an agent needs to call it correctly 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 coverage is 0% for the single timezone parameter, so the description must compensate; it names the expected identifier format ('IANA') and gives a concrete example ('Asia/Tokyo'). The UTC default is left to the schema, which is a minor omission given only one 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?

States a specific verb+resource ('current date, time and weekday') and scopes it to 'an IANA timezone'. It is unmistakably distinct from every sibling (dnssec_check, ping_host, traceroute_path, etc.), so the agent can route between them without reading schemas.

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

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

Explicitly tells the agent to prefer this over self-computed calendar arithmetic, and explains why ('it fails silently'), which is real when-to-use guidance. It stops short of stating edge cases such as what happens if the server clock is wrong or which timezone to pick by default, so not a full 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?

With no annotations, the description carries the behavioral transparency burden. It discloses transport behavior, default ports, and the critical dependency on dig BIND 9.18+, including how older dig versions fail. It does not cover every edge case, but the important behavioral quirks are transparent.

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 dense but purposeful, with each sentence adding meaningful technical information. It front-loads the core action, then organizes parameter details and dependency caveats cleanly. No filler or redundant restatement of the name.

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 an output schema exists, return values are covered elsewhere. The description adds essential context about transports, resolvers, and the dig version requirement. It is complete enough for correct invocation, though it could mention edge cases like PTR record hostname formatting or timeout behavior.

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 0%, so the description must explain the parameters, and it largely does. It enumerates record_type values, defines resolver usage, and clarifies transport options with ports and defaults. Hostname is left implicit, but that is a well-understood parameter for a DNS lookup tool.

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

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

The description opens with a specific verb and resource: 'Resolve a DNS record via `dig`.' It lists supported record types and clearly distinguishes itself from sibling tools like dnssec_check, whois_lookup, and asn_lookup. An agent can immediately tell what this tool does.

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

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

The description explains when to use the resolver parameter, such as checking whether a change has propagated to a given resolver. It gives clear operational context, though it does not explicitly contrast with sibling tools or state when not to use it. Overall, usage intent is well implied.

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

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

With no annotations, the description carries the full behavioral burden. It discloses useful behavior, such as relying on a known-validating resolver's AD bit and comparing plain DNS against encrypted transports. However, it does not explicitly state that live network queries are sent or describe potential side effects, leaving some behavior implicit.

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 short and the first sentence front-loads the main purpose. The transport fragment is slightly awkwardly embedded in the description rather than formatted as a parameter note, but there is no redundancy or wasted wording.

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 three-parameter network check with an output schema, the description covers the core operation and the key transport decision. It omits caveats like resolver prerequisites or explicit when-not-to-use guidance, but the sibling tool list and output schema supply much of the remaining context.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful detail for 'transport' (plain/dot/doh and interception rationale) and loosely implies 'hostname' via 'a name' and 'resolver' via 'known-validating resolver.' It does not provide explicit per-parameter explanations, but the essential meaning of all parameters is inferable.

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

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

The description states a specific action ('Check') and resource ('whether a name validates DNSSEC') and adds the AD-bit criterion, which clearly separates it from the sibling dns_lookup. This is not a tautology or vague restatement of the tool name.

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

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

The description gives a concrete usage context: choose plain DNS vs. dot/doh 'when port 53 may be intercepted.' It does not explicitly list exclusions or alternative tools, but the transport comparison provides clear situational 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?

With no annotations provided, the description carries the full burden, and it does well by explaining the fixed return shape and the exact healthy/degraded semantics. It also tells the caller that missing binaries mean corresponding tools will fail at call time, which is valuable behavioral 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 compact and front-loaded: the first sentence states the core purpose, and the second paragraph adds the crucial return-shape and status semantics without any filler. Every sentence contributes useful 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 zero-parameter, no-output-schema tool, the description is fairly complete: it names the top-level return fields and explains status values. The main gap is that 'backend fields' are not enumerated, but the overall behavior is still clear enough for an agent 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?

There are zero parameters, so the baseline is 4. The input schema already documents this completely, and the description confirms no inputs are needed, which is sufficient.

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 a specific resource (service health) and the operation: reporting version and which wrapped binaries are present on PATH. It also differentiates this tool from the network-diagnostic siblings by framing it as a meta/service-level check rather than a network operation.

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 intended use is implied: a monitoring caller should use this to check service health without branching on missing keys. However, it does not explicitly say when to prefer this over sibling tools or state any exclusions, leaving the guidance somewhat indirect.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does communicate the request method, the reported metrics, and that redirects are followed or tracked. It does not mention potential side effects of GET requests, timeout behavior, authentication requirements, or error handling, which are relevant for a network tool.

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 action and lists the key outputs. Every phrase contributes meaning, and there is no redundant or filler content.

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

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

The tool is simple and an output schema exists, so return-value details need not be in the description. Still, important context is missing: no guidance on when to prefer http_check over health_check, no timeout semantics, and no note on whether GET requests may trigger side effects. It is minimally viable but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'a URL', which aligns with the required 'url' parameter, but it adds no meaning to the 'timeout' parameter, leaving units, interpretation, and behavior undocumented. The description adds only marginal value over the parameter names.

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

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

The description uses a specific verb and resource ('HEAD/GET a URL') and names concrete outputs: status, redirect chain, and latency. This makes the tool's HTTP-focused purpose clear, though it does not explicitly distinguish it from the similarly named 'health_check' sibling.

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

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

The description implies the tool is for checking HTTP endpoints via HEAD or GET requests, and the sibling list suggests DNS, TCP, TLS, and other diagnostic alternatives. However, it does not provide explicit when-to-use or when-not-to-use guidance, leaving the agent to infer the appropriate context from the tool name and 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?

With no annotations, the description carries the behavioral burden and does well: it discloses the accepted content types (text/JSON/XML only), the byte cap behavior, and a hard cap of 1 MiB, which are real limits an agent must know. It omits redirect handling, auth requirements, and non-2xx behavior, which keeps it short of a 5.

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 core behavior and limits, ending with the routing hint. Every clause earns its place with no filler.

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

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

An output schema exists, so return values need not be described, and the description covers content types and size limits well. The remaining gap is the undocumented timeout parameter, which matters for an agent tuning request behavior.

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 0%, so the description must compensate for all three parameters. It explains max_bytes semantics (capped output, 1 MiB hard cap) but says nothing about the url format or the timeout unit/behavior, leaving two of three params undocumented anywhere.

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

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

States a specific verb (GET) and resource (URL) and specifies what is returned (response body). It also names the sibling http_check and the scope it does not cover (status/latency only), so an agent can distinguish it without opening the schema.

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

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

Explicitly says when to use it (read a JSON endpoint, inspect an error page) and names the alternative (http_check) with the condition that selects it (status/latency only). Nothing is left to inference.

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

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

With no annotations, the description carries the full burden. It discloses the core behavior 'ICMP ping' and a notable constraint: 'count is clamped to 1-10.' However, it omits other operationally relevant details such as timeouts, permission requirements, or behavior on unreachable hosts.

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 with no filler. The primary purpose is stated first, followed immediately by the single important parameter constraint. 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 diagnostic tool with an output schema present, the description covers the essentials: what it pings and the count limit. It lacks guidance on choosing this tool among the sibling network diagnostics and does not mention edge-case behavior, but the scope is simple enough that the main gaps are about selection rather than 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?

Schema description coverage is 0%, but the description compensates by clarifying that 'host' accepts a hostname or IP address and that 'count' is clamped to 1-10. It does not explicitly say count is the number of ping packets, but that is strongly implied by context.

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 and target: 'ICMP ping a host or IP.' The protocol qualifier 'ICMP' helps distinguish it from siblings like http_check and tcp_port_check, though it does not explicitly name or contrast any sibling.

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

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

There is no guidance about when to choose this tool over alternatives such as tcp_port_check, http_check, or health_check. The description implies usage for ICMP reachability but provides no exclusions, prerequisites, or decision rules.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does reveal the mechanism ('plain socket connect') and expressly rules out scanning, but it does not mention timeout behavior, error/closed-port semantics, or other operational details that could affect the agent's expectation.

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 sentence with no wasted words. The core action is front-loaded, and the clarifying exclusion is concise and useful.

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-port connectivity check, the description is nearly sufficient, especially because an output schema exists. It lacks explicit timeout semantics and host resolution behavior, but these are relatively minor gaps 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?

Schema description coverage is 0%, and the description does not explain host, port, or timeout. The phrase 'TCP port' clarifies that port refers to a TCP port number, but no units for timeout, host format, or range constraints are provided, so the description adds little beyond 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 uses a specific verb ('check'), a clear resource ('TCP port'), and a defined method ('plain socket connect'), making the tool's purpose immediately understandable. The explicit exclusion 'no port scanning' helps distinguish it from broader network-scanning tools and sibling diagnostics.

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

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

The description clearly indicates the tool is for checking whether a single TCP port is open, which gives strong contextual guidance for when to select it. It also explicitly excludes port scanning, but it does not name sibling tools or state when to prefer alternatives like http_check or ping_host.

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

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

With no annotations, the description carries the full burden. It honestly conveys that this is a read-only network fetch and lists the returned certificate aspects. It does not disclose edge behavior such as whether the cert chain is validated, what happens with expired/cinvalid certs, or failure modes, but for a simple fetch/report tool the disclosed behavior is reasonably transparent.

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 states the operation first and then the output scope. There is no filler or repetition, every phrase 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?

The tool has only two parameters, one of which has a default, and an output schema exists, so the description does not need to enumerate return values. It covers the core operation but lacks explicit usage guidance and parameter conventions, making it minimally viable rather than richly complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify that the tool connects to 'host:port', giving meaning to both parameters. However, it does not explain host format, port range, or relationship to the default port, leaving most parameter detail to the schema's names and default.

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

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

The description states a specific verb ('Fetch'), a concrete resource ('the TLS certificate presented on host:port'), and the reported fields (subject/issuer/validity/SANs). This clearly distinguishes the tool from sibling network checks like tcp_port_check or dns_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: call this when you need TLS certificate details rather than just connectivity or DNS information. However, it does not explicitly state when not to use it or name an alternative tool, so the guidance is implicit rather than explicit.

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

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

With no annotations provided, the description carries the full burdin of behavior disclosure. It adds useful behavioral constraints: the tool runs `mtr --report` in fixed cycles (not live) and clamps cycles to 1-10. However, it does not mention that it relies on an external mtr command, potential permission/network requirements, timeouts, or result interpretation beyond 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?

Very concise: a single sentence that fronts the core purpose and then adds a key behavioral constraint. Every phrase earns its place 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?

For a simple two-parameter tool with an output schema, the description provides the core function and a parameter constraint. However, it omits operational details that an agent would need, such as whether the tool depends on an external mtr binary, what network protocol it uses (ICMP/UDP), and potential timeout or failure behavior. These are not covered by annotations either.

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 0%, so the description must compensate. It provides meaningful semantics for the `cycles` parameter by noting it is clamped to 1-10 and implies a fixed-cycle behavior. The `host` parameter is self-evident from the tool name and purpose. No detail on default values or special formats, but the essential meanings are conveyed.

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

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

States a specific function (Path/MTU-style hop report) via `mtr --report`, which clearly indicates a network path tracing/mtr tool. It is distinguishable from sibling tools like ping_host and dns_lookup by the focus on hop-level path reporting. Lacks an explicit verb like 'traces' or 'generates', but the noun phrase plus the mtr reference is clear enough.

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 siblings like ping_host or health_check. The only contextual hint is 'fixed cycles, not a live run', which distinguishes it from an interactive/live traceroute but does not explain when an agent should choose this tool over alternatives.

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

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

No annotations are present, so the description carries the full burden of disclosing behavioral traits. 'Lookup' implies a non-mutating network query, but the description does not mention rate limits, failure behavior, network dependency, or whether WHOIS data may be redacted or aggregated.

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 short sentence with no wasted words, which is structurally clean. However, it is so sparse that it reads more like under-specification than a deliberately complete, well-structured help entry.

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 that the tool has only one required parameter and an output schema exists, the minimal description is close to viable. Still, it lacks input-format guidance and any usage context relative to the sibling tools, leaving an agent to guess at correct invocation 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 description coverage is 0%, so the description needed to compensate. It only repeats that the operation is 'for a domain' without adding format constraints like whether a bare domain is required, whether URLs/schemes are accepted, or whether IDN/punycode handling is supported.

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 ('lookup') and resource ('domain') and names the WHOIS protocol, which distinguishes it from sibling tools like dns_lookup and tls_cert_check. It is clear, though minimal, and does not elaborate on what WHOIS data is actually returned.

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 about when to use this tool versus any of the sibling tools. It does not mention alternatives, exclusions, or typical use cases such as registrant/registration-status investigations, so the agent must infer applicability from the sibling names alone.

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