dns

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered. The description adds value by specifying the return payload (drift classification, score delta, lists of improvements/regressions) and clarifies the baseline 'cached' reuse, without contradicting 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?

Three sentences with clear information architecture: purpose, output, usage/alternatives. No wasted words; 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?

No output schema exists, but the description covers the return values. It also explains when to use the tool and the key baseline parameter behavior (via schema), making it sufficiently complete for a moderate-complexity tool.

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

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

Schema description coverage is 100%, with detailed per-param explanations (e.g., baseline's 'cached' literal and exclusion of policy objects). The description itself doesn't add parameter-level semantics beyond schema, so a 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 states the tool measures DNS security posture change against a prior snapshot, using specific verbs and resources. It explicitly distinguishes from compare_baseline by contrasting improvement-over-time vs compliance-to-policy, differentiating it from a key sibling tool.

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

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

Provides an explicit use case ('did our security score improve or regress since last time?') and an explicit exclusion (not for compliance checks — use compare_baseline instead). The baseline parameter schema reinforces this with 'NOT a policy/requirements object — for compliance enforcement against required controls, use compare_baseline 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?

With annotations already declaring readOnlyHint=true, idempotentHint=true, and destructiveHint=false, the description adds value by explaining how the score is computed (combining SPF trust surface, DMARC enforcement, DKIM coverage) and what outputs to expect (risk level, sub-scores, plain-language summary). This goes beyond annotation coverage and helps set expectations.

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 repetition of schema content, and the most important information (what the tool does and its output) is front-loaded. Every phrase serves a purpose, with the usage note placed last as a natural call to action.

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 no output schema, so the description's explanation of returned data (risk level, sub-scores, summary) is valuable. It covers the core behavior and usage context. Minor gaps like handling of invalid domains or network-only data sources exist, but they are not critical for a read-only, idempotent 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 baseline is 3. The description doesn't add parameter-level details beyond what the schema already provides (domain, format, force_refresh). It doesn't harm, but it also doesn't compensate further.

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 starts with a specific verb ('Compute') and clearly names the resource ('composite email spoofability risk score'), including the 0–100 scale and direction. It explicitly distinguishes itself from sibling tools like check_spf, check_dmarc, and check_dkim by framing this as a combined/composite assessment rather than a single-control 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 gives explicit usage triggers: 'Use when asked how easy it is to spoof email from a domain, or for a composite email spoofing risk score.' It implies alternatives (individual control checks) exist among siblings but does not name them or state when NOT to use this tool. This is clear context but lacks 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 declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable context about version stamps (scoringModelVersion vs dnsChecksPackageVersion independence and reporting requirements for scoringConfigHash). This matches the high bar by adding meaningful behavioral disclosure 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 well-structured and the version-stamp caveat earns its place. The sentence about version stamps is useful but could be seen as overly detailed for a description, though it's essential domain context. Everything earns its place; only minor length concerns prevent a 5.

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 3-parameter tool with no output schema, the description covers the key aspects: what it does, what it returns (score, grade, finding counts), and version semantics. The description is complete for a batch list-style tool despite lacking an output schema. Slight deduction for not explicitly describing pagination or error behavior for the 10-domain limit.

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 baseline is 3 per the rubric. The description adds context about 'hoisted once per batch' version stamps and output includes score/grade/finding counts, but the parameter descriptions in the schema are already adequate. The description doesn't add meaning beyond what the schema 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 is very clear: 'Bulk-scan up to 10 domains in parallel' with specific verb+resource+scope. It clearly describes auditing multiple domains at once, distinct from sibling tool compare_domains. The 6-band letter grade explanation (A+/A/B/C/D/F) adds valuable specificity.

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 explicitly distinguishes this tool from compare_domains (side-by-side analysis of 2–5 domains), giving clear when-to-use guidance. It explains when to use batch_scan versus the alternative, which fully satisfies the usage guidelines criteria.

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 set readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description reveals that it is async, returns an immediate response with auditId and eta, and explains quota usage. With annotations covering the basic traits and the description adding async and budget details, the score is appropriately above midpoint.

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 and includes essential information: what it does, return fields, follow-up tools, and quota consumption. It is front-loaded and efficient, but could be trimmed slightly (e.g., 'caller-supplied' vs 'optional candidate domains' introduces minor redundancy). Still, it earns its keep.

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 output schema exists (implicit from the described return fields), the description properly defers return value details. The complexity is high (10 params, async flow), but the description covers the core workflow, quota, and dependencies (status/report tools). The annotation set and schema are extensive, making this description 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 100%, so the baseline is 3. The description adds semantic value by explaining the purpose of 'domains' (max 50, duplicates merged) and the meaning of optional fields like brand_aliases and candidate_domains in the context of an audit. This goes beyond what the schema provides, justifying a 4.

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 that the tool enqueues an async brand audit across up to 50 domains, with optional depth, aliases, and candidate domains, which clearly differentiates it from siblings like 'brand_audit_single' or 'brand_audit_status'. It gives a precise verb and resource with explicit scope and mode details.

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 tells how to use the tool, what it returns immediately, and how to check results (poll status, fetch report). It also mentions quota consumption. However, it does not explicitly say when NOT to use it or compare with other tools like 'brand_audit_single' for smaller audits.

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. The description adds value beyond these by disclosing the notReady polling response, the PDF sidecar metadata (pdfUrl and pdfPending), and the behavior difference with/without target. 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 concise at four sentences, each delivering essential information: core purpose with modes, polling behavior, and PDF sidecar details. No redundancy or filler, and the most critical information is front-loaded.

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, idempotent tool with two parameters and an output schema, the description covers the primary behaviors (two modes, polling, PDF sidecar). It does not discuss error codes or timeouts, but given the output schema exists and annotations cover safety, the description is sufficiently complete for effective use.

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 both parameters well-described. The description adds that omitting target yields an audit-level aggregate and setting it returns a per-target CheckResult, but this largely restates the schema's description for target. The baseline of 3 is appropriate given the schema already carries the semantic load.

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 fetches the result JSON for a completed brand audit, distinguishes between two usage modes (with target for per-target CheckResult, without for audit-level aggregate), and differentiates from sibling tools like brand_audit_status by describing the actual data retrieval behavior.

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 context by mentioning polling behavior (returns notReady for in-flight audits) and the two modes. However, it does not explicitly state when to use this tool versus alternatives like brand_audit_status or brand_audit_batch_start, leaving the agent to infer the prerequisite.

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. The description adds important behavioral context: quota gating by tier (with specific limits per tier) and the classification categories produced. It also implies that the tool may use caching (by mentioning force_refresh param in schema). 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 three sentences, front-loading the core action. It is concise and covers purpose, behavior, and constraints. However, it could be slightly more structured (e.g., breaking out quota limits) and reduces redundancy ('full brand audit' then detailing same). Still, every sentence adds value.

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 complexity (11 params, output schema exists, no nested objects), the description adequately covers the tool's purpose, outcome (classification types), and behavioral constraint (quotas). It omits mention of prerequisites like ownership_verified (important for certain tiers) and the 'view' parameter's csc_complement mode, but these are documented in the schema. Overall, provides a solid mental model for the agent.

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 detailed descriptions for all 11 parameters, so baseline is 3. The description echoes some parameters (depth, brand_aliases, candidate_domains) but does not add new semantic meaning beyond what the schema already provides. For example, the schema already explains 'depth' enum values and 'view' for csc_complement. The description contextualizes the workflow but does not enhance individual 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 clearly states the tool runs a 'full brand audit on a single target' with specific actions: discovers brand-related domains, looks up registrar/registrant, and classifies relationships into detailed categories (consolidated, shadowIt, etc.). The name 'brand_audit_single' and sibling context (e.g., brand_audit_batch_start, check_*) strongly differentiate this as the comprehensive single-target audit tool.

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

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

The description does not provide explicit when-to-use vs when-not-to-use guidance or mention alternatives like discover_brand_domains or brand_audit_batch_start. However, the description inherently implies usage for a full single-target audit, and the presence of many check_* siblings suggests this is for broad analysis. An agent can infer context from the name and description, but lacks clear directives.

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, idempotentHint, and openWorldHint. The description adds value by detailing the return format (status enum, progress 'N/M', per-target statuses) and the owner-scoping behavior (notFound for other principals). It also implies polling semantics. 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?

Two sentences that efficiently convey the core purpose, return types, and a key constraint. 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?

For a status polling tool, the description covers the essential behavior: status codes, progress reporting, per-target details, scoping, and source of auditId. Combined with the output schema (present), the agent has sufficient information to use and interpret results 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 a clear description for auditId. The description adds semantic context: the parameter must come from brand_audit_batch_start and that owner-scoping means other-owned IDs return notFound. This goes beyond the schema's basic description.

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 polls the status of an enqueued brand audit, specifying return fields (audit-level status, progress, per-target statuses). It distinguishes from siblings like brand_audit_batch_start and brand_audit_get_report by focusing on status polling, and adds owner-scoping constraints.

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 after brand_audit_batch_start (auditId from there) and notes owner-scoping behavior. It clarifies that audit IDs belonging to others surface as notFound. While it does not explicitly exclude alternatives or provide when-not guidance, the use case is clear and contextually sufficient given sibling tool names.

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, idempotentHint=true, and destructiveHint=false. The description adds value by explicitly stating 'Read-only', detailing the specific checks performed, and noting the use of Private-Use SVCB param code points pending IANA assignment. This provides behavioral context beyond the annotations, though it does not cover caching behavior or error conditions.

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 paragraph of four sentences, front-loaded with the main purpose. It is concise and packs relevant information without being verbose. It could be slightly more structured (e.g., bullet points), but it is still efficient and clear.

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 has 6 parameters (100% schema coverage), annotations, and an output schema, the description covers the key aspects: what it checks, that it is read-only, and the standard it follows. It does not detail output format (covered by output schema) or error handling, but it is complete enough for a security assessment tool of this 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add per-parameter details beyond what the schema provides, but it offers overall context (e.g., 'sweep the zone' relates to the protocol parameter). The description is adequate but does not significantly enhance parameter understanding 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 clearly states the tool assesses the security posture of IETF BANDAID agent-discovery records, listing specific checks (SVCB records, DNSSEC anchoring, DANE/TLSA binding, capability-document integrity). It includes a standard reference and uses a specific verb-resource combination ('assess the security posture of ... records'). The distinct focus on agent discovery differentiates it from sibling tools like check_dane, check_dnssec, and check_svcb_https.

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 defines the use case by stating the tool is for assessing agent-discovery security posture. It does not explicitly provide when-to-use or when-not-to-use guidance, but the domain-specific nature makes the context clear. No exclusions or alternatives are mentioned, which prevents a 5, but the purpose is sufficiently specific to guide selection.

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 read-only, idempotent, non-destructive behavior. Description adds that it uses BV_INFRA_PROBE when available and lists the evidence domains (raw DNS, routing, RPKI, vantage-point), providing useful context beyond annotations. Does not explain fallback behavior if probe unavailable, but still adds value.

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: first states purpose, second adds probe/evidence details. No wasted words, 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?

Tool is moderately complex (multiple evidence types, probe dependency). Description covers core purpose and probe usage, and output schema handles return details. Missing explicit notes on when not to use or behavior when BV_INFRA_PROBE is unavailable, but with strong annotations and schema, this is 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?

Schema descriptions cover 100% of parameters, so baseline is 3. The description does not add additional parameter-level meaning beyond what the schema already provides; it only hints at hostname scope.

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

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

Description uses specific verb 'Check' with resource 'authoritative DNS infrastructure posture', clarifying scope beyond individual DNS record checks. Mentions specific evidence types (routing, RPKI, vantage-point) which distinguishes it from sibling tools like check_ns or check_dnssec.

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 overall authoritative DNS infrastructure assessment but does not explicitly state when to prefer this tool over siblings like check_ns or check_dnssec. No exclusions or alternative tool guidance is 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?

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral detail: the a= tag limitation (VMC vs CMC not determined), the DMARC enforcement prerequisite, and the specific validation of l= and a= tags. The return behavior ('Returns findings for a missing/malformed record or unmet prerequisites') is also disclosed.

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?

Every sentence earns its place: core action is front-loaded, followed by technical detail, limitation, prerequisite, return behavior, and usage context. The structure flows logically, and despite the density of information, there is 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 moderate-complexity tool with an output schema (which removes the need to describe return structure) and comprehensive parameter definitions, the description covers validation logic, limitations, prerequisites, and use cases thoroughly. Minor gaps include no mention of network/DNS failure edge cases or interaction with the format/force_refresh parameters, but these are adequately handled by the output schema and parameter descriptions.

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 each parameter clearly documented (e.g., 'Auto-detected if omitted' for format, 'Bypass cache' for force_refresh). The description maintains the baseline 3 by not detracting from the schema but adds minimal parameter-specific value beyond it, sticking to domain-level validation context instead.

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+resource construction ('Check the BIMI brand-logo record at default._bimi.<domain>') and details exact validation logic (l= tag, a= tag, DMARC prerequisite). The scope is precisely delimited, and the focus on BIMI-specific checks (as opposed to the many sibling DNS-check tools) 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 provides clear use context ('Use to assess brand-indicator readiness in inboxes' and 'Part of the scan_domain audit'). However, it does not name alternative tools or explicitly articulate when NOT to use it, which 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?

The description adds no behavioral traits beyond what the annotations already provide (readOnlyHint, idempotentHint, destructiveHint). It does not disclose caching behavior, rate limits, or any other operational details. With annotations covering safety, the description contributes minimal behavioral insight.

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: three sentences covering purpose, function, and context. No wasted words; every sentence adds value. It is front-loaded with the core action.

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, existing output schema, and comprehensive annotations, the description is largely complete. It explains what the tool does and its role in a broader audit. It could briefly mention that it performs a DNS record check, but the name and context already imply this.

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 all parameters are well-documented in the input schema (e.g., domain format, verbosity, force_refresh meaning). The tool description does not add any additional semantic value beyond the schema, thus 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 clearly states the tool looks up CAA records for a domain, specifying the verb 'Look up' and the resource 'CAA records'. It further explains the purpose (showing which CAs are authorized) and places it in the context of 'scan_domain audit', differentiating it from other DNS check tools among siblings.

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 alternative tools like check_dnssec, check_dmarc, or others. The description only mentions it is 'Part of the scan_domain audit' but does not specify conditions or exclusions for its use.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context about MX resolution and TLSA lookup at a specific DNS label, which is useful. However, it does not explain return value structure (despite an output schema existing) or edge cases (e.g., no MX records). With annotations covering the core behavioral traits, a 3 is appropriate.

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 three sentences with no waste. It front-loads the core action and protocol details, then provides usage guidance, then distinguishes from the sibling tool. 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?

Given the presence of an output schema (which reduces the burden to explain return values), the description is complete for a focused security check tool. It covers purpose, process, and sibling differentiation. Minor gap: it doesn't mention what happens if the domain has no MX records or if DNSSEC is not available, but these are implied by the task and the tool is part of a larger audit suite (scan_domain).

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 all 3 parameters documented. The description adds value by explaining the domain parameter in the context of SMTP DANE checking and the force_refresh parameter with a usage hint ('Useful after DNS changes'). The format parameter's auto-detection is noted. This goes slightly beyond the schema baseline 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 specifies the verb 'Check', the resource 'DANE/TLSA certificate pinning for SMTP at port 25', and the exact process (resolve MX, look up TLSA records at _25._tcp.<mx-host>). It clearly distinguishes itself from the sibling tool check_dane_https by naming the alternative and the different port/protocol.

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 explicitly states when to use this tool ('when asked if SMTP connections are protected by DANE/TLSA pinning') and when to use the alternative ('For HTTPS DANE at port 443, use check_dane_https instead'). This provides clear context and exclusion 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, idempotentHint=true, openWorldHint=true. The description adds value beyond these by specifying the exact DNS lookup target (_443._tcp.{domain}) and noting the tool is part of the scan_domain audit. This extra context about scope and workflow is valuable without contradicting 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 three sentences, front-loading the main action and then providing technical detail and differentiation. It is concise with no wasted words, though slightly redundant with 'port 443' mentioned twice. A tight structure earns a high score.

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 (3 params with full schema, output schema present), the description covers the core function, DNS lookup mechanism, port, sibling differentiation, and audit context. It lacks mention of prerequisites or error cases but is sufficiently complete for an experienced agent to use 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 baseline is 3. The description does not elaborate on parameters beyond what the schema provides (domain, format, force_refresh). While the schema itself is well-described, the tool description adds no new semantics for the parameters, meeting but not exceeding the baseline.

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 verifies DANE certificate pinning for HTTPS connections using TLSA records at _443._tcp.{domain}. It explicitly distinguishes itself from the sibling check_dane (SMTP port 25), providing a specific verb and resource with differentiation.

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 names the sibling tool check_dane and explains the port difference (HTTPS vs SMTP), giving clear context for when to use this tool over that one. However, it does not provide exclusions or guidance for other related siblings (e.g., check_ssl, check_svcb_https), so the guidance is good but not comprehensive.

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, covering safety and idempotency. The description adds that results include decoded return codes, but does not disclose caching behavior, rate limits, or what constitutes a 'listing'—though the force_refresh parameter hints at caching. The description provides moderate additional context 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?

Two sentences, no wasted words. The first sentence states the purpose and target lists, the second describes the return value. Highly efficient and front-loaded.

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 description is concise but lacks details on the output structure (though an output schema exists), potential performance implications, or how 'decoded return codes' map to actual listing statuses. For a tool that queries multiple DNS block lists, it provides functional completeness but not operational depth.

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 input schema already documents all three parameters with descriptions. The tool description adds no extra meaning to parameters beyond what the schema provides. Baseline 3 is appropriate when schema fully covers parameters.

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

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

Description clearly states the tool checks domain reputation against specific DNS-based block lists (Spamhaus DBL, URIBL, SURBL) and returns listing status with decoded codes. This distinguishes it from similar tools like check_rbl, which typically check IP-based RBLs.

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 names the exact block lists, implying usage for domain reputation checks, but provides no explicit guidance on when to use this tool versus alternatives (e.g., check_rbl, check_mx_reputation). No when-not-to-use or prerequisite conditions 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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral detail: it probes common selectors, validates algorithms, and reports key strength. There is no contradiction. The description adds value beyond the annotations by explaining the internal probing and validation behavior.

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 three sentences, front-loaded with the core purpose, followed by specific capabilities and usage guidance. Every sentence 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?

Given the 4 parameters (100% schema coverage), clear annotations, existence of an output schema, and the family of sibling check_* tools, the description fully covers what the tool does, why to use it, and how it fits into the audit context. No missing information is needed 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?

Schema coverage is 100%, so the schema already describes all four parameters well. The description mentions 'probes common selectors' which adds context for the optional selector parameter, but does not significantly enhance parameter understanding beyond the schema. 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 clearly states it looks up DKIM records, probes common selectors, validates signing algorithms (RSA-1024/2048, Ed25519), and reports key strength. It distinguishes itself from the many sibling check_* tools by focusing specifically on DKIM verification.

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 says 'Use to verify that outbound email signatures are cryptographically sound' and places it as part of scan_domain audit. While it doesn't explicitly list alternatives or when not to use, the domain-specific purpose and sibling names imply when to invoke it. A small gap in explicit comparative guidance keeps it from 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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by detailing the specific DMARC fields returned (enforcement, alignment, reporting) and notes it is 'part of the scan_domain audit,' which gives context about its role. 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 three sentences with no wasted words. The first sentence states the core action and resource, the second elaborates on returned fields, and the third provides usage guidance and sibling differentiation. Information is front-loaded 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?

Given the tool has 3 parameters (all documented in schema), an output schema, and clear annotations, the description covers what is needed: purpose, output specifics, usage context, and distinguishing from related tools. The agent can confidently invoke this tool without additional clarification.

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 baseline is 3. The description does not add extra meaning for the parameters (domain, format, force_refresh) beyond what the schema already provides. It mentions 'domain' implicitly in the first sentence but offers no additional details on formatting or caching behavior. The schema itself is sufficient, so 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 action ('Look up and validate the DMARC record for a domain') and lists specific outputs (enforcement level, alignment mode, reporting destinations). It explicitly distinguishes from two sibling tools (check_shadow_domains and assess_spoofability), making the tool's 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 provides explicit use cases: 'determine a domain's DMARC enforcement level, whether it sends aggregate reports, or if it is protected against email impersonation.' It also names two distinct alternatives and explains what they check. While it does not state when NOT to use this tool, the positive guidance is strong enough for an agent to select appropriately.

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 non-destructive nature. The description adds value by specifying exactly what is checked (algorithm types, deprecated status) and what it does NOT do (check DNSSEC chain validation), which clarifies behavioral boundaries 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?

Four tightly written sentences front-load the core purpose, then detail what is reported, flag deprecated algorithms, and give usage examples. No wasted words. Achievement of conciseness without sacrificing clarity.

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 only one required parameter (domain), a detailed output schema (mentioned as existing), and full annotation coverage, the description is complete. It explains what is checked, what is reported, and what is not covered, leaving no significant gaps for an AI agent to fill.

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 baseline is 3. The description adds value by explaining that format is auto-detected if omitted and that force_refresh bypasses cache 'after DNS changes', providing context beyond schema defaults and enum descriptions.

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 ('Audit', 'Reports', 'flags') and clearly identifies the resource ('cryptographic strength of DNSKEY signing algorithms used for DNSSEC'). It lists example algorithms and distinguishes itself from sibling tools like check_dnssec (which validates chains) by stating it reports algorithm strength independent of chain validation.

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 explicit when-to-use guidance ('Use when asked what algorithm is used for DNSSEC signing keys, or if deprecated DNSKEY algorithms are in use') and implies alternatives by noting independence from DNSSEC chain checks (contrasting with check_dnssec sibling). The scope is clear: auditing algorithm strength, not validation.

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, idempotentHint, and non-destructiveHint. The description adds value by stating it validates DNSKEY and DS records, reports enablement and validation status, and mentions it checks against cache poisoning and DNS spoofing—behavioral context beyond what annotations offer. The description is consistent 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?

Three sentences, front-loaded with main purpose, then provides behavioral details, and ends with contextual note about being part of scan_domain. Every sentence earns its place with no 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 tool's moderate complexity, full schema coverage, rich annotations (readOnly, idempotent, openWorld), and presence of an output schema, the description is complete. It explains what the tool checks, how it validates, and its role in a broader audit.

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 baseline is 3. The description adds marginal value by explaining the domain parameter in context of DNSSEC check, but the schema already describes parameters well. The description doesn't add new parameter info.

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 DNSSEC status for a domain, with specific verbs like 'verifies', 'validates', and 'reports'. It distinguishes itself from many DNS-related sibling tools (e.g., check_dnssec_chain, check_nsec_walkability) by focusing on high-level DNSSEC validity and tamper-proof 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 gives clear context that this is part of the scan_domain audit, which implies use in a security audit workflow. While it doesn't explicitly say when not to use it or name alternatives, the sibling list provides strong differentiation cues. No specific usage 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond these by detailing that the tool traces DS/DNSKEY records and algorithm usage at each zone level, and implies per-zone walking. No contradictions are present (annotation_contradiction=false).

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 only two sentences long, with no filler or repetition. The first sentence front-loads the core purpose (walking the chain with specific records). The second sentence provides clear usage guidance. 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?

Given the tool has an output schema (so return values are documented), three well-documented parameters, and comprehensive annotations, the description is nearly complete. It covers purpose, scope (zone-level tracing, algorithm usage), and usage guidance. One minor gap: it doesn't mention potential time or network requirements, but that is often implied and not critical for selection. Overall, it's adequate for confident agent 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 100%, so all three parameters (domain, format, force_refresh) are already documented in the input schema. The description does not add extra semantic detail for the parameters beyond what the schema provides. A score of 3 is appropriate as the schema carries the full burden, and the description adds minimal parameter-specific value.

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 ('Walk') and clearly identifies the resource ('full DNSSEC chain of trust from the DNS root down to the target domain'), including the records traced (DS/DNSKEY) and algorithm usage. It distinguishes itself from siblings like check_dnssec (general validity) and check_dnskey_strength (key strength) by focusing on step-by-step delegation path tracing.

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 explicitly states when to use the tool: 'when asked to trace the chain of trust from the DNS root, or to see the full DNSSEC delegation path step by step.' This provides clear context. While it does not explicitly mention when not to use it or list alternative sibling tools, the usage scenario is specific enough to guide an agent.

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 non-destructive hints. The description adds meaningful behavioral detail: it performs multiple query rounds, compares IP answer sets and TTLs, and ties the behavior to botnet detection. This goes beyond the annotations and helps the agent understand the tool's operational profile 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 two sentences, front-loaded with the core purpose ('Detect fast-flux DNS behavior'), followed by a clear explanation of the method and rationale. Every sentence contributes, with no filler or repetition of schema/annotation 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?

Given the presence of an output schema and strong annotations, the description covers the essential context: what the tool does, how it works (multi-round queries), and why it matters. It does not explain return values (covered by output schema) or explicitly address edge cases like cache behavior (covered by parameter descriptions), but it is adequately complete for 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?

Schema description coverage is 100%, so the parameters (domain, format, rounds, force_refresh) are already well documented. The description adds high-level context (multiple rounds, comparison of IPs/TTLs) but does not explain individual parameters beyond the schema. Baseline 3 is appropriate given the rich 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 opens with 'Detect fast-flux DNS behavior' — a specific verb and resource that clearly states the tool's function. It further explains the methodology (multiple rounds of A/AAAA queries, IP rotation check) and distinguishes it from generic DNS tools in the sibling list.

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 implies when to use this tool (when fast-flux detection is needed) and provides context (botnet/malicious infrastructure). However, it does not explicitly name alternative tools or state exclusion conditions (e.g., when a single DNS lookup suffices), leaving some ambiguity among the many sibling DNS-check 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, and non-destructive behavior. The description adds value by detailing what headers are inspected, what issues are flagged (e.g., unsafe-inline, weak X-Frame-Options), and detection of CDN/WAF interception. 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?

The description is a single, well-structured paragraph of 4-5 sentences. It front-loads the core purpose ('Audit a domain's browser-facing HTTP security headers') and then lists specifics. Every sentence contributes useful information without 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?

Given the output schema exists, the description doesn't need to explain return values. It covers what headers are checked, what vulnerabilities are flagged, and mentions CDN/WAF detection. Combined with annotations, it provides sufficient context for a security audit 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 all three parameters. The description does not add new parameter-level context beyond the overall purpose. 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 clearly states the tool audits HTTP security headers, listing specific headers (CSP, X-Frame-Options, etc.) and their purposes. It distinguishes itself from sibling tools like check_ssl (SSL/TLS) and check_dmarc (email) by focusing on browser-facing HTTP security.

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 assessing HTTP security headers but lacks explicit guidance on when to use this tool versus alternatives like check_ssl or scan_domain. No when-not-to-use or prerequisite information is 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 establish read-only, idempotent, and non-destructive behavior. The description adds valuable context that these are 'active' domains registered by attackers and intended for phishing, which goes beyond the structured fields. It does not fully describe rate limits or cache behavior, but given the annotation coverage, the additional context justifies a score above baseline.

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 three focused sentences: purpose, technical scope, and sibling differentiation. Every sentence carries distinct value with no filler or redundancy. It front-loads the core action and immediately clarifies boundaries.

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 moderate complexity, full schema coverage, explicit annotations, and presence of an output schema, the description covers the essential context. It explains what the tool detects, why it matters (phishing), and how it differs from related tools. Additional return-value details are unnecessary because the output schema is available.

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, with each parameter (domain, format, force_refresh) already documented. The tool description does not add further parameter-level detail, but it also does not need to because the schema is sufficient. 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 ('Detect') and clearly identifies the resource: active typosquat and lookalike/homoglyph domains that impersonate a brand and could be used in phishing. It further specifies technical detail (character-substitution and visual-confusion domains) and explicitly distinguishes itself from sibling tools, making its 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 explicitly names comparator tools and defines boundaries: 'Distinct from check_shadow_domains (TLD variants with auth gaps) and discover_brand_domains (legitimate brand portfolio).' This tells the agent when to prefer this tool over alternatives and clarifies what it does not cover.

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 non-destructive behaviors. The description adds value by detailing the mechanism: queries _mta-sts.<domain>, fetches the policy file, and reports mode and MX coverage. This goes beyond the annotations but does not contradict 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?

Three sentences: first states purpose, second explains mechanism and output, third provides usage guidance and differentiation. Every sentence adds value with no redundancy, perfectly front-loaded.

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 3 well-documented parameters, an output schema, and comprehensive annotations. The description covers purpose, mechanism, output fields, and usage context, making it fully sufficient for an 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 description coverage is 100%; all three parameters (domain, format, force_refresh) are documented in the schema. The description does not add new parameter semantics beyond implying the domain is the primary input. 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 clearly states the tool checks MTA-STS enforcement for a domain, specifies the verb 'Check whether a domain enforces SMTP TLS', and distinguishes from the sibling check_dane by mentioning TLSA pinning, making the purpose specific and 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 explicitly says 'Use to verify whether inbound SMTP is protected against TLS downgrade or MITM — distinct from check_dane which uses TLSA pinning', providing direct guidance on when to use this tool and contrasting it with a closely related 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?

Annotations already indicate read-only, open-world, idempotent, and non-destructive behavior. The description adds context by explaining what the tool actually does with the MX records (identify servers and provider). It does not contradict annotations and provides useful behavioral insight 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 three sentences, front-loaded with the main action. Every sentence adds value: purpose, what it identifies, usage guidance, and context. No unnecessary words. Highly efficient.

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 complexity (3 parameters, 1 required, output schema present), the description is sufficiently complete. It explains the core function, usage scenarios, and its role in the broader scan_domain audit. The presence of an output schema eliminates the need to describe return values. No gaps identified.

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 baseline is 3. The description does not add parameter-level details beyond what the schema already provides. The description mentions 'domain' implicitly but no additional semantics for 'format' or 'force_refresh'. This is adequate given the schema's thoroughness.

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 verb 'Look up' and the resource 'MX records for a domain'. It specifies what it identifies (mail servers and email hosting provider) and provides concrete examples. It distinguishes itself from sibling tools like check_mx_reputation by focusing on the MX record lookup and provider identification. The purpose is 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 explicitly states when to use the tool: 'when asked which email provider hosts inbound mail for a domain, or to see MX record configuration'. It also mentions it's part of the scan_domain audit, providing context. However, it does not explicitly exclude other scenarios or mention alternatives, which is a minor gap.

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 the tool as read-only, idempotent, open-world, and non-destructive. The description adds behavioral context: it queries multiple external RBLs (Spamhaus, Barracuda, etc.), performs reverse DNS checks, and relies on caching (with force_refresh bypass). These are useful beyond the annotations, though it does not specify cache TTL or behavior when MX records are absent.

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 concise sentences. The first delivers the core action with specific details (RBLs, reverse DNS), and the second provides usage context and sibling differentiation. No wasted words, fully front-loaded.

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, the description doesn't need to detail return values. It covers what the tool checks (blocklists, rDNS), caching behavior, and when to use it. Minor gaps: no mention of what happens if the domain has no MX records, but the output schema likely handles that. Overall complete for a reputation check 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%, so the baseline is 3. The description adds meaning by explaining that 'domain' is used to resolve MX records and that the tool checks blocklists/reverse DNS, which gives context beyond the schema's simple descriptions. This raises the score slightly.

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 mail server MX IPs against spam blocklists and verifies reverse DNS. It explicitly distinguishes from the sibling tool 'check_rbl' by stating it targets MX hosts rather than a specific IP, leaving no ambiguity about its purpose.

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 explicit usage guidance: 'Use when you want to know if your mail server IP is blacklisted, or if your MX is on any blocklist.' It directly contrasts with check_rbl, which checks a specific IP, giving clear context for when to choose this tool over its sibling.

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 no destructive behavior, so the safety profile is covered. The description adds meaningful context: it mentions that comparison uses 'the infrastructure probe' (when available), notes specific checks (authoritative AA, glue addresses), and implies a caching mechanism (by mentioning force_refresh in schema). One minor gap: it doesn't explain output structure or what happens when probe is unavailable, but annotations and output schema mitigate this.

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 (4 sentences) and front-loaded with the core action. Every sentence serves a purpose: action+scope, inputs/checks, use cases, and context. No filler or duplication of schema 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?

Given the rich schema (3 params, all documented), strong annotations (readOnly, idempotent, non-destructive), and the presence of an output schema (not shown but noted via 'has output schema: true'), the description is complete. It explains what the tool does, what it checks, when to use it, and where it fits in the broader audit suite. No critical gaps remain.

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 the baseline is 3. The description goes beyond by explaining the tool's purpose in a way that gives meaning to the parameters: 'domain', 'format', and 'force_refresh' gain context from the audit goal. However, it doesn't explicitly document each parameter beyond what the schema already provides, so the added value is moderate.

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 starts with a specific action verb 'Audit' and clearly identifies the resource 'domain nameserver delegation and redundancy'. It distinguishes this tool from its many siblings (e.g., check_dnssec, check_resolver_consistency) by detailing what it uniquely checks: NS delegation, redundancy, DNS hosting provider, AA responses, and glue addresses. The purpose is unmistakable.

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 explicitly states when to use the tool: 'Use to detect stale registrar delegations, lame nameservers, and intermittent resolution risk.' It also positions it as 'Part of the scan_domain audit', providing context for integration. While it doesn't explicitly name alternative tools, the specific use cases naturally differentiate it from sibling probes (e.g., check_dnssec or check_fast_flux), effectively guiding agent choice.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile. The description adds value beyond annotations by specifying exactly what is detected (plain NSEC zones, weak NSEC3 parameters, opt-out flags), giving the agent behavioral insight into the analysis scope without contradicting any 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 two concise sentences that immediately state the purpose and specific detections. Every phrase ('Assess zone walkability risk,' 'analyzing NSEC3PARAM configuration,' 'Detects plain NSEC zones...') adds value 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?

Despite the tool having 3 parameters and an output schema, the description is complete enough for the given complexity. It covers the tool's purpose, key analytical capabilities, and the output schema (though not explicitly described) likely structures the detection results. The high annotation coverage and schema richness mean the description needn't elaborate further.

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 all three parameters with descriptions including domain constraints (min/maxLength), format enum, and force_refresh semantics. The description adds no additional parameter details beyond the schema, earning 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 assesses 'zone walkability risk' by analyzing 'NSEC3PARAM configuration,' with specific detections for 'plain NSEC zones, weak NSEC3 parameters, and opt-out flags.' This distinct purpose and resource distinguish it from sibling tools like 'check_dnssec' and 'check_dnssec_chain,' which focus on broader DNSSEC validation and chain verification, respectively.

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 when evaluating DNSSEC security of a zone, particularly regarding NSEC/NSEC3 weaknesses. It does not explicitly state when to use this tool versus alternatives like 'check_dnssec' or 'check_zone_hygiene,' but the specialized focus on NSEC3PARAM makes the context clear. No explicit when-not or alternative tools 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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint covering safety and idempotency. The description adds context about mail server focus and audit role, but does not elaborate on caching, rate limits, or other behavioral nuances beyond what annotations convey.

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 core action and resource. No wasted words; every sentence earns its place by defining the tool and placing it in the audit workflow.

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 and the existence of an output schema, the description adequately covers purpose and context. It lacks details on prerequisites or caching behavior, but the force_refresh parameter and annotations fill some gaps. For a straightforward DNS check, it 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?

Schema description coverage is 100%, so baseline is 3. The description adds minimal context (e.g., 'for mail servers' hints at domain use), but does not explain format or force_refresh beyond the schema's own descriptions.

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 'Verify' and clearly identifies the resource as 'forward-confirmed reverse DNS (PTR/FCrDNS) for mail servers', which is distinct from sibling check_* tools that focus on other DNS records or security aspects.

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 used within a 'scan_domain audit' and for mail servers, but lacks explicit guidance on when to prefer this over alternatives like check_dnssec or check_mx. Usage context is implied but not directly stated.

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 destructiveHint=false, so the agent knows it's a safe read operation. The description adds value by disclosing the 7 specific blocklists, the MX resolution step, and implicitly that results are cached (since force_refresh parameter exists). The description 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 extremely concise at two sentences. The first sentence states the core function, blocklist count, and specific blocklist names. The second sentence clarifies a key prerequisite (MX resolution). 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?

Given the tool has 3 parameters, 100% schema coverage, an output schema, and comprehensive annotations, the description is nearly complete. It covers purpose, RBL list, and resolution behavior. Minor omissions: it doesn't explain what format options affect or that the tool might take time due to 7 lookups. But overall, it's very complete for an RBL check tool within the sibling 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 100%, so the schema already documents parameters well. The description adds context by explaining the MX resolution process and the specific blocklists used, which indirectly clarifies the domain parameter's role. The force_refresh parameter's purpose ('Bypass cache and run a fresh check. Useful after DNS changes.') is described, though this comes from the schema description, not the main description. The description mentions the MX resolution but doesn't add syntax or behavior beyond parameter descriptions.

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 MX server IP reputation against 7 specific DNS-based blocklists (SpamCop, UCEProtect, Mailspike, Barracuda, PSBL, SORBS). It also mentions resolving MX hosts to IPs first, which distinguishes it from other check_* siblings like check_mx (which likely only resolves MX records) or check_dbl (which checks domain blocklists). The verb 'check' combined with 'reputation against 7 DNS-based Real-time Blocklists' is specific and actionable.

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 used to assess email deliverability risk by checking RBL listings. It mentions the specific blocklists checked, helping the agent understand the scope. However, it does not explicitly state when to use this tool versus alternatives like check_mx_reputation (which may check other reputation sources) or check_realtime_threat_feed. The description also lacks guidance on when not to use it, such as for domains without MX servers.

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. The description adds valuable context beyond annotations: 'Operator-deploy only' explains deployment dependency, and 'degrades to info when unprovisioned' describes fallback behavior. This gives the agent a clear picture of the tool's operational constraints and non-standard behaviors.

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 three sentences, each serving a distinct purpose: stating the core function, differentiating from siblings, and noting deployment behavior. No extraneous words or repetition. Information is 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?

Given the tool has 3 parameters (all documented in schema), a full output schema, and explicit annotations, the description covers all essential context: what the tool does, its niche among many sibling tools, and its deployment-dependent behavior. The description is sufficient for an agent to understand when and how to use it without consulting additional sources.

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 baseline is 3. The description does not add new parameter-level detail beyond what is already in the schema (e.g., 'domain' and 'format' are well-described in the schema). The mention of 'Distinct from DNSBL checks' indirectly hints at the domain parameter's role but does not significantly enhance parameter 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 explicitly states the verb 'Check a domain', the resource ('BlackVeil real-time threat intelligence'), and the context ('Distinct from DNSBL checks'). It also specifies operational constraints ('Operator-deploy only; degrades to info when unprovisioned'). This clearly defines the tool's purpose and distinguishes it from sibling tools like check_rbl or check_dbl.

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 this tool: it is an alternative to DNSBL checks for real-time threat intelligence. It also mentions that it is operator-deployed and degrades when unprovisioned, which guides usage in different environments. However, it does not explicitly list when not to use it or enumerate alternatives beyond DNSBL.

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 idempotentHint=true, and the description adds that exactly 4 public resolvers are used. However, it does not explain what 'consistency' means in terms of output or behavior (e.g., whether it reports mismatches only, or includes details).

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 and contains no wasted words. It conveys the core function quickly and clearly.

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 there is no output schema, the description should hint at what the result looks like, but it does not. The tool is simple and annotations cover safety, but the lack of return-value context leaves a gap for the agent.

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%; each parameter already has a description. The tool description adds no additional parameter semantics beyond the schema, 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 uses a specific verb ('Check') and clearly identifies the resource ('DNS consistency across 4 public resolvers'). It distinguishes this tool from sibling DNS-checking tools like check_dnssec or check_ns by focusing on cross-resolver consistency.

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 DNS consistency across public resolvers is needed, but it does not explicitly state when to choose this tool over alternatives or when not to use it. No exclusions or alternative-recommendations 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds specific behavioral context about the types of evidence checked, which is valuable but not essential beyond what annotations provide. 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, well-structured sentence that conveys the core purpose immediately. There is no redundant or extraneous 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 has an output schema (not shown but present), the description does not need to explain return values. The description covers the inputs and the verification scope adequately. One minor gap: it could clarify what 'cross-root evidence' entails, but the output schema likely 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 coverage is 100%, and the schema already describes the single parameter 'format' with its enum and auto-detection behavior. The description does not add any additional parameter information, 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 clearly states the verb 'Check' and the resource 'the DNS root server set', and lists specific evidence types (root hints, root glue, delegation, serial, DNSKEY cross-root) that distinguish it from sibling tools like check_ns, check_dnssec, and check_dnskey_strength.

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 verifying root server set integrity against official evidence, but it does not explicitly state when to use this tool versus alternatives (e.g., check_ns for nameserver checks, check_dnssec for DNSSEC validation). No when-not-to-use or alternative guidance is 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 declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context beyond these: it checks email authentication (SPF/DKIM/DMARC), looks for weak/missing auth, and mentions cache bypass via force_refresh. 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?

Two sentences with zero wasted words. First sentence states purpose with examples. Second sentence gives usage guidance and sibling distinction. Information is front-loaded 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?

Given the presence of an output schema (not shown but indicated), the description need not explain return values. It covers the tool's focus (email auth on TLD variants), differentiates from a key sibling, and addresses caching. No major gaps for a single-domain check tool with good 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 description coverage is 100%, so the schema already documents all three parameters. The description does not add per-parameter details, but it provides overall context that helps interpret the domain parameter. Baseline 3 is appropriate as the description adds no new param 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 finds 'alternate TLD variants of a domain' with weak email auth for spoofing, using specific verbs and resource. It gives concrete examples (example.net, example.co) and explicitly distinguishes itself from the sibling tool check_lookalikes, making its 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 explicitly says when to use it: 'when asked about TLD variants with email auth gaps'. It contrasts with check_lookalikes, providing clear differentiation. It does not mention prerequisites or when not to use, but the positive guidance is strong enough for 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?

The description adds behavioral context beyond the annotations: it lists outputs (IP addresses, third-party senders, syntax errors, trust surface) and mentions it is a lookup operation. Annotations already declare readOnlyHint:true, idempotentHint:true, destructiveHint:false, so the safety profile is clear. The description reinforces this but does not go deeper into details like caching behavior (force_refresh parameter is only in schema) or output structure—adequate but not exceptional.

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 concise (two sentences plus a usage note) and front-loaded with the primary action. Every sentence contributes: first sentence defines the core purpose, second details outputs, third gives usage guidance, fourth notes integration. No wasted words, though it could be slightly more compact by merging the last two sentences.

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 output schema exists and annotations are rich (readOnly, idempotent, non-destructive), the description covers all essential aspects: what the tool does, what it returns, when to use it, and its audit context. No missing information that would hinder an AI agent's ability to select and invoke this tool correctly among 70+ 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?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific details—it focuses on the tool's overall purpose. Since the schema already describes all three parameters (domain, format, force_refresh) and their roles are standard, the description adds no extra semantic value. An example of format values or the effect of force_refresh would improve this.

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 purpose: 'Look up and validate the SPF record for a domain.' It specifies the verb (look up/validate), resource (SPF record) and domain context. It distinguishes itself from siblings like 'resolve_spf_chain' and 'check_dmarc' by being focused on SPF validation, listing authorized senders, and flagging syntax errors.

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 says 'Use when you need to know who is permitted to send email as a domain' and notes it is 'Part of the scan_domain audit.' This provides clear context for when to use the tool, but it does not explicitly state when NOT to use it or mention alternatives (e.g., resolve_spf_chain for detailed chain resolution). Lack of exclusions keeps it from 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, idempotentHint, openWorldHint, and destructiveHint. The description adds value by explaining parallel probing, the specific prefixes checked, and that insecure advertisements are flagged. This provides behavioral context beyond the 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 two well-structured sentences. The first sentence delivers the core purpose and action, the second provides a usage cue. No fluff or redundancy; every sentence is earned.

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 moderate complexity (3 parameters, output schema exists, rich annotations), the description covers purpose, probing scope, parallel execution, return content, and usage context. It does not need to explain return format since an output schema is present. The description is complete for agent 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 coverage is 100% as all three parameters have descriptions. The description does not add additional meaning beyond the schema: it does not expand on domain validation, format options, or force_refresh behavior. Baseline 3 is appropriate when the schema already handles the parameter documentation.

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 starts with a specific verb 'Map' and resource 'domain's DNS-visible service footprint'. It clearly states it probes ~16 common SRV record prefixes and returns discovered services along with insecure flagging. This distinguishes it from sibling tools like check_mx or check_spf.

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 explicitly says 'Use when asked to map DNS-visible services or flag insecure service advertisements.' This provides a clear usage context. However, it doesn't mention when not to use it or suggest alternative tools for specific record types, which would improve the guidance given the many sibling check_* 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 description adds significant behavioral context beyond annotations: it warns that certificate data comes from Certificate Transparency logs and 'may differ from the one currently served.' It also explicitly states what is excluded (TLS protocol versions, cipher suites). Annotations already indicate readOnlyHint, idempotentHint, non-destructive, so the description complements them without 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 concise and front-loaded with the core purpose. It efficiently covers scope, data source caveats, and exclusions in 4 sentences. Minor redundancy: 'read from public Certificate Transparency logs' could be tighter, but overall 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 output schema exists (the score mentions 'has output schema: true'), the description does not need to detail return values. It covers key behavioral aspects (caveats, exclusions, usage). However, for a tool with 3 parameters and potential caching nuances, a brief note on default caching behavior or typical latency could strengthen 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 description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema: it mentions 'domain' implicitly through 'Check the HTTPS/TLS posture of a domain' and notes the force_refresh is 'Useful after DNS changes' in the schema itself. No new semantic insight is added beyond what the schema 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 purpose: 'Check the HTTPS/TLS posture of a domain' and lists specific checks (HTTPS reachability, HSTS policy, redirect, certificate metadata). It differentiates from siblings like check_http_security and scan_domain by mentioning it is 'Part of the scan_domain audit,' but does not explicitly distinguish from all reading-related siblings.

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 explicit usage context, e.g., 'Use to verify HTTPS/HSTS configuration and certificate issuer/expiry.' It also mentions what is NOT returned (negotiated TLS protocols), which guides agents away from expecting that data. However, it does not explicitly state when NOT to use this tool or provide alternative sibling names.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by specifying that the tool analyzes the SPF include chain, which is a specific behavioral trait not captured in structured data. 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 two sentences plus a brief note—no wasted words. The first sentence front-loads the primary purpose, followed by usage guidance in the second, and ends with the audit context. 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?

Given the existence of an output schema (specifies return values) and thorough annotations (safety, idempotency), the description covers the essential context: what the tool does, when to use it, and its role in a broader audit. It does not explain integration with related sibling tools like resolve_spf_chain, but that is not critical for basic selection.

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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for the three parameters (domain, format, force_refresh). It mentions 'SPF include chain' contextually but does not elaborate on parameter details or 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 clearly states the tool detects 'SubdoMailing risk' by analyzing the SPF include chain for dangling or hijackable subdomains. This specific verb+resource combination distinguishes it from sibling tools like check_subdomain_takeover and check_spf, which cover related but distinct concerns.

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 explicitly tells the agent when to use this tool: 'when you want to know if an SPF include chain can be hijacked through a dangling domain, or to detect subdomain mailing risk hidden in SPF includes.' It also notes it's part of the scan_domain audit, providing context. It does not explicitly name alternatives for when not to use it, but given the sibling list, the usage scope is well-defined.

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. The description adds value by explaining the sweeping mechanism (CNAMEs, 16 providers), the built-in 15-name list, caching behavior (force_refresh), and parameter constraints. 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?

Two sentences plus a concise usage note. Every sentence is purposeful: purpose, detection scope, usage context, and companion tool. No filler 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?

Given the tool's complexity (4 parameters, 100% schema coverage, output schema present, full annotations), the description is complete. It explains the built-in subdomain list, parameter customization, caching, and pairing with discover_subdomains. No critical gaps.

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%, baseline 3. The description adds meaningful context for the 'subdomains' parameter (explicit list, source, capping, dedup) and 'force_refresh' (bypass cache). The 'domain' and 'format' parameters are not enhanced beyond the schema, but the overall addition is solid.

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 specifies the action ('sweep subdomains'), the vulnerability ('dangling CNAMEs pointing to deprovisioned cloud services'), and the scope ('subdomain takeover'). It enumerates 16 provider families, distinguishing it from sibling check_* tools that focus on other security aspects.

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?

Provides explicit usage context: 'Use when asked if subdomains are pointing to deprovisioned cloud services.' Also advises pairing with discover_subdomains and notes that discover_subdomains returns a CT sample, not a full inventory. The description lacks an explicit 'when not to use' but the guidance is 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 as true, and destructiveHint as false, so the safety profile is well-covered. The description adds valuable behavioral context by mentioning 'modern transport capability advertisement' and the RFC standard. It does not contradict annotations, and complements them with the domain-specific purpose. One could argue for a 5, but the description does not detail caching behavior beyond what the 'force_refresh' parameter implies.

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 core purpose, and every sentence adds value. The first sentence defines the tool's function with RFC specificity, and the second provides organizational context. 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?

Given the tool has a clear input schema (100% coverage), comprehensive annotations, an output schema, and a straightforward domain-checking purpose, the description is complete. It does not need to explain return values because the output schema exists. The RFC reference and audit context provide sufficient richness for the agent to use the tool correctly alongside many 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?

Schema coverage is 100%, so the baseline is 3. The description adds marginal value by referencing RFC 9460 which implies the validation standard, and mentions 'part of the scan_domain audit' which contextually ties the parameters (domain, format, force_refresh) to a broader audit workflow. However, it does not elaborate on the 'format' parameter beyond the schema, nor explain how 'force_refresh' interacts with caching. Still, the high schema coverage means the schema carries the bulk of the 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 validates HTTPS/SVCB records per RFC 9460 for modern transport capability advertisement, using a specific verb ('validate') and resource ('HTTPS/SVCB records'). It also identifies the tool as part of the 'scan_domain audit', which helps distinguish it from the many sibling tools like check_caa, check_dane, and others that operate in the same domain audit context.

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 mentions this is part of the 'scan_domain audit', giving some context, but does not explicitly say when to use this tool vs alternatives like check_dane_https, check_http_security, or check_ssl. There is no guidance on when not to use it or what prerequisites are needed. The agent must infer usage from the RFC 9460 reference and the tool name.

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 annotations (readOnlyHint, idempotentHint, etc.), the description details the DNS query, validation of the reporting destination, and flagging of missing records, duplicates, or invalid URIs. This adds substantial 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 concise (3-4 sentences) and front-loaded with the core purpose. Every sentence contributes useful information without 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?

Given the tool's complexity (3 parameters, output schema, clear annotations), the description fully covers the tool's behavior, relationship to other checks, and expected outcomes. No gaps remain for an agent to understand 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 100%, so the baseline is 3. The description adds value by explaining the DNS query pattern (_smtp._tls.<domain>) and the validation of rua= mailto:/https:, which gives semantic meaning to the domain parameter beyond what the schema 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 checks for SMTP TLS Reporting (TLS-RPT) configuration by querying _smtp._tls.<domain> and validating the record. It distinguishes itself from sibling tools like check_mta_sts by explicitly noting it complements MTA-STS and is part of the scan_domain audit.

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 context by stating the tool complements MTA-STS and is part of a domain audit, which helps an agent understand when to use it. However, it does not explicitly exclude alternative tools or provide direct guidance on 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?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, indicating safe, non-destructive behavior. The description adds focus on 'stale entries' and 'SaaS exposure' but doesn't disclose caching, rate limits, or error handling. With annotations present, the description provides minimal additional 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 a single sentence with no wasted words, but it is very terse. It is not front-loaded with key usage guidance; it simply states the purpose. Still, it avoids verbosity.

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 has 3 parameters, an output schema, and 100% schema coverage, the description is too minimal. It does not explain what 'stale entries' or 'SaaS exposure' mean in practice, nor does it help the agent understand when to use this tool over similar sibling tools. The output schema exists, so return values are covered, but the overall context is lacking.

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%; the input schema already documents all three parameters with descriptions. The tool description adds no additional parameter semantics beyond what the schema 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 'Audit TXT records for stale entries and SaaS exposure' provides a clear verb (audit) and resource (TXT records), with specific purposes. It distinguishes from sibling tools like check_spf or check_dmarc by indicating a broader audit of TXT records, though it could be more explicit about differentiation.

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 such as check_spf, check_dmarc, or check_zone_hygiene. There are no prerequisites, exclusions, or context signals to help the agent decide.

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 mark this as readOnlyHint: true, idempotentHint: true, and destructiveHint: false. The description adds that it identifies sensitive subdomains and stale records, matching the read-only audit character. However, it does not disclose any behavioral nuances beyond the annotations, such as data freshness details or the fact that 'force_refresh' bypasses cache. Score is adequate but not elevated due to good annotation coverage.

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 long, front-loads the main purpose ('Audit DNS zone hygiene'), and provides concrete examples of findings (sensitive subdomains, stale SOA records, propagation issues). Every sentence adds value, with no redundancy or filler. Highly efficient.

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 a complete output schema, so return values are already documented. The description covers what the tool does and key finding categories. Given the presence of sibling tools like check_txt_hygiene and check_subdomains, it would benefit from a brief mention of how it differs from them (e.g., 'Unlike check_subdomains, this focuses on security hygiene rather than enumeration'), but as is, it is reasonably 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 100%, so the schema already documents all three parameters (domain, format, force_refresh) with descriptions. The tool description adds no additional parameter-level semantics. Baseline 3 is correct because the description does not enhance or clarify the parameter usage beyond what the schema 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 audits DNS zone hygiene, identifies sensitive or forgotten subdomains, stale SOA records, and propagation issues. The verb 'audit' and resource 'DNS zone hygiene' are specific. However, among sibling tools like 'check_subdomaining' and 'discover_subdomains', it could better distinguish itself, e.g., by noting it focuses on security posture rather than discovery.

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 specifies two use cases: finding sensitive subdomains visible in DNS and auditing overall zone cleanliness. However, it does not mention when NOT to use it (e.g., if only subdomain discovery is needed, use 'discover_subdomains') nor does it reference alternative tools. Context is implied but exclusions are missing.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful semantic context by defining 'fixed policy baseline' (compliance requirements) and excluding drift/regression analysis, which prevents misuse and clarifies the tool's scope. 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?

Two sentences, front-loaded with the core action ('Compare...'), followed immediately by usage guidance with alternative tool names. 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 has a nested baseline object and no output schema, but the description plus rich schema provide sufficient context for selection and invocation: it explains the compliance purpose, explicitly excludes drift and multi-domain comparison, and the schema fully documents parameters. A minor gap is not describing the output format, but this is partially mitigated by the 'format' parameter.

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 domain, baseline (including all nested require_* flags, max_* fields, grade/score floors), format, and force_refresh are fully documented. The description text does not add parameter-level detail, but the schema carries the burden, 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 states a specific verb+resource+outcome: 'Compare a domain's current security configuration against a fixed policy baseline to determine compliance.' It also distinguishes from sibling tools by explicitly naming analyze_drift and compare_domains for other use cases.

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?

Explicit when-to-use and when-not-to-use guidance is provided: 'Use to check whether a domain meets a policy requirement — not for tracking improvement/regression over time (use analyze_drift) and not for comparing multiple domains (use compare_domains).' The schema's baseline description reinforces this by clarifying the baseline is a policy object, not a prior scan.

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 idempotentHint=true, so the description need not repeat safety traits. It adds output details (relative scores, gaps, weaknesses) but does not disclose behavioral traits like caching, rate limits, or side effects. This matches the baseline for a description that adds some value without rich 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 two sentences, front-loaded with purpose, then output details, then usage guidance. Every sentence 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?

No output schema exists, so the description must partially explain return values. It does mention 'relative scores, category gaps, and unique weaknesses,' which is a useful summary, though not exhaustive. Annotations cover safety, and schema covers parameters. It is adequately complete for a comparison tool, but lacks a precise output format 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?

Schema coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema for domains, format, or force_refresh. The only implied semantic is the 2–5 domain limit, which is already in the schema. No compensation needed, so baseline holds.

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 verb ('comparison') and resource ('domains'), and specifies output: 'relative scores, category gaps, and unique weaknesses.' This distinguishes it from sibling tools like compare_baseline, which likely compares against a baseline rather than other domains.

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?

Explicit usage context is provided: 'Use when comparing your security posture against a competitor, or doing a head-to-head comparison between multiple domains.' However, it does not mention alternatives or when not to use it, so it falls short of the highest score requiring explicit when-not/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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral context: the tool uses Team Cymru DNS and flags high-risk hosting ASNs. This goes beyond the structured hints and informs the agent about output characteristics. 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 long, front-loads the verb and resource, and contains no filler. Every sentence adds value: the first explains the core mapping function, the second lists return fields and a notable output feature. This is an exemplary use of 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?

Given the presence of an output schema (not shown here), the description does not need to detail return values. It covers the core purpose, the data source (Team Cymru DNS), the key output fields, and the high-risk flag. The three parameters are well-documented in the schema. The description is complete enough for an agent to understand the tool's role and output, though it could briefly mention when to use the optional parameters.

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 covers all three parameters with descriptions, achieving 100% schema coverage. The description does not add any parameter-specific information beyond what the schema provides, so the baseline score of 3 is appropriate. The description's mention of output fields 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 clearly states the tool maps domain IPs to Autonomous System Numbers via Team Cymru DNS, lists the specific output fields (ASN, prefix, country, registry, organization), and mentions a unique feature (flagging high-risk hosting ASNs). This purpose is distinct from sibling tools like rdap_lookup or check_* tools, which focus on different aspects of domain security.

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 does not provide any guidance on when to use this tool versus alternatives such as rdap_lookup or osint_investigate_infrastructure_start. It lacks explicit when-to-use, when-not-to-use, or prerequisite information, leaving the agent to infer context solely from the purpose statement.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, which are confirmed by the description's 'permanently removes' and 'owner-scoped' statements. The description adds value by detailing the 'notFound' behavior for mismatched owners and that it returns confirmation, which annotations do not cover. 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?

The description is three concise sentences, each adding unique value: what the tool does, ownership scope and error behavior, and return value. No waste, front-loaded with the primary action.

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 (single parameter, clear destructive action, output schema present), the description covers the key aspects: what it does, scoping constraints, and confirmation of deletion. It could mention that the operation is idempotent (though annotations cover this), but overall it's sufficient for the agent to use correctly.

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