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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context by noting the selector sourcing limitation and the fallback to common selectors. This goes beyond the annotations, though it doesn't describe error handling or response shape, which is acceptable given the output schema exists.

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, no fluff. The first sentence front-loads the core function and output details; the second provides a crucial usage hint. 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?

For a read-only lookup with an output schema, the description covers purpose, selector sourcing, and parameter behavior. It omits explicit alternative routing, but the domain-specific nature and sibling names make it sufficiently complete for an agent to invoke 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 50%: the domain parameter is described in the schema, but the selectors array items are not. The description compensates by explaining that selectors are optional and default to 30 common provider selectors, clarifying the semantic role of the selectors parameter beyond the raw schema.

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

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

The description clearly states the tool's function: it looks up DKIM keys at specified selectors, detailing the key attributes it returns (type, size, flags, problems). It distinguishes itself from siblings like check_spf (SPF-specific) and dns_lookup (generic DNS) by focusing on DKIM and its selector-based 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 important usage context: it explains that selectors cannot be discovered via DNS and must come from a sent message's DKIM-Signature header. It also mentions the fallback to 30 common provider selectors when none are given. However, it doesn't explicitly compare to alternatives like check_spf or dns_lookup, though the domain-specific nature makes it clear enough.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral detail beyond that: it discloses that DNS lookups are checked against the limit of 10, that void lookups and syntax are examined, and that a provided IP changes the result to what a receiver would see. No contradictions.

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

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

A single, front-loaded sentence that packs in every meaningful detail without fluff. Each listed element (include tree, DNS lookups, void lookups, syntax, result, mechanism) contributes directly to understanding tool behavior.

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

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

Given the annotations already cover safety and the output schema presumably documents return values, the description is nearly complete. It fully scopes what is evaluated and the effect of the IP parameter. The only real gap is the sender parameter, which is left unexplained in both schema and description.

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 covers 2 of 3 parameters (domain and ip), leaving sender undescribed. The description adds meaning to ip ('with ip the result a receiver would reach') and implies domain as the target, but does not explain sender's role at all. It partially compensates for schema gaps but not fully.

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 ('Evaluates') and resource ('a domain's SPF'), then enumerates exactly what 'in full' means: include tree, DNS lookup count, void lookups, syntax, and the receiver result with an IP. This clearly distinguishes it from sibling tools like check_dkim 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 purpose is obvious from the name and description, but there is no explicit guidance about when to use this tool versus alternatives such as check_dkim or dns_lookup. No exclusions or alternative recommendations are given; usage is only 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds significant behavioral detail beyond annotations: it names Cloudflare as the resolver, explains that compare:true queries Google's resolver and flags propagation differences, and states that DNSSEC validation status is reported. These are concrete behaviors an agent needs to interpret results correctly, and there is 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 two sentences with no wasted words. The core action and default types are front-loaded, followed by the optional compare behavior and DNSSEC note. Every clause adds value, and the structure is highly readable for an agent scanning quickly.

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

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

An output schema exists, so return-value structure is already defined. The description covers the essential behavioral facets: record types, TTLs, resolver, comparison mode, and DNSSEC validation. For a read-only, idempotent DNS lookup tool, this is complete—nothing an agent needs to invoke 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?

With schema description coverage at 0%, the description must carry the burden for parameters. It explains the 'types' parameter by listing the default set (A, AAAA, MX, NS, TXT, CAA) and the 'compare' parameter by describing its boolean effect (query Google and flag differences). The 'name' parameter is implicitly clear from 'of a name'. It does not enumerate all possible types from the enum, but that is not required; it adds meaning beyond the bare 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 states the operation precisely: retrieving DNS records of a name by type, listing the default types (A, AAAA, MX, NS, TXT, CAA), and adding unique features like TTLs, resolver source, comparison, and DNSSEC status. This clearly distinguishes it from sibling tools like check_dkim and check_spf, which focus on email authentication, and domain_lookup/report which are broader domain queries.

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 makes the tool's purpose unambiguous—querying DNS records—so an agent can infer when to use it. However, it does not explicitly state when not to use it or mention alternatives (e.g., for DKIM/SPF checks use check_dkim). It gives clear context but no exclusions, which aligns with a 4.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context: it queries each registry's RDAP server, handles up to 20 domains, and resolves subdomains to their registrable domain. 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 dense sentence, front-loaded with the core action and a colon-separated list of returned data. It is compact with no filler, though the subdomain behavior is tacked on at the end without a clear structural break.

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 read-only nature, an output schema exists (so return values are covered), and annotations handle safety, the description is largely complete. It still lacks guidance on error scenarios and sibling differentiation, but covers core behavior and input constraints well.

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 carries the burden for parameter meaning. It explains that the 'domains' array accepts domain names, that subdomains are normalized to registrable domains, and that up to 20 are allowed. This adds value beyond the raw schema constraints.

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 the tool retrieves registration/availability data from RDAP, listing specific fields like registrar, dates, DNSSEC, and name servers. It is clear enough to distinguish from sibling tools (check_dkim, check_spf, dns_lookup), though 'Registration of' is slightly awkward phrasing and not an explicit verb like 'retrieves'.

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 is given about when to use this tool versus alternatives like dns_lookup or domain_report. The description implies a registration-info use case but does not state when to prefer it, what scenarios it should not be used for, or how it differs from 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds meaningful behavioral context by explaining the scope of the health check, that it aggregates many checks into one call, and that output includes ranked findings and fixes.

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, tightly packed sentence that front-loads the tool's purpose ('One-call health check') before listing the included checks. Every item in the list earns its place, and there is no filler or redundant phrasing.

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 required parameter, full schema coverage, a rich output schema, and comprehensive annotations, the description covers the tool's scope and expected output thoroughly. Nothing critical for selecting or invoking the tool 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%, so the single 'domain' parameter is already fully documented with format and example. The description only restates that it operates on a domain and adds no new parameter-level meaning, 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 begins with a specific verb phrase 'One-call health check of a domain' and enumerates a precise list of checks it performs, ending with the deliverable 'ranked findings and fixes.' This clearly distinguishes it from the more granular sibling tools like check_dkim, check_spf, dns_lookup, and domain_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 phrase 'One-call health check' strongly implies using this tool when a comprehensive domain and email setup review is needed, versus using the narrower sibling tools for individual checks. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to route correctly.

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