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 cover read-only, idempotent, and non-destructive traits. The description adds valuable context about version stamps (scoringModelVersion vs dnsChecksPackageVersion independence) and instructs to record scoringConfigHash. No contradictions. It could have mentioned caching behavior (related to force_refresh) but not required given 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?

Well-organized and front-loaded with the core purpose. The version stamp paragraph is essential to prevent misuse, so no fluff. Slightly dense but every sentence carries 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 no output schema, the description adequately explains the key return values (score, grade, finding counts). It also covers usage distinctiveness and the version gotcha. Lacks explicit response structure or error handling, but sufficient for a batch tool with rich annotations.

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

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

Schema coverage is 100% and descriptions for each parameter are present. The tool description does not add extra meaning beyond the schema—it repeats the max-10 domain limit and mentions output fields, but that's about return values, not parameters. 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 explicitly states 'Bulk-scan up to 10 domains in parallel. Runs a full security audit on each domain...' and names the return fields (score, NIST-aligned letter grade, finding counts). It also distinguishes from compare_domains, making the tool's scope clear.

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 'Use when you want to audit multiple domains at once' and notes distinctness from compare_domains, a side-by-side analysis. It does not explicitly exclude single-domain scans (e.g., scan_domain), but the guidance is sufficient for typical 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 covered. The description adds useful context beyond annotations: findings are 'owner-scoped' and the scan must be 'completed'. It does not discuss error behavior for incomplete scans, but this is a minor gap given the strong 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?

A single, dense sentence that front-loads the action, resource, scope, and precondition. Every word earns its place and there is no redundant 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?

The description covers purpose, scope, and the completion precondition, which is sufficient for an agent to decide to call this tool. Since there is no output schema, a bit more detail about the return shape or format semantics would improve completeness, but the low parameter complexity and strong annotations keep this from being a significant gap.

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

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

The schema already describes job_id, including its pattern and source, but provides no description for the optional 'format' parameter. The tool description adds no parameter-level meaning, failing to clarify the difference between 'full' and 'compact' or any default behavior. With 50% schema coverage, the description should compensate but does not.

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

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

The description uses a specific verb ('Fetch') and resource ('owner-scoped findings'), and specifies the condition 'for a completed asynchronous batch scan'. This clearly differentiates it from siblings like batch_scan_start (starting) and batch_scan_status (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 phrase 'completed asynchronous batch scan' clearly implies this tool is used after a batch_scan_start job has finished, giving solid usage context. It does not explicitly name alternatives or state when not to use it, but the timing condition is unambiguous 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?

The description adds meaningful behavioral context beyond the annotations: the operation is durable, asynchronous, returns a stable job ID, and has explicit idempotency-replay semantics conditional on principal, normalized inputs, and scoring versions. This complements the annotations (idempotentHint=false) by clarifying that replay is safe only with the same idempotency key, not a general guarantee.

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

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

Two sentences with no filler. The primary action and scope are in the first clause, and the idempotency/replay behavior is front-loaded in the second sentence. Every sentence adds necessary 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?

The description adequately covers what the tool does and the key idempotency contract, but it omits guidance on how to retrieve the scan results or monitor progress (e.g., use batch_scan_status or batch_scan_findings). Given there is no output schema, a brief mention of the job ID's role in follow-up steps would make it more 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 four parameters and their constraints. The description adds no new parameter-level detail; it only references the idempotency key's behavior, which is a behavioral note rather than a semantic explanation of the parameter values.

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 ('Start') with a clear resource ('durable asynchronous scan of 1–10 domains') and states a concrete outcome (stable job ID). It is semantically clear but does not explicitly differentiate itself from similar batch-start siblings like brand_audit_batch_start or discover_brand_domains_start, nor from the synchronous batch_scan 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 implies use for asynchronous batch scans via 'durable asynchronous scan', but it gives no explicit guidance on when to choose this over alternatives, when not to use it, or how it relates to sibling tools like batch_scan_status, batch_scan_findings, or scan_domain. No exclusions or routing hints 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, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds 'owner-scoped' and 'asynchronous', which are genuinely useful behavioral context, but it does not disclose how unknown job IDs are handled or what the status response contains.

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

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

A single sentence that front-loads the core action, resource, and scope. There is no filler or repetition of schema information, making it immediately scannable.

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 adequate for a simple status-read operation and the annotations cover safety, but with no output schema the description does not explain return values or polling/completion semantics. An agent may not know what 'status' looks like or how to interpret its result.

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 covers 50% of parameters with descriptions; job_id is well-documented with a pattern and a note that it comes from batch_scan_start, and format has a self-explanatory enum. The description itself adds no parameter-level meaning, but the critical job_id parameter is already adequately explained in 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 states a specific verb ('Read'), a clear resource ('status of an asynchronous batch scan'), and an important scoping qualifier ('owner-scoped'). This distinguishes it from sibling status tools like brand_audit_status or discover_brand_domains_status without requiring schema inspection.

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 no explicit guidance on when to use this tool versus the many sibling status tools, nor does it state prerequisites such as 'use after batch_scan_start'. Though 'batch scan' implies context, no alternatives or exclusions are mentioned.

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

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

The description discloses the async behavior, immediate return payload shape, quota cost per target, and the follow-up polling/report tools. With annotations already indicating readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, the description adds the important context that this is a queued operation and consumes budget. It does not mention specific permission requirements for enterprise tier beyond the schema's view field note, but the async and quota context is substantial.

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 the primary action and return type, then the workflow continuation and quota note. Every sentence earns its place and none repeat the schema.

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

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

An output schema exists, so return values need no further explanation; the description covers the async handoff, quota consequence, and sibling tools. It could be more complete by noting that tiered discovery requires ownership_verified for non-enterprise callers, but that is already detailed in the input schema.

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 valuable semantic context by explaining the async workflow, the returned envelope fields, and quota consumption. However, it does not expand on the meaning of less-common parameters such as planner_mode or discovery_mode beyond their schema descriptions, so it doesn't quite reach a 5.

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 ('Enqueue'), a resource ('an async brand audit'), and key scope constraints ('up to 50 target domains' with optional discovery layers). It also names sibling tools for status and report retrieval, so an agent can distinguish this start action from brand_audit_status and brand_audit_get_report.

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 routes the agent to poll with brand_audit_status and fetch results with brand_audit_get_report, providing a complete start→poll→fetch workflow. It also notes quota consumption, which helps agents decide whether to invoke this tool versus a cheaper or single-domain alternative such as brand_audit_single.

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 read-only, idempotent, and non-destructive, so the base requirement is met. The description adds valuable behavioral details beyond annotations: 'notReady' polling semantics, 'pdfUrl' being an authenticated download link requiring the same bearer credential, and 'pdfPending' for rendering state. This is meaningful supplementary information that helps the agent handle edge cases correctly.

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 dense sentences, each earning its place. The first establishes the core function, the second covers parameter behavior, and the third handles edge cases (notReady, pdfUrl, pdfPending). No filler, 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 output schema exists Rodríguez, the description appropriately covers runtime behaviors not in the schema: polling (notReady), authentication for pdfUrl, rendering status (pdfPending). This is complete for a tool with two parameters and a rich output contract.

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

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

Both parameters are 100% documented in the schema, so baseline is 3. The description enhances this by clarifying the semantic distinction: `target` yields per-target CheckResult, while omitting it yields audit-level aggregate. It also explains the meaning of the returned statuses (notReady, pdfUrl, pdfPending), adding value beyond the schema's bare field definitions.

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: 'Fetch the result JSON for a brand audit.' It clearly distinguishes this tool from siblings (e.g., brand_audit_status, brand_audit_batch_start) by focusing on retrieving results. The dual mode (per-target vs. aggregate) is explicit, removing ambiguity about what the tool returns.

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 states when to use it (for completed audits) and explains the behavior of the optional `target` parameter eagerly. It implicitly signals not to use it for in-flight audits by mentioning 'notReady' polling. However, it does not explicitly name alternative tools (e.g., brand_audit_status) for checking status, so a bit more exclusivity would push it to 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 flag safe, read-only, idempotent behavior. The description adds meaningful non-obvious behavior: it discovers domains, performs registrar/registrant lookups, and classifies relationships, and it discloses tier-wide monthly quota gating with exact limits. This exceeds what annotations alone 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?

The description is three dense sentences with no filler: purpose first, process second, quota gating third. Every sentence earns its place, though 'shadowIt' appears to be a minor spacing typo.

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?

Combined with a rich output schema, full parameter descriptions, and safety annotations, the description covers the tool's purpose, pipeline, classification outcomes, and quota constraints. It does not describe async/report flows or all discovery-mode caveats, but those are largely carried by sibling names and the schema.

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?

All 11 parameters have schema descriptions, so the baseline is 3. The description names depth, brand aliases, and candidate domains but does not add semantic detail beyond the schema; the schema remains the primary source for parameter 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 opens with a specific verb and resource: 'Run a full brand audit on a single target,' and it names optional inputs (depth, aliases, candidate domains) plus the concrete output classification categories. This clearly distinguishes it from discovery-only and batch siblings by emphasizing 'single target' and 'full brand 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 phrase 'single target' and 'full brand audit' imply this is for one-target comprehensive audits, and the quota note tells when it may be blocked, but no alternatives are named or excluded. There is no explicit guidance on choosing this over brand_audit_batch_start or discover_brand_domains.

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=true and destructiveHint=false. The description adds genuine value by disclosing the owner-scoping edge case ('auditIds owned by other principals surface as notFound') and previewing the return shape (audit status, 'N/M' progress, per-target statuses). 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 tightly-written sentences with every clause earning its place. The first sentence front-loads the verb and purpose; the second packs return-shape details and a critical scoping edge case into a single clause. Zero fluff or repetition.

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

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

For a single-parameter polling tool with an output schema, the description covers all key aspects: purpose, async lifecycle, return shape, and the ownership-related notFound edge case. Given the available schema context and annotations, there are no material gaps that would prevent an agent from using this 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?

Description stays at the schema's 100% coverage level. The auditId parameter is fully documented in the schema ('Audit ID returned by brand_audit_batch_start'), with the description adding only the word 'enqueued' as extra context. Schema does the heavy lifting, 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 opening verb-noun pair 'Poll the status of an enqueued brand audit' precisely defines the operation with a specific verb (poll) and resource. It clearly distinguishes itself from sibling tools like brand_audit_single, brand_audit_batch_start, and brand_audit_get_report, making the tool's role in the async workflow 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 establishes clear context: 'Poll the status of an enqueued brand audit' implies usage after brand_audit_batch_start initiates work, and the 'queued | running | completed | failed' state machine signals when it applies. However, it doesn't explicitly name alternatives or state when NOT to use it (e.g., vs. brand_audit_get_report).

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

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

Annotations already declare read-only, idempotent, non-destructive behavior knee. Description adds substantial behavioral context: it reports on DNSSEC anchoring, DANE binding trust, and capability-document integrity, and notes the use of private-use SVCB parameter codes pending IANA assignment (a caveat about potential instability). These details meaningfully exceed the annotations, so a 4 is warranted.

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 dense sentences front-load the purpose and then list the key checks. Every sentence adds value: purpose, detection scope, and read-only note. It is not overly long, though it packs a lot of technical detail. Slightly above average due to efficiency and prioritization.

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 niche protocol tool, this description covers the essential aspects: what records it looks for, what security properties it evaluates (DNSSEC, DANE, capability integrity), and the current standardization status (pending IANA). Combined with a detailed schema and output schema, an agent has sufficient context to select and invoke this tool appropriately.

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

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

The input schema already provides detailed descriptions for all 6 parameters (100% coverage), including format, protocol, domain, and verify_cap. The description adds some contextual nuance (e.g., 'reports whether the discovery zone is DNSSEC-anchored' ties protocol to the indexing) but largely complements the schema rather than adds new meaning. Baseline of 3 is appropriate.

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

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

Description uses specific, concrete language: 'Assess the security posture of IETF BANDAID agent-discovery records (draft-mozleywilliams-dnsop-dnsaid).' It names the exact resource type (SVCB agent records), the naming convention (_agents/_index._{protocol}._agents), and distinguishes itself from the generic DNS-check siblings (check_dnssec, check_dane, etc.) by focusing on a specific draft spec. 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 explains the specific technical context but never explicitly states when to use this tool over alternatives or when NOT to use it. It is clearly specialized for IETF BANDAID agent-discovery records, but no exclusions or comparisons to sibling tools are given. Given the niche focus, the intended use case is inferable, but explicit guidance would be stronger.

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, openWorld, and non-destructive behavior. The description adds meaningful context beyond those annotations by revealing the underlying BV_INFRA_PROBE dependency and the evidence categories (raw DNS, routing, RPKI, vantage-point), which helps the agent understand the tool's data acquisition 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?

Two tight sentences. The first states the purpose, the second names the key data-source detail. No filler, no redundancy, all content 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 output schema exists, the description does not need to explain return values. It covers purpose, scope (authoritative DNS infrastructure), and evidence source. It is slightly less complete than ideal because it omits what the 'posture' result means or how it relates to the many sibling DNS tools, but the schema and annotations fill most 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 description coverage is 100%, and each parameter (domain, format, force_refresh) has a helpful description. The tool description adds no parameter-specific meaning, but the schema already carries that burden sufficiently, 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?

Description clearly states a specific verb+resource: 'Check authoritative DNS infrastructure posture for a hostname.' This distinguishes it from sibling tools that check individual DNS records (MX, SPF, NS, etc.), though it does not explicitly name the distinction.

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

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

No guidance on when to use this versus alternatives. The sibling list contains numerous focused DNS checks (check_ns, check_dnssec, check_dnssec_chain), and the description could have indicated this is the comprehensive posture check while those are for specific record types, but it does not.

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 readOnly/idempotent/non-destructive annotations, the description explains what is actually validated, the limitation that the certificate type is not determined from the bare a= tag, the DMARC enforcement prerequisite, and that findings cover missing/malformed records or unmet prerequisites. This adds meaningful behavioral context 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, starts with the core action and target, and every clause adds value: validation logic, limitation, prerequisite, returned findings, and use case. 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 annotations describe safety, the schema fully documents parameters, and an output schema exists, the description provides sufficient behavioral detail: exact record, fields validated, limitation, prerequisite, and outcome types. Nothing critical is missing for an agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents domain, format, and force_refresh. The description adds domain semantics by specifying the lookup at default._bimi.<domain>, but it does not add further detail on format or force_refresh beyond the schema.

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

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

The description names a specific resource (default._bimi.<domain>), a precise action (check/validate), and the exact fields validated (l= and a=), while also verifying the DMARC prerequisite. This clearly distinguishes it from the many other DNS/record checking siblings like check_dmarc or check_tlsrpt.

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 to use it 'to assess brand-indicator readiness in inboxes' and notes it is 'part of the scan_domain audit,' providing clear context. It does not name alternatives or state when not to use it, but the use case is unambiguous 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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the domain-appropriate semantics (shows which CAs are authorized) but does not elaborate on caching behavior or output format, which would be useful given the force_refresh and format parameters.

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

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

The description is two sentences with no filler. The first sentence states the action and resource, the second clarifies the result's meaning, and the third positions the tool within the scan_domain audit. Every sentence earns its place.

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

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

For a simple, read-only DNS lookup tool with a fully documented schema, annotations, and an output schema, the description is complete. It covers the tool's purpose and context without needing to explain return values or parameter details.

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

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

The input schema provides 100% coverage of all three parameters with descriptions, so the baseline is 3. The tool description does not add extra parameter semantics beyond mentioning 'domain' in prose, but the schema already handles parameter documentation adequately.

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 ('Look up') and identifies the exact resource ('CAA records for a domain'), clearly distinguishing it from sibling check_* tools that target other DNS record types. The added context about Certificate Authorities further clarifies the tool's 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 clear context by noting it is 'Part of the scan_domain audit,' implying when it fits into a broader workflow. It does not explicitly list exclusions or alternatives, but for a DNS record lookup tool, the record type in the name/description makes the intended usage obvious.

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, lowering the bar. The description adds meaningful behavioral context by detailing the MX resolution and TLSA lookup at _25._tcp.<mx-host>, and the DNSSEC-backed verification purpose. This goes 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 compact (four sentences) and front-loaded with the core purpose. Every sentence adds value: functionality, mechanism, usage trigger, alternative tool, and audit 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 availability of an output schema and annotations, the description covers all necessary aspects: the exact DNS lookup procedure, the security rationale, when to use it, and how it differs from the HTTPS variant. It is complete for a DNS-checking 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 baseline is 3. The description adds context about the domain parameter (MX hosts, port 25) but does not provide additional syntax or meaning for 'format' or 'force_refresh' beyond what the schema already explains. It is adequate but not enriching.

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 ('Check') and resource ('DANE/TLSA certificate pinning for SMTP at port 25'), and distinguishes from the sibling tool check_dane_https by explicitly mentioning port 25 and HTTPS port 443. This makes 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?

Explicit guidance is provided: 'Use when asked if SMTP connections are protected by DANE/TLSA pinning' and 'For HTTPS DANE at port 443, use check_dane_https instead.' Also notes it is 'Part of the scan_domain audit,' giving clear context for when to invoke this tool.

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

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

Annotations already declare readOnlyHint/idempotentHint, and the description adds substantial behaior beyond that: every deployment reports the record as 'present but UNVERIFIED', names the root cause (probe vantage cannot observe the origin certificate, notAssessedReason probe_vantage_intercetted), and explicitly states the stale-pin limitation. This is exactly the kind of context annotations cannot convey, and it contradicts nothing.

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 sentences, front-loaded with purpose and mechanism before the caveats. The third sentence is dense, packing in the UNVERIFIED status, the probe_vantage reason, and the stale-pin warning; every sentence earns its place, though that one could be tightened. No filler anywhere.

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 significant caveat (UNVERIFIED status, no stale-pin detection), the description covers purpose, mechanism, limitation, sibling routing, and audit context. An output schema exists so return-value documentation is not the description's job. Nothing an agent needs to select and invoke this tool correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3 per rubric. The description adds only one piece of param meaning beyond the schema: that domain is used to construct the _443._tcp.{domain} DNS lookup name. That is useful but minor; format and force_refresh are already fully documented in 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?

Opens with a specific verb+resource: 'Verify DANE certificate pinning for HTTPS connections' and 'Looks up TLSA records at _443._tcp.{domain} (port 443)', then names exactly what gets validated (syntax, usage/selector/matching-type fields, DNSSEC backing). It explicitly distinguishes itself from the sibling check_dane by protocol and port, so an agent can tell them apart without opening either schema.

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

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

Names the alternative tool (check_dane) and the discriminating condition (SMTP at port 25 vs HTTPS at port 443). Also gives a clear when-not: comparison against the served certificate is withdrawn, so 'a stale pin is NOT detected here'. Stating that it is 'Part of the scan_domain audit' adds invocation context.

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 that it returns decoded return codes, but does not elaborate on caching, network dependencies, or error scenarios; it meets the reduced bar but adds limited extra 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?

A single, focused sentence that front-loads the core purpose and includes concrete block-list names; 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?

With a complete schema, comprehensive annotations, and an output schema, the description sufficiently conveys the tool's scope and result format. It could mention cache behavior or default format, but these are covered by 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 coverage is 100% with descriptions for all three parameters. The tool description adds no additional parameter-level meaning beyond the schema, so the 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 names a specific verb ('Check'), a resource ('domain reputation against DNS-based Domain Block Lists'), and explicitly lists the lists (Spamhaus DBL, URIBL, SURBL), distinguishing it from sibling checks like check_rbl.

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 this tool applies (domain reputation on DBLs) but does not explicitly mention alternatives or exclusion cases, such as when to prefer check_rbl for IP-based lists.

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, destructiveHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds behavioral context by explaining it probes multiple selectors, validates algorithm strength, and reports key strength, which goes beyond annotation details and helps the agent anticipate multiple DNS queries and analysis. 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, each adding distinct value: what it does, what it validates, and when to use it. It is front-loaded with the primary verb and object, contains no fluff or redundant phrasing, and is appropriately sized for the tool's simplicity.

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

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

Given the schema fully documents parameters and an output schema exists, the description does not need to explain return values. It covers purpose, usage context, and behavioral details (selector probing, algorithm validation, key strength reporting), which is more than sufficient for a read-only DNS checking tool. The description is complete for this complexity level.

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

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

The schema has 100% parameter description coverage, so the baseline is 3. The description adds slight meaning about selector behavior ('Probes common selectors') which connects to the optional selector parameter, but it does not elaborate on format or force_refresh beyond what the schema already states. The added value is minimal but not redundant.

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 DKIM records for a domain, probes common selectors, validates signing algorithms (RSA-1024/2048, Ed25519), and reports key strength. This distinct purpose differentiates it from sibling tools like check_spf, check_dmarc, and check_mx, and the verb 'look up' combined with the resource 'DKIM records' 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 provides a clear use case: 'Use to verify that outbound email signatures are cryptographically sound.' It also notes it is part of the scan_domain audit, giving context for when it might be invoked. However, it does not explicitly state when not to use it or name alternative tools, though the purpose naturally excludes other DNS record checks.

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 value by detailing what the tool shows (enforcement level, alignment mode, reporting destinations), but does not disclose potential error modes or network behavior. 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 three sentences: purpose, outputs, and usage/alternatives. Every sentence contributes new information, and it is 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?

The tool has robust annotations, full schema coverage, an output schema, and clear sibling context. The description covers purpose, usage, and differentiation, making it complete 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 description coverage is 100% and each parameter has a clear description (domain, format, force_refresh). The description does not add extra meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Look up and validate the DMARC record'), clearly states the domain scope, and explicitly distinguishes itself from sibling tools like check_shadow_domains and assess_spoofability.

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?

It explicitly states when to use this tool ('Use to determine a domain's DMARC enforcement level, whether it sends aggregate reports, or if it is protected against email impersonation') and names alternatives with their focus, providing clear decision 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?

The description accurately reflects the tool's read-only, idempotent nature by using terms like 'audit' and 'reports.' It adds context about being independent of chain validation, but does not elaborate on potential side effects or limitations beyond that.

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, using three sentences to convey purpose, output, independence, and usage. It avoids redundancy and each sentence adds meaningful 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?

The description covers the tool's purpose, usage, and key behavior, and mentions its position in the scan_domain audit. It does not describe output format or error conditions, but these are not critical for a simple read-only tool with clear schema 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?

The input schema has full coverage with clear descriptions for each parameter (domain, format, force_refresh). The tool description adds no additional information about these parameters, so it contributes nothing beyond the schema itself.

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: auditing the cryptographic strength of DNSKEY signing algorithms, reporting the algorithm used, and flagging deprecated ones. It also explicitly distinguishes this from DNSSEC chain validation, making its scope 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 usage scenarios: 'Use when asked what algorithm is used for DNSKEY signing keys, or if deprecated DNSKEY algorithms are in use.' It also notes the tool is part of a broader audit, giving context on when it might be invoked.

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

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

Annotations already declare read-only, idempotent, non-destructive. Description adds specific details about DNSKEY/DS validation and reporting, which goes beyond the basic safety profile.

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 concise sentences with no redundant information. Clearly structured 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?

Description fully explains the tool's function and context. Output schema exists, so return values are not required in the description. No missing essential information.

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?

All parameters have schema descriptions, and the tool description does not add additional semantic meaning beyond what schema already provides. Coverage is 100%, so baseline 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?

Clearly states it checks DNSSEC status, verifies tamper-proofness, and validates DNSKEY/DS records. Distinguishes from sibling tools by focusing on DNSSEC status and mentions being 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?

Provides context as part of scan_domain audit but does not explicitly contrast with alternatives like check_dnssec_chain. However, purpose is clear enough for typical usage.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side-effect behavior. The description adds some context about what it traces (DS/DNSKEY records, algorithm usage) but does not disclose additional behaviors such as caching nuances, rate limits, or what happens if the chain breaks. With annotations present, this is adequate but not rich.

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

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

The description is two sentences long, front-loaded with the action, and every sentence adds value. It states what the tool does and when to use it without any redundancy or filler. Excellent 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?

For a read-only diagnostic tool with three straightforward parameters, the description is sufficiently complete. It explains the tool's scope and use case, and since an output schema exists, detailed return value explanations are unnecessary. It could be slightly more explicit about the output structure, but the description covers the essential 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%, with clear descriptions for domain, format (including enum), and force_refresh. The tool description does not add extra meaning beyond the schema—it only mentions 'tracing DS/DNSKEY records,' which is not parameter-specific. Given high schema coverage, the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Walk the full DNSSEC chain of trust from the DNS root down to the target domain') and clearly distinguishes from sibling tools like check_dnssec by focusing on the complete chain tracing behavior. It explicitly mentions tracing DS/DNSKEY records and algorithm usage, making 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 when-to-use guidance: 'Use when asked to trace the chain of trust from the DNS root, or to see the full DNSSEC delegation path step by step.' However, it does not explicitly note when not to use it or contrast with simpler alternatives like check_dnssec, leaving some ambiguity for an agent choosing between 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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by explaining the multi-round query process and what it compares (IP answer sets and TTLs), which goes beyond the annotations. It does not mention rate limits or caching behavior, but the force_refresh parameter hints at caching.

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 main purpose and then explaining the method. It is concise and avoids fluff, though the second sentence somewhat repeats the first. No wasted words, but could be slightly tighter.

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 (4 params, output schema present), the description covers the core behavior and purpose. The output schema exists, so return values are documented elsewhere. The description could mention caching behavior or rate limits, but the annotations and schema cover most needs. It is complete enough 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%, so the schema already documents all four parameters. The description adds context about the overall purpose but does not add new meaning to individual parameters beyond what the schema provides. The description mentions 'multiple rounds' which aligns with the 'rounds' parameter, but the schema already explains that.

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 fast-flux DNS behavior by performing multiple rounds of A/AAAA queries and checking for rapid IP rotation and TTL changes. It explicitly names the resource (domain) and the specific behavior (fast-flux), distinguishing it from sibling DNS check 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 explains the method (multiple query rounds, comparing IP sets and TTLs) and the purpose (identifying botnet/malicious infrastructure), which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list shows many other DNS checks that could be 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 (readOnlyHint: true, destructiveHint: false) already disclose the tool's non-destructive, read-only nature. The description adds behavioral details beyond annotations by specifying that it detects CDN/WAF interception, flags missing or weak protections against XSS/clickjacking/cross-origin attacks, and returns per-header findings. This enriches the agent's understanding 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 two sentences, front-loaded with the core purpose, and packed with specific details (headers, weakness types, CDN/WAF). Every word earns its place; no fluff or redundancy. It is appropriately sized for the tool's complexity.

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 covers the key behavior: what headers are checked, what weaknesses are flagged, and what is returned. It also mentions CDN/WAF detection. The presence of an output schema reduces the need to describe return format. It does not mention prerequisites (e.g., HTTPS availability) or edge cases, but for a read-only audit tool with good annotations, this is sufficient.

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 (domain, format, force_refresh) already described in the schema. The tool description does not add any additional parameter-level meaning beyond what the schema provides. It doesn't compensate with extra details, so the baseline of 3 applies.

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

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

The description clearly states the tool audits a domain's browser-facing HTTP security headers over HTTPS, lists specific headers and what it flags (unsafe-inline/unsafe-eval/wildcards, etc.), and indicates it returns per-header findings. This distinguishes it from sibling tools like check_ssl or check_mx by focusing on security headers.

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

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

The description notes 'Part of the scan_domain audit', providing context that it's a component of a broader audit. It doesn't explicitly state when to use this tool over alternatives or when not to use it, but the specific scope (HTTP security headers) implies its role. No explicit exclusions are given, but the context is clear enough for typical 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 declare readOnlyHint, openWorldHint, idempotentHint, and harmless, which cover the safety profile. The description adds that it detects 'active' domains, implying a live scan or freshness aspect, and mentions the type of registrations (by attackers). It does not detail output structure, but with annotations covering safety and the description adding scope, this is strong; minus one for not describing the return format or any rate limits.

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 concise two-sentence block: first sentence defines the tool's function and use case, second sentence differentiates from key siblings. No filler; 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?

The tool has a clear, narrow scope with a detailed input schema and an output schema (not shown but noted). The description covers the purpose, use context, and differentiation from two key siblings. It could mention what the output looks like (e.g., list of domains) but the output schema likely covers that, and the description is sufficient for a straightforward scan tool with rich 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 all parameters are well-described in the schema. The description adds a semantic focus on impersonation and 'active' domains, which reinforces the domain parameter's purpose, but does not add new syntax or format details 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 the tool detects active typosquat and lookalike/homoglyph domains that impersonate a brand, with specific examples of character-substitution and visual-confusion. It explicitly distinguishes from siblings check_shadow_domains and discover_brand_domains, meeting the high bar.

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 context: for detecting impersonation domains used in phishing. It names two specific sibling tools and how they differ, giving clear guidance on when not to use this tool (e.g., for TLD variants with auth gaps or legitimate portfolio discovery).

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 provide readOnlyHint=true and idempotentHint=true, and description augments with concrete behavior: queries `_mta-sts.<domain>`, fetches policy file, reports mode and MX coverage. Says 'only' for current policy fetch, transparent about scope.

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 dense sentences are well-structured, opening with the purpose, then mechanics, then usage guidance and sibling distinction. 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 simple read-only DNS check with schema coverage and annotations, the description fully covers what is checked, why, how to contrast with related tools, and context within scan_domain 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 already describes all three parameters at 100% coverage. Description does not add substantial parameter-level meaning beyond what schema provides, 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?

Description clearly states it checks MTA-STS for inbound SMTP TLS enforcement, specific verb 'check' with resource (_mta-sts DNS record and policy file), and distinct from check_dane. It reports mode and MX coverage, so highly specific.

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

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

Explicitly states use case: 'Use to verify whether inbound SMTP is protected against TLS downgrade or MITM' and calls out the alternative check_dane using TLSA pinning, clearly distinguishing when this tool is appropriate.

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 the safety profile. The description adds behavioral context by explaining the tool identifies mail servers and provider, and references its role in scan_domain audit. It does not disclose additional operational details like caching behavior or freshness semantics (though the force_refresh parameter implies caching), but given the strong annotations, this is adequate.

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

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

The description is three concise sentences with no fluff. It front-loads the purpose, then provides usage guidance, then contextual placement. Every sentence earns its place, and it is easy to scan.

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 and comprehensive annotations, the description is complete for a simple DNS lookup. It explains the core function and when to use it. It could mention edge cases like missing MX records, but that is not essential given the schema and audit context. Overall, it adequately covers the necessary 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 all three parameters (domain, format, force_refresh) are already well-described in the schema. The description adds minimal parameter-specific value; it only indirectly refers to domain. With full schema coverage, the baseline is 3, and the description does not surpass that.

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 specific action (look up MX records) and the resource (domain), and further explains what it reveals (mail servers and email provider). It also distinguishes itself from sibling DNS check tools like check_spf and check_dmarc by specifying its unique output. The mention of being part of scan_domain audit adds 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 explicitly states when to use the tool: 'Use when asked which email provider hosts inbound mail for a domain, or to see MX record configuration.' This gives clear use cases. However, it does not mention when not to use it or list alternative tools for comparison, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds context about what is checked (RBLs and reverse DNS) and notes the distinction from check_rbl. With annotations present, this is more than sufficient, though it doesn't describe output format or rate limits.

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 exactly two sentences, both informative and front-loaded. The first sentence states the core purpose, the second adds usage guidance and sibling differentiation. 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 that an output schema exists and the tool is read-only with idempotent hints, the description covers the essential context: purpose, usage, and differentiation. It doesn't mention potential caveats like cache behavior (though force_refresh is in the schema), but for a simple read-only check, this is adequate and slightly above minimal.

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

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

The schema description coverage is 100%, and all parameters (domain, format, force_refresh) are already well-described in the schema. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool checks MX IP addresses against spam blocklists (Spamhaus, Barracuda, SORBS) and verifies reverse DNS. It explicitly distinguishes from check_rbl, which checks a specific IP directly, providing clear differentiation from a closely related sibling.

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

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

It provides explicit when-to-use guidance ('Use when you want to know if your mail server IP is blacklisted, or if your MX is on any blocklist') and names an alternative tool (check_rbl) with a clear distinction. This fully satisfies the criteria for usage direction.

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

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

Annotations already declare read-only, idempotent, non-destructive. The description adds valuable behavioral details beyond annotations: compares parent/child NS sets, verifies AA responses, checks glue, and notes the 'infrastructure probe' availability condition. 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?

Three sentences, each packed with relevant information. Front-loaded with purpose, then specifics, then context. No filler or redundancy.

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

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

For a moderately complex tool, the description covers the audit goal, the specific checks performed, the conditional probe dependency, and the typical failure modes detected. Output schema exists so return details are covered there. The mention of 'Part of the scan_domain audit' provides integration context. Slight gap: does not explain how results are returned (e.g., structured vs. textual), but output schema compensates.

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 covers 100% of parameters with meaningful descriptions (domain example, format enum, force_refresh purpose). Description adds no extra parameter semantics beyond schema, which is acceptable given the high coverage. Baseline 3 applies.

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

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

Description clearly states 'Audit a domain's nameserver delegation and redundancy' – specific verb and resource, and distinguishes from sibling DNS check tools (e.g., check_mx, check_spf) by focusing on NS delegation, AA responses, and glue. The additional use cases (detect stale delegations, lame nameservers) reinforce 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?

Provides explicit use cases: 'detect stale registrar delegations, lame nameservers, and intermittent resolution risk.' Mentions it's part of scan_domain audit, giving context. However, it doesn't explicitly state when NOT to use it (e.g., for non-NS checks) or name alternatives, so it's slightly below exemplary.

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, so the safety profile is covered. The description adds meaningful behavioral detail by revealing exactly what configurations will be flagged (plain NSEC zones, weak NSEC3 params, opt-out flags), going beyond generic labels.

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 with no wasted words. The first sentence states the primary purpose, and the second enumerates the detected conditions, making the tool's scope immediately obvious.

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, annotations, and full parameter descriptions, the description is sufficiently complete for this moderately complex check. It could improve by explicitly contrasting with related DNS security checks (e.g., check_dnssec, check_dnssec_chain), but the current content is enough for an agent to evaluate usefulness.

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 each parameter documented (domain, format, force_refresh). The description adds no additional parameter nuance, but it does not need to because the schema already provides clear meaning for all three fields.

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

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

The description opens with a specific verb and resource: "Assess zone walkability risk by analyzing NSEC3PARAM configuration." It then names discrete detection targets—plain NSEC zones, weak NSEC3 parameters, and opt-out flags—which differentiates it from broader DNS-related sibling tools like check_dnssec or 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 gives clear functional context: this tool is for NSEC/NSEC3 walkability and DNSSEC configuration detail. It does not explicitly name alternatives, but the specificity of the risk target implies when the tool should be used versus general DNS checkers.

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, so the description does not need to restate safety. The description complements these by clarifying the tool targets mail servers and is part of an audit workflow, though it could have mentioned caching behavior (force_refresh) or rate limits.

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, with the core purpose immediately front-loaded in the first sentence and additional audit context in the second. Every word earns its place; no fluff or redundancy.

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

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

For a simple DNS lookup tool with a clear schema and an output schema available, the description is adequately complete. It clearly identifies the tool's domain (mail servers) and place in the audit, though it could briefly mention that force_refresh invalidates cache to set expectations about response freshness.

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 clear descriptions for each parameter (e.g., domain, format, force_refresh). The description adds no additional context beyond what the schema supplies, so a 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 a specific verb ('Verify') and resource ('forward-confirmed reverse DNS (PTR/FCrDNS) for mail servers'). It distinguishes from numerous check_* siblings by naming the exact DNS record type and use case. The phrase 'Part of the scan_domain audit' adds scoping 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 provides no guidance on when to use this tool versus the many sibling tools like check_mx or check_spf. The only contextual hint is 'Part of the scan_domain audit,' but there is no explicit 'use when' or comparison to alternatives, leaving the agent to guess when this specific check is required.

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, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it resolves MX hosts to IPs first and checks six named blocklists, which helps the agent anticipate the operation's flow and scope.

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

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

The description is two sentences with no filler. The primary action and key scope ('MX server IP reputation', the six blocklists) are front-loaded, and the resolution behavior is stated succinctly in the second sentence.

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 a rich output schema, full parameter documentation, and safety-relevant annotations, the description covers the essentials for correct invocation. The only noticeable gap is the lack of guidance distinguishing this tool from the similarly named check_mx_reputation and check_dbl siblings.

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 domain, format, and force_refresh well. The description adds no extra parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource ('Check MX server IP reputation') and names the exact six blocklists involved. It is clear about the tool's function, though it does not explicitly name sibling tools like check_dbl or check_mx_reputation to draw a distinction.

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

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

The description explains what the tool does but gives no guidance on when to choose it over similar siblings such as check_dbl, check_mx_reputation, or check_realtime_threat_feed. No exclusions, alternatives, or situational cues 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, idempotentHint, and destructiveHint=false, establishing a safe read operation. The description adds valuable behavioral detail beyond annotations: the tool is operator-deploy only and degrades to info when unprovisioned, explaining a failure mode. This is meaningful additional context without contradicting anything.

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 concise sentences, front-loaded with the primary purpose, followed by a differentiation note and deployment context. Every word earns its place—no redundancy or filler. Ideal structure for quickly orienting an agent.

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

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

The tool is simple (domain check) with rich annotations, full parameter documentation, and an output schema existing. The description covers key differentiators (realtime, curated, not DNSBL) and failure behavior (degrade to info). It could mention specific use cases or output expectations, but given the simplicity and available structured data, 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 coverage is 100%, and each parameter already has a clear description (domain, format with enum, force_refresh). The tool description itself doesn't add any extra parameter meaning beyond what's in the schema, so the baseline 3 for high coverage applies. No new information about parameter usage or format is provided 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 action ('Check a domain against BlackVeil real-time threat intelligence') with a specific resource (curated intel-gateway feed). It explicitly distinguishes from DNSBL checks, which separates it from siblings like check_dbl and check_rbl, making 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?

It provides context by stating it's distinct from DNSBL checks and indicates deployment constraints ('Operator-deploy only; degrades to info when unprovisioned'). While it doesn't explicitly list alternative tools for specific scenarios, the distinction from DNSBL checks gives a clear when-not-to-use signal. More explicit exclusions would elevate it to 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 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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds specific context about what evidence is checked (root hints, glue, delegation, serial, DNSKEY cross-root). However, it does not describe output format, failure behaviors, or any further implications. With annotations covering safety, the description adds modest value but not extensive behavioral transparency.

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 conveys the core purpose without verbose or redundant language. Every word adds value, and it is front-loaded with the action and subject.

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

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

Given the simplicity (1 optional parameter, full schema coverage, output schema present, and read-only annotations), the description covers the main function. However, it lacks usage guidance and does not elaborate on the evidence types beyond listing them, which might leave some ambiguity about how 'cross-root evidence' is interpreted. Since the output schema exists and annotations cover side effects, this is adequate but not exceptional.

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

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

The schema has 100% description coverage for the single parameter 'format', including an enum and description 'Output verbosity. Auto-detected if omitted.' The tool description does not mention this parameter, so it adds no additional meaning beyond the schema. Baseline 3 is appropriate since the schema fully documents the parameter.

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

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

The description clearly states the tool 'Check the DNS root server set against official root hints, root glue, delegation, serial, and DNSKEY cross-root evidence.' It uses a specific verb (Check) and resource (DNS root server set) and specifies exactly what it validates against. This distinguishes it from sibling tools like check_ns, check_dnssec, etc., which focus on different DNS 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 provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or contrast with sibling tools. For example, it doesn't say 'Use this when verifying root server consistency' or 'For other DNS checks, see check_ns.' The agent is left to infer usage entirely 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 readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description doesn't need to repeat them. It adds that the tool flags weak/missing email auth for spoofing, which is useful context. 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 primary action and immediately followed by usage guidance. Zero 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?

With output schema present and good annotations, the description covers the core purpose and distinction from sibling tools. It doesn't explain return values (output schema handles that) or edge cases, but for a check tool this is sufficiently complete. Could mention limits like scope of TLDs, but not necessary.

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 all three parameters (domain, format, force_refresh). The description doesn't add parameter-specific meaning beyond what the schema provides, 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 states a specific verb ('Find'), resource ('alternate TLD variants of a domain'), and purpose (weak/missing email auth for spoofing), and explicitly distinguishes from 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?

It provides clear guidance: 'Use when asked about TLD variants with email auth gaps' and contrasts with check_lookalikes, which is a concrete alternative. This tells the agent exactly when to use and when to avoid.

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 that this is read-only, idempotent, open-world, and not destructive, so there is no contradiction. The description adds useful non-obvious behavior beyond those annotations, such as flagging syntax errors and enumerating the 'trust surface'. It stops short of describing cache semantics in prose, but the schema already covers force_refresh.

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

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

The description is compact and front-loaded, with the first sentence giving the action and resource and the following sentences adding only high-value context: what it returns, whether it detects errors, and when to choose it. There is no filler or repetition of schema details.

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

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

Given the tool has an output schema, clear annotations, and only three parameters, the description fully supports selection and invocation. It covers purpose, result semantics, syntax validation, and workflow context. The expected response format does not need to be in prose because an output schema is present.

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 fully documents domain, format, and force_refresh, including defaults and intended use. The description adds no parameter-specific information beyond the output-level concept of validation, which matches the baseline of 3 for high coverage.

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 the specific action and resource: 'Look up and validate the SPF record for a domain.' It then clarifies what the tool provides beyond the name—listing authorized IPs, flagging syntax errors, and showing the trust surface—making it easy to distinguish from siblings like check_mx, check_dmarc, and check_dkim.

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

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

The description gives a clear usage trigger: 'Use when you need to know who is permitted to send email as a domain.' It also situates the tool within the broader scan_domain audit, providing enough context for selection, though it does not explicitly call out alternatives or when-not-to-use cases.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the bar for additional disclosure is lower. The description still adds meaningful behavioral context: parallel probing of 19 prefixes, flagging insecure plaintext services, and the no-match caveat. This goes beyond what the annotations alone 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?

The description is three dense sentences with no filler. The first front-loads the action and scope, the second explains outputs and flagging behavior, and the third provides an important caveat plus 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?

For a read-only, idempotent tool with full schema coverage and an output schema, the description is complete. It covers what is probed, what is returned, how to interpret negative results, and when to use the tool. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100% and each parameter (domain, format, force_refresh) is documented in the schema. The description does not add parameter-specific meaning, but it doesn't need to because the schema carries the load. 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 opens with a specific verb ('Map') and a precise resource ('a domain's DNS-visible service footprint'), then names the 19 SRV prefixes and what the tool returns. This differentiates it from siblings like check_svcb_https, which targets a different record type.

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 it: 'Use when asked to map DNS-visible services or flag insecure service advertisements.' It also adds a valuable interpretation caveat about empty results not proving absence of services. It does not name sibling alternatives or explicit exclusions, so it falls just short of a 5.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds vital behavioral context beyond that: certificate data comes from public CT logs and 'may differ from the one currently served', and legacy-TLS detection was withdrawn because the probe cannot observe the origin handshake. 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?

Four dense sentences, front-loaded with the core purpose, followed by caveats and usage. Every sentence contributes; 'Part of the scan_domain audit' is minor but useful context. Not maximally concise, but well structured and free of filler.

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

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

For a read-only check with an output schema present, the description covers the behavior, limitations, data-source caveat, and intended use thoroughly. It leaves no critical ambiguity about what the tool can or cannot do.

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 of 3 applies. The description itself does not elaborate on parameter meanings, but the schema already documents domain, format, and force_refresh adequately. The description adds no extra param-specific nuance.

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

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

The description opens with a specific verb and resource: 'Check the HTTPS/TLS posture of a domain' and enumerates concrete checks (HTTPS reachability, HSTS policy, HTTP-to-HTTPS redirect, certificate metadata). It also differentiates from siblings by explicitly listing what it does NOT assess (origin TLS protocol support, cipher suites, legacy TLS).

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 use context: 'Use to verify HTTPS/HSTS configuration and certificate issuer/expiry.' It also states limitations that imply when not to use it, such as 'Origin TLS protocol support and cipher suites are not assessed.' However, it does not name specific alternative tools for those excluded checks, so guidance is not fully routed.

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, and idempotentHint true, covering the safety profile. The description adds that it analyzes the SPF include chain, which is useful behavioral context beyond annotations. No additional side effects or operational traits are disclosed, but with strong annotations, this is adequate.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no filler. Every word adds value, efficiently conveying what, when, and the parent context.

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 and 100% parameter coverage, the description needs only to clarify the tool's niche and usage context, which it does. It might have mentioned cache behavior or return format, but those are covered by the schema and annotations. Overall, it's sufficiently complete for this simple read-only 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 all parameters (domain, format, force_refresh) are already well-documented with descriptions in the schema. The tool description adds no additional parameter meaning, matching the baseline of 3 for high schema coverage.

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 states the resource: 'SubdoMailing risk' through analysis of the SPF include chain. It differentiates from siblings by focusing on dangling/hijackable subdomains in SPF includes, distinct from tools like check_subdomain_takeover or resolve_spf_chain.

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

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

The description provides explicit when-to-use scenarios: 'Use 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, giving context, though it doesn't explicitly mention alternatives or when not to use it.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds concrete scope detail ('16 provider families' and lists them) and warns that discover_subdomains returns only a CT sample, not a full inventory. This is additive context, though it doesn't disclose the default 15-name built-in sweep (which is documented in the schema).

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

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

Three sentences: the first states the core purpose, the second lists coverage, the third gives usage and pairing guidance. No filler or redundant repetition; each sentence contributes meaningfully.

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, output schema, and annotations, the description covers the key facts an agent needs: what the tool does, when to invoke it, and a caveat about widening the candidate set. The default 15-name sweep is documented under the subdomains parameter, so it need not be repeated. The description is complete for this complexity level.

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?

All four parameters are fully described in the input schema (100% coverage). The description itself does not add parameter-level semantics beyond the schema—its extra notes about provider families and pairing are about output scope and workflow, not parameter meaning. Baseline 3 applies.

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

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

The description opens with 'Sweep subdomains for dangling CNAMEs pointing to deprovisioned cloud services that could be claimed by an attacker,' clearly stating the verb, resource, and vulnerability. It lists provider families, distinguishing it from sibling DNS checks 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?

Explicitly states 'Use when asked if subdomains are pointing to deprovisioned cloud services' and gives a complementary action with 'Pair with discover_subdomains to widen the candidate set.' This provides clear when-to-use context and an alternative tool.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The description adds context about the RFC and audit role, but it does not go beyond annotations or reveal additional behaviors such as cache behavior, though schema documents force_refresh. No contradiction exists.

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

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

Two short, direct sentences clearly state what the tool does and where it belongs. Every word earns its place, with no unnecessary technical filler or redundant restatement of the tool name.

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

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

With an output schema present and full schema coverage for parameters, the description only needs to fill the purpose and context gap, and it does. It clearly identifies the subject, standard, and audit context, making the tool adequately complete for an 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 description coverage is 100%, so the parameters are fully documented by the schema. The description does not add meaning beyond the schema for domain, format, or force_refresh; it only frames the overall purpose of the check rather than enriching 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 uses a specific verb ('Validate'), names the exact resource ('HTTPS/SVCB records (RFC 9460)'), and states its purpose ('modern transport capability advertisement'). This clearly distinguishes it from sibling checks like check_dane_https or check_ssl while staying focused.

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 usage context by noting it is 'Part of the scan_domain audit,' placing it within a defined workflow. It does not explicitly call out alternatives or when not to use it, but the RFC scoping and audit context provide enough situational guidance.

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