isitdns

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds genuine value beyond that by enumerating how the chain terminates: addresses, none, resolver failure, NXDOMAIN (dangling), a loop, or an inside name, which tells the agent what to expect from a traversal.

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

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

Two sentences, zero filler, with the usage condition front-loaded and the return semantics following immediately. Every clause 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?

With no output schema, the description carries the burden of describing results and does so via the termination taxonomy. It omits depth limits, resolver choice, and timeout handling, but for a single-parameter read-only tracer it is close to 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?

There is a single parameter with 100% schema description coverage, and the schema itself documents the domain alias and URL-as-host behavior. The description adds no further syntax or format detail beyond the schema, so the 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 states a specific verb and resource: follow a name that is a CNAME and return each hop with target and TTL. It implicitly distinguishes itself from siblings like dig or check_domain by framing the task as chain-following, so an agent can select 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?

"Use when a name is a CNAME and the person asks where it leads" gives a clear triggering condition. It stops short of naming when-not-to-use cases or explicit alternatives (e.g., use dig for a single lookup instead), so it falls one step below full routing 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 read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine value by describing the response shape: a first line on resolution, then eleven rows labeled ok/warn/fail/skipped with reasons — useful given there is no 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?

Two tight sentences with the trigger condition front-loaded and the output contract in the second. Nothing is padded or repeated from structured fields.

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 no output schema, describing the return format is exactly what is needed, and it does so. Parameter and safety context come from schema and annotations, leaving only the absence of explicit sibling routing as a minor 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?

Schema coverage is 100%, so both parameters are already documented, including the "domain" alias and URL-as-host behavior. The description adds no parameter-level detail beyond the schema, 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?

States a specific resource and what the tool produces: resolution status plus an eleven-check zone audit. An agent can tell this is a composite diagnostic rather than a raw query like dig, even though no sibling is named explicitly.

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?

"Use when a domain or website is not working or not resolving (is it DNS?)" gives a clear triggering condition. It stops short of stating when to prefer a sibling such as dig or trace instead.

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

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

Annotations already declare readOnly, idempotent and openWorld, so safety is covered. The description adds genuine context beyond them: the returned fields (records, flags, rcode, EDE, latency) and the transport distinction (DoH from the edge vs Do53 from a region probe via 'from'). It omits rate limits or failure behavior, so not 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 sentences with zero padding, and the usage guidance is front-loaded before the output details. Every clause carries information an agent needs.

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 no output schema and 10 parameters, the description does well to summarize the return payload and the edge-vs-probe behavior. It never explains resolver='all' or the interaction between dnssec/cd, but the 100% schema coverage absorbs most of that 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?

Schema description coverage is 100%, so every parameter including the resolver board list is already documented in the schema, setting the baseline at 3. The description only adds meaningful color to the 'from' parameter (regional probe / Do53), leaving resolver, family, type, dnssec and the boolean flags entirely to 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?

States a specific action (one exact question to one public resolver) and the resource (DNS records), which is clearly distinct from diagnostics suites like trace or alias_chain. It does not name a sibling directly, but the scope is unambiguous enough to route correctly.

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 gives both when to use (a single exact lookup) and when not ('not as the first call for a site that is not working'), which steers agents away from it for broad diagnostics. It stops short of naming the alternative sibling (e.g. check_domain or trace) that should be called first.

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 readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real value beyond that by disclosing the return semantics: each signed zone cut from root to answer, the first broken link, and where the chain goes insecure.

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 tightly written sentences: the first gives the trigger, the second gives the output shape. No filler, and the usage condition is front-loaded before the return description.

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, so the description must carry the return contract, and it does: it explains that the result is an ordered list of zone cuts plus the failure/insecurity point. It could say more about how the cut records are formatted, but it is sufficient to call the tool correctly.

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

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

Schema description coverage is 100%, so both the name (including domain/URL-host acceptance) and the record type default are already documented in the schema. The description adds no parameter-level syntax or constraints beyond that, 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?

States a specific verb (walk) and resource (DNSSEC chain) and further defines the scope as the zone cuts from root to answer. This clearly separates it from siblings like dig, trace, or check_domain, which do not perform validation-path 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?

Gives explicit trigger conditions: use when a name fails validation or the user asks whether its DNSSEC chain holds. It does not name an alternative tool to use instead for non-DNSSEC lookups, but the diagnostic framing makes the boundary against dig/trace clear.

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 cover safety (readOnly, openWorld, non-idempotent, non-destructive), so the bar is lower. The description adds genuinely new behavior: a nonce-based two-phase protocol where the first call yields a dig to run and the second returns observed resolver details plus a signed TXT. It doesn't mention rate limits or auth requirements.

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?

Compact and front-loaded: the when-to-use condition leads, followed by the two-call sequence. The parenthetical field list is dense but each item earns its place as return-value preview.

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 no output schema, the description usefully enumerates what the second call returns (resolver address, transport, DO/CD flags, EDNS size, cookie, ECS, case, arrivals, signed TXT) and explains the two-phase flow. Only the first call's output (the dig command) is left slightly 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% and both the schema and description say the nonce comes 'from the first call', so the description adds no syntax or format detail beyond the structured field. Baseline 3 for a fully documented single 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 purpose: proving what the resolver sends, and outlines the two-call flow. It hints at a difference from plain dig/trace by framing it as a 'receipt', but never names a sibling to differentiate against.

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?

'Use when the person wants proof of what their resolver sends' gives a clear triggering condition, and the two-step ordering is spelled out. It stops short of saying when to prefer this over dig, trace, or alias_chain.

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 readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds genuinely useful behavioral content the annotations can't: the response shape (statuses plus their resolution meaning, dates, nameservers) and a deliberate omission (no contacts), which matters since there is no 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?

Two sentences, front-loaded with the usage trigger and followed by the return scope. No filler, no repetition of the title or annotations.

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 no output schema, the description carries the return-value burden and does so reasonably well (statuses, their resolution implications, dates, nameservers, absence of contacts). It does not mention behavior for unregistered/nonexistent domains, which is the one gap for a 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?

Schema coverage is 100% and the single parameter's description already explains the domain/hostname/URL and "name" alias handling. The description adds no syntax or format detail beyond that, so the 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?

States a specific verb+resource (returns the registry's RDAP statuses, dates and nameservers for a domain) and explicitly scopes what it does not return ("no contacts"). An agent can distinguish this registry-level RDAP lookup from the DNS-oriented siblings (dig, check_domain, trace) without opening a 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?

Gives a concrete trigger: "when a domain has vanished from DNS and the person asks whether it expired or is on hold." That clearly separates it from live-resolution tools, though it never names a sibling alternative explicitly, so it stops short of the 5 bar.

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 cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's job is to add behavioral context — which it does by enumerating return categories: per-server answers, disagreements, lame or silent servers, and CAA/ACME readiness. It doesn't discuss timeouts or rate limits against the many servers queried, but the added detail is substantive.

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

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

Two sentences with no waste: the first front-loads the usage condition, the second enumerates the return content. Nothing is repeated or padded.

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 no output schema, the description carries the burden of describing returns and does so adequately, and annotations cover safety. Missing only edge-case behavior for large sweeps (timeouts, partial results), which is minor for this tool.

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

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

Schema description coverage is 100%, so the schema already documents names, types, and domain including defaults and the '@' apex convention. The description only alludes to 'each name and type you list' without adding format or constraint detail beyond the schema, so the 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?

States a specific verb and resource ('sweep a domain across its authoritative servers') and clarifies the output is a per-nameserver comparison, which implicitly separates it from single-query siblings like dig and trace. It stops short of naming any sibling explicitly, so an agent must infer the distinction.

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?

Gives an explicit trigger: 'Use after a zone change, when the person asks whether the authoritative servers agree.' That is clear context for selection. It does not state when not to use it or name an alternative (dig, check_domain), 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 establish readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds genuine behavioral value beyond that: it discloses the output contents (each referral and glue, lame or unreachable servers, final answer, verdict), which compensates for the absent 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?

A single dense sentence that front-loads the usage trigger before the behavior and return details. Nothing is redundant, though the return-value list is packed in tightly rather than broken out.

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 no output schema, the description usefully enumerates what a trace returns and gives the invocation trigger. It omits operational expectations (traces are slow/network-bound) and the meaning of the verdict, leaving minor gaps for a complex multi-hop diagnostic.

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

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

Schema description coverage is 100%, so both parameters (name, type) are already documented in the schema, including the "domain"/URL-host aliasing and the type default. The description adds no further parameter 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?

States a specific verb and resource (walk the delegation for a name) with explicit scope (root to authoritative) and anchors it to a well-known command (dig +trace). The analogy cleanly distinguishes it from the sibling `dig` (single query) and `dnssec_chain` (validation chain).

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?

"Use when the person wants to walk the delegation for a name" gives a clear triggering condition. It does not, however, name alternatives or exclusion cases (e.g. when to prefer plain `dig`, `check_domain`, or `dnssec_chain` instead), so the routing guidance stops short of 5.

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