BlackVeil DNS & Email Security Scanner

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?

Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds genuinely useful behavior beyond them: the call is async and returns immediately, results must be polled, and each target consumes 1 unit of the monthly BRAND_AUDIT_QUOTAS budget. That quota cost is exactly the kind of context an agent needs before calling.

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

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

Three tight sentences: what it does and its limits, what it returns, how to follow up, and what it costs. Front-loaded with the action and scope, with zero 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 10-parameter async job-starter with a full output schema, the description covers everything an agent needs: scope limits, async semantics, the follow-up tool chain, and quota impact. Return-value details are correctly left to the output 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 description coverage is 100%, so all 10 parameters are already documented in the schema, including enums for depth, discovery_mode, and view. The description names a few of them (discovery depth, brand aliases, candidate domains) and repeats the 50-domain cap, adding marginal value over the structured data. 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?

States a specific verb and resource ('Enqueue an async brand audit') plus scope (up to 50 target domains), which cleanly separates it from brand_audit_single and the status/report siblings. An agent can identify the tool without opening the schema.

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

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

Explicitly routes the agent through the workflow: poll with brand_audit_status, fetch results with brand_audit_get_report once complete. It does not explicitly contrast with brand_audit_single, but the 'batch/up to 50 domains' framing makes the choice 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?

Goes well beyond the readOnly/idempotent annotations by disclosing the notReady in-flight return, the authenticated /reports/ download link requiring the same bearer credential as this call, and the pdfPending flag for still-rendering PDFs. This is exactly the operational behavior an agent needs to poll and authenticate 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?

Front-loads the core action, then layers the mode distinction, polling state, and PDF metadata in a tight sequence with no filler. Slightly dense but 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 an output schema already present, the description only needs to cover the behavioral edges, and it does: the notReady polling state, the credential requirement for pdfUrl, and the pdfPending retry condition. Nothing an agent needs to call and interpret this correctly is missing.

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

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

Schema coverage is 100%, so both parameters are already documented, and the schema itself says 'Omit for audit-level aggregate'. The description restates this distinction rather than adding new syntax or format detail, 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?

States a specific verb and resource ('Fetch the result JSON for a completed brand audit') and immediately scopes the two modes (per-target CheckResult vs audit-level aggregate). An agent can distinguish this from brand_audit_status and brand_audit_batch_start without opening a schema.

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

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

Gives clear conditional context: set target for per-target results, omit for the aggregate, and expect notReady when polling an in-flight audit. It does not explicitly name which sibling to use instead (e.g. brand_audit_status) when the audit is not yet complete, leaving that to inference.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower; the description adds real value beyond them by disclosing monthly quota gating with exact per-tier limits and the five classification outcomes. It does not detail caching or latency behavior, but the quota and output-shape 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 core purpose before process and quota details. Efficient, though the middle sentence's classification list is dense and slightly overlaps what the output schema likely conveys.

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 schema (100% coverage), an output schema, and full annotations, the description only needs to add the process and gating context it does. It is essentially complete for calling the tool correctly, missing only explicit alternative-routing guidance.

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 11 parameters thoroughly. The description references depth, brand_aliases, and candidate_domains but adds no syntax or format meaning beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('Run a full brand audit on a single target') and the 'single' qualifier implicitly contrasts with the brand_audit_batch_start sibling. It also enumerates the concrete work performed (domain discovery, registrar/registrant lookup, classification), so an agent knows exactly what it does.

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

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

The description implies usage through 'single target' (vs. batch) and mentions depth/alias/candidate options, but never explicitly says when to choose this over brand_audit_batch_start, discover_brand_domains, or brand_audit_get_report. No when-not guidance or alternatives are named.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description still adds real value by disclosing the return shape (audit-level status enum, 'N/M' progress, per-target statuses) and the owner-scoping rule that foreign auditIds surface as notFound.

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

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

Three tight sentences, front-loaded with purpose, then return shape, then the ownership edge case. No filler and nothing repeated from the schema or annotations.

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

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

Output schema exists, yet the description still summarizes the payload and, more importantly, flags the non-obvious notFound behavior for audits owned by other principals. Only the relationship to brand_audit_get_report and any polling expectations are left unstated.

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?

Single auditId parameter with 100% schema description coverage that already states it comes from brand_audit_batch_start. The description adds no format, length, or lookup semantics beyond what the schema provides, so the baseline 3 applies.

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

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

Specific verb ('Poll') plus resource ('an enqueued brand audit') that makes the tool's job unambiguous, and the status/report split versus brand_audit_get_report is implied. It never explicitly names a sibling to route against, so it falls short of the top tier.

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?

'Enqueued' implies this is used after brand_audit_batch_start returns an auditId, so the usage context is inferable. There is no explicit statement of when to poll versus when to fetch the report or start a new audit, and no guidance on polling cadence or termination.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine extra context beyond the annotations: the unsigned-zone spoofability implication, the DNSSEC-anchoring check, and the caveat that Private-Use SVCB param code points are used pending IANA assignment.

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

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

Front-loads the purpose, then lists the specific checks in a single dense but well-structured block. It is information-rich rather than padded, though the prose is heavily packed and slightly long for a definition.

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

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

An output schema exists, so return-value detail is unnecessary, and annotations cover the safety profile. Combined with 100% schema coverage, the description is complete enough for correct invocation, though it could more explicitly address caching/pagination behavior of the zone sweep.

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 six parameters thoroughly. The description ties cap/cap-sha256 to the capability-integrity check and protocol to the index pattern, but adds little beyond what the schema already states. 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?

States a specific verb (Assess/Detects/reports/evaluates/checks) combined with a precise, unusual resource (IETF BANDAID agent-discovery SVCB records). The subject matter is so specialized that it is inherently distinguishable from DNS/TLS siblings like check_svcb_https or check_srv.

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 its use case (security posture of agent-discovery records) but never states when to choose this over alternatives or when not to use it. There is no explicit routing to or from sibling tools, leaving usage to inference.

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

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

Annotations already declare the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds substantial context beyond them: authenticated callers get zone-transfer refusal and CHAOS version.bind tests, the ZT test is 'first response only, no zone data retrieved,' and it uses BV_INFRA_PROBE when available. This discloses auth gating and side-effect boundaries the annotations do not.

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?

Purpose is front-loaded, but the description is a single very long, em-dash-dense sentence followed by a lengthy enumeration of non-measured signals. The scope-negation list is useful for routing yet verbose; some items could be trimmed without loss. Appropriately sized in intent but structurally heavy.

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

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

An output schema exists so return values need not be described, and annotations cover safety. The description still supplies full scope, auth-dependent behavior, probe fallback, and a clear boundary of what is not measured — nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% with all three parameters documented, so the schema carries the parameter burden. The description adds no syntax or format detail beyond the schema (e.g., it does not explain the full/compact format semantics or when force_refresh is worthwhile), so the baseline 3 applies.

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

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

States a specific verb (measure), resource (authoritative DNS infrastructure posture), scope (for a hostname, over direct DNS-over-TCP/53 from a single vantage), and enumerates the exact signals it covers. The explicit list of what it measures versus what it does not (UDP/53, amplification, BGP, RPKI, etc.) lets an agent separate it from siblings like check_ns and check_dnssec without opening a schema.

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

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

The scope delineation implies when the tool is appropriate (authoritative-side posture, TCP/53-based checks), and the 'inconclusive' list helps rule it out for other needs. However, it never names an alternative tool or states an explicit condition for choosing this over check_ns, check_dnssec, or check_zone_hygiene. Usage is inferred rather than guided.

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, openWorld), so credit goes to added context: the disclosure that a= is a bare URL so VMC/CMC cannot be determined, the DMARC enforcement prerequisite, and the scope of returned findings. It does not address the caching behavior implied by force_refresh, which keeps it from a 5.

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

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

Front-loaded with the core action and validation scope, then caveats, then usage. Dense but each clause earns its place; the trailing 'Part of the scan_domain audit' is the one mildly expendable element.

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, return values need not be re-explained, and the description already summarizes the finding scope. Annotations carry the safety profile and the description carries the BIMI-specific semantics, so 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%, so the schema already documents domain, format, and force_refresh. The l=/a=/p= references are BIMI record tags, not input parameters, so the description adds no parameter-level meaning beyond the schema. Baseline 3.

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

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

States a specific verb and resource ('Check the BIMI brand-logo record at default._bimi.<domain>') and enumerates exactly what it validates (logo URL l=, authority evidence a=, DMARC p= prerequisite). An agent can distinguish this from check_dmarc or brand_audit_single without opening any schema.

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

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

'Use to assess brand-indicator readiness in inboxes. Part of the scan_domain audit.' gives clear context for when this applies and ties it to the scan_domain flow. It stops short of naming alternatives or exclusions (e.g., when to prefer brand_audit_single), so it's clear context but no explicit when-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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the audit-framing context but says nothing about caching behavior, rate limits, or auth that the annotations don't already imply.

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 compact sentences with zero waste; the core action is front-loaded and the CAA explanation and audit tie-in follow. 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 a full output schema present, return values need no explanation, and annotations cover the safety profile, so the description is largely sufficient. It could be stronger only by clarifying its place relative to sibling DNS checks.

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 all three parameters (domain, format, force_refresh) are documented inline, including the enum options. The description adds no parameter detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ("Look up CAA records for a domain") and even explains what the records mean, making the tool's intent unambiguous. It does not explicitly contrast with neighbors like check_dane or check_bimi, so it stops short of a 5.

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?

"Part of the scan_domain audit" implies when this tool fits in the workflow, giving some usage context. However, it offers no explicit when-to-use/when-not guidance or named alternatives among the many sibling 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?

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing a critical behavioral caveat: the record is reported as present but UNVERIFIED because there is no port 25 certificate probe, so pinned data is never compared to the served certificate. It also notes the comparable HTTPS pipeline is kill-switched. This is exactly the kind of non-obvious limitation an agent cannot infer from 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?

Front-loads purpose and mechanism before the caveat, and every sentence carries weight. The parenthetical about the kill-switched HTTPS pipeline is slightly tangential for this tool but supports the UNVERIFIED claim, so it is defensible rather than wasteful.

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

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

With a rich annotation set and an output schema present, the description fills the remaining gap — the verification limitation — completely. An agent knows what it does, what it returns conceptually, and what it cannot confirm.

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 all three parameters (domain, format enum, force_refresh) are documented in the schema itself. The description adds no parameter-level syntax or defaults, so the baseline 3 applies.

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

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

States a specific verb (Check) and resource (DANE/TLSA certificate pinning for SMTP at port 25), and precisely scopes the mechanism: MX resolution plus TLSA lookup at _25._tcp.<mx-host>. It explicitly distinguishes itself from check_dane_https for HTTPS at port 443, so an agent can separate it from its nearest 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?

Explicitly states when to use it ('Use when asked if SMTP mail servers publish DANE/TLSA pinning') and when not to ('this does not confirm the pin matches the live certificate'), and names the correct alternative for the HTTPS case. Routing is unambiguous.

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?

Goes well beyond the readOnly/idempotent/openWorld annotations by disclosing a decisive behavioral caveat: the record is reported UNVERIFIED in every deployment, certificate comparison is withdrawn, and a stale pin is NOT detected, with the reason (probe_vantage_intercepted). This is exactly the kind of hidden limitation an agent must know before trusting a result.

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

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

Front-loads the purpose, then the method, then the critical caveat, then the sibling distinction. Dense and mostly waste-free, though the middle clause explaining the withdrawn comparison is convoluted enough to slow a reader.

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, return values need not be explained, and the description supplies everything else an agent needs: scope, port/record pattern, the UNVERIFIED limitation, and the sibling boundary. Nothing material is missing for correct invocation or interpretation.

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

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

Schema description coverage is 100%, so domain, format, and force_refresh are already documented in the schema. The description only echoes the _443._tcp.{domain} lookup pattern and adds no extra semantics (e.g., caching behavior tied to force_refresh), so the baseline 3 applies.

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

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

States a specific verb (verify DANE certificate pinning) and resource (HTTPS TLSA records at _443._tcp.{domain}), and explicitly separates itself from the sibling check_dane which handles SMTP port 25. An agent can distinguish the two 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?

Explicitly names the alternative (check_dane for SMTP port 25) and situates itself in the scan_domain audit, which is strong routing context. It stops short of stating when an agent should prefer this over, say, check_ssl or check_svcb_https, so no full when/when-not matrix.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds only that it returns listing status with decoded return codes; it says nothing about query latency, per-provider rate limits, or caching, though the force_refresh param hints at cache 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 tightly written sentences, front-loading the action and scope before the return behavior. Zero 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?

With an output schema present and annotations covering safety, the description is nearly complete for a read-only check. The only shortfall is the lack of routing against the sibling check_rbl, which matters given how similar the two tools are.

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 all three parameters (domain, format, force_refresh) are already documented in the schema. The description adds no parameter-level detail 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?

Specific verb+resource: 'Check domain reputation against DNS-based Domain Block Lists' and names concrete providers (Spamhaus DBL, URIBL, SURBL). However, it does not distinguish itself from the near-identical sibling check_rbl, so an agent cannot tell them apart from the description alone.

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 when-to-use guidance, no prerequisites, and no mention of the closely related check_rbl or check_mx_reputation alternatives. Usage is only implied by the verb 'Check', leaving the agent to infer selection.

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

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

Annotations already declare readOnly/openWorld/idempotent, so the safety profile is covered. The description adds genuine behavioral context beyond that: it probes common selectors automatically, validates the signing algorithm (RSA-1024/2048, Ed25519) and reports key strength. It doesn't mention cache behavior despite a force_refresh param, but the added context is substantive.

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

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

Four compact sentences, purpose-first, each carrying a distinct payload (what it does, what it validates, when to use it, where it fits). 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?

With an output schema present, return values need not be explained, and annotations carry the safety profile; the description supplies purpose, behavior, and audit context. It is nearly complete for a read-only probe, only lacking failure/error expectations or DNS-resolution caveats an agent might want.

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, selector, and force_refresh. The description's mention of probing "common selectors" lightly contextualizes the selector param but adds no syntax or format meaning 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?

States a specific verb (look up) and resource (DKIM records) scoped to a domain, and immediately differentiates itself from the email-auth siblings (check_spf, check_dmarc, check_bimi) by naming DKIM explicitly. An agent can tell what it does without opening the schema.

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

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

"Use to verify that outbound email signatures are cryptographically sound" gives a clear use case, and "Part of the scan_domain audit" situates it relative to a sibling. However, it names no exclusions or explicit alternative (e.g., when to prefer check_dmarc or check_bimi instead), so it stops short of full when-to-use guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/open-world, so the safety profile is covered. The description adds that this is part of the scan_domain audit and what data is surfaced, but does not mention caching behavior implied by force_refresh or refresh latency - a modest gap for a DNS-backed lookup.

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

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

Three tight sentences, front-loaded with the action and outputs before the disambiguation. The closing 'Part of the scan_domain audit' is slightly incidental but still useful context, not padding.

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 needn't be restated, and annotations cover the safety profile; what remains missing is any note on caching/refresh semantics tying force_refresh to real-world behavior. Otherwise the definition is sufficient to invoke the tool correctly.

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

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

Schema description coverage is 100%, so all three parameters (domain, format, force_refresh) are already documented in the schema with enum values and semantics. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('look up and validate the DMARC record for a domain') and enumerates the concrete outputs (enforcement level, alignment mode, reporting destinations). It explicitly names the sibling tools it is distinct from, so an agent can route correctly without opening schemas.

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

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

Gives explicit when-to-use conditions ('determine enforcement level, whether it sends aggregate reports, or if it is protected against email impersonation') and names the two nearest alternatives (check_shadow_domains, assess_spoofability) with the reason each differs. Nothing is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it reports algorithm details and deprecated-flag results independently of whether the DNSSEC chain validates, which tells the agent the result is not gated on chain success.

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

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

Three tight sentences, purpose front-loaded, then scope and usage. Slight redundancy between the opening audit statement and the later 'Use when asked what algorithm is used' clause keeps it from a 5.

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

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

With an output schema present, return-value detail is unnecessary, and annotations carry the safety profile. The description supplies purpose, when-to-use, algorithm coverage, and its place in the scan_domain audit, leaving nothing an agent needs missing.

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

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

Schema coverage is 100% and all three parameters carry descriptions, so the schema does the heavy lifting. The description says nothing extra about domain, format, or force_refresh behavior, so the baseline 3 applies.

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

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

States a precise verb and resource: audits the cryptographic strength of DNSKEY signing algorithms for DNSSEC, and names the specific algorithms it reports and flags. This is clearly differentiated from siblings such as check_dnssec or check_dnssec_chain, which cover chain validation rather than algorithm 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?

Gives explicit when-to-use conditions ('what algorithm is used for DNSSEC signing keys', 'deprecated DNSKEY algorithms in use') and notes it is part of the scan_domain audit. It lacks explicit when-not or a direct sibling comparison (e.g., vs check_dnssec), 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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds useful semantics about what the check validates (DNSKEY/DS) and what it reports, but says nothing about caching behavior, latency, or how results relate to the parent audit.

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

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

Three tight sentences, front-loaded with the core purpose and with no filler. The trailing audit-context clause is slightly tacked on but still earns its place as routing 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?

An output schema exists, so return values need no explanation, and the description covers what is checked and reported. The one gap is sibling disambiguation, which matters given the many adjacent DNSSEC-related tools.

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

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

Schema description coverage is 100%, so all three parameters (domain, format, force_refresh) are already documented in the schema. The description adds no format examples, default behavior, or refresh semantics beyond what the schema states, so the baseline 3 applies.

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

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

States a specific verb+resource ('Check DNSSEC status for a domain') and elaborates on what is validated (DNSKEY and DS records) and what is reported (enabled/validating). However, it never distinguishes itself from the close sibling check_dnssec_chain, leaving overlap for the agent to resolve.

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 trailing 'Part of the scan_domain audit' hints at where this fits in a larger workflow, but there is no explicit when-to-use guidance and no exclusion versus check_dnssec_chain, check_dnskey_strength, or check_nsec_walkability. Usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the tool performs a full recursive walk from the root, examining DS/DNSKEY records and algorithms per zone, which explains the traversal cost and structure.

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 no filler; the purpose is front-loaded and the usage condition follows immediately. Every clause earns its place.

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

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

With an output schema present and annotations covering safety, the description need not explain return values, and it covers purpose and usage well. It could add one detail about behavior on domains without DNSSEC (error vs. broken chain), but the definition is otherwise 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 all three parameters (domain, format, force_refresh) are already documented in the schema. The description adds no syntax, format, or default details beyond what the schema provides, making the baseline 3 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?

States a specific verb (walk/trace) and resource (DNSSEC chain of trust from root to target domain), and specifies the mechanism: tracing DS/DNSKEY records and algorithm usage at each zone level. This is clearly distinguishable from siblings like check_dnssec (validation status) and check_dnskey_strength (key 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 second sentence gives an explicit when-to-use: tracing the chain of trust from the root, or seeing the full DNSSEC delegation path step by step. It does not name an alternative tool (e.g., check_dnssec) or state when not to use it, 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 the safe read-only, idempotent, non-destructive profile, and the description adds real behavioral context: it discloses the multi-round query method and that IP answer sets and TTLs are compared across rounds. It does not mention latency or cost implied by multiple query rounds, but it clearly exceeds what the annotations convey.

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

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

Two sentences, front-loaded with the operation and its purpose, with no filler. Slightly redundant in restating 'rapidly rotating infrastructure' at the end, but efficient overall.

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 full schema coverage, an output schema handling return values, and annotations covering the safety profile, the description covers everything needed to invoke the tool correctly. Only the absence of when-to-use routing keeps it from being fully 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 domain, format, rounds, and force_refresh are all documented in the schema itself. The description adds no syntax or default detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Detect) and resource (fast-flux DNS behavior) and explains the mechanism (multiple rounds of A/AAAA queries, IP rotation across rounds). This clearly distinguishes it from siblings like check_ns, check_dnssec, or check_lookalikes, which target entirely different DNS signals.

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 its use case (identifying botnet/malicious infrastructure) but never states when to prefer this over alternatives such as check_shadow_domains or check_realtime_threat_feed, nor any prerequisites or exclusions. Usage is only inferable from the threat-detection framing.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world. The description adds meaningful behavioral context beyond them: it detects CDN/WAF interception (which affects interpretation of results) and returns per-header findings for missing or weak protections. It does not, however, note auth needs, rate limits, or caching interplay beyond force_refresh's schema note.

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 action and scope before the header list and the scan_domain tie-in. Dense but each clause carries information; no filler. Slightly list-heavy but well organized.

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 annotations covering safety and idempotency, the description need not explain return values, and it correctly focuses on scope, header coverage, and CDN/WAF caveats. Only the absence of sibling routing guidance and caching nuance keeps it from a 5.

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 no parameter-level detail (e.g., what compact vs full omit), so baseline 3 is correct.

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

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

States a specific verb+resource: auditing a domain's browser-facing HTTP security headers over HTTPS. Enumerates the exact headers inspected (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, COOP/COEP/CORP), which cleanly separates it from adjacent siblings like check_ssl, check_bimi, and check_dane_https.

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

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

The closing phrase 'Part of the scan_domain audit' situates it within a workflow, implying when it's relevant, but there is no explicit when-to-use/when-not or named alternative among the many sibling check_* tools. An agent must infer routing from header scope alone.

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/openWorld annotations, the description discloses meaningful behavior: caching behavior implied by force_refresh, evidence-strength caveats ('evidence of a dangling service, not proof it can be claimed', 'an unregistered name is claimable'), and the explicit 'not scored' scope plus a notAssessed section for unmeasured items.

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 paragraph that front-loads the core purpose before listing the sub-checks. Nearly every clause carries information, though the list of checks is long and could be tightened slightly.

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, return-value detail is unnecessary, and the description still covers scope, evidence interpretation, cache/refresh behavior, and a notAssessed out-of-scope section. Nothing essential for correct invocation 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%, with all three parameters (domain, format, force_refresh) documented including the enum and the force_refresh purpose. The description adds no parameter-level meaning beyond that, 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 resource (a domain's /llms.txt and /llms-full.txt) and precisely enumerates the checks performed: link parsing/dedup, external-host CNAME sweep, and install-command registry/OSV verification. It clearly delineates a distinct capability, though it never explicitly differentiates itself from the adjacent sibling check_agent_discovery.

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

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

Usage is implied rather than stated - an agent can infer this inspects agent-discovery artifacts, and 'Detection only; not scored' hints at its boundary. But there is no explicit when-to-use condition, no mention of prerequisites, and no routing to siblings such as check_agent_discovery or check_subdomain_takeover.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds that it targets 'active' attacker-registered domains, which is useful framing, but says nothing about caching behavior, latency, or rate limits for a network-dependent scan.

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 core purpose and ending on the sibling differentiation. Slight redundancy between 'lookalike/homoglyph' and 'character-substitution and visual-confusion', but nothing is wasted.

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 explanation, and annotations carry the safety profile. Purpose, detection target, and sibling boundaries are all present, leaving nothing an agent needs in order to invoke it.

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

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

Schema coverage is 100%, so the schema already documents domain, format, and force_refresh with their own descriptions. The description adds no syntax, format, or refresh semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Detect) and resource (typosquat/lookalike/homoglyph domains) with the impersonation/phishing motive spelled out. It explicitly distinguishes itself from two named siblings, so an agent can route correctly without opening schemas.

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

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

Explicitly names the alternatives and the distinguishing condition: check_shadow_domains for 'TLD variants with auth gaps' and discover_brand_domains for the 'legitimate brand portfolio'. This is a clear when-to-use-this-vs-that signal.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: it performs DNS lookups on _mta-sts.<domain>, fetches a remote policy file, and reports mode plus MX coverage — plus an implicit cache (force_refresh bypasses it).

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, no filler: the mechanism leads, the routing guidance follows, and the parent-tool relationship closes. Nothing is repeated from the schema or annotations.

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

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

An output schema exists so return values need not be spelled out, and annotations cover the safety profile. The description still names the reported fields (mode, MX coverage) and the sibling boundary, leaving no gap for correct invocation.

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

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

Schema description coverage is 100% and all three params (domain, format, force_refresh) are documented there. The description only touches caching obliquely via 'fresh check' and adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource (check MTA-STS enforcement) plus the mechanism: queries _mta-sts.<domain> and fetches the policy file, reporting mode and MX coverage. It explicitly distinguishes itself from check_dane, so an agent can route correctly without opening the schema.

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

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

Gives the when ('Use to verify whether inbound SMTP is protected against TLS downgrade or MITM') and names the sibling it is not ('distinct from check_dane which uses TLSA pinning'), supplying the discriminating condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety and repeatability are covered. The description adds the derived provider-classification behavior and its role inside the scan_domain audit, but says nothing about caching, latency, or rate limits (the force_refresh parameter hints at caching only via 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 tight sentences, front-loaded with the action, then the meaning of the output, then the usage triggers. No filler and nothing that repeats the title.

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 formatting need not be explained, and annotations carry the safety profile. Purpose, trigger conditions, and the audit-workflow relationship are all present, leaving nothing an agent needs before calling it.

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%: domain, format enum, and force_refresh are all documented in the schema itself. The description adds no parameter-level detail (no format values, no note that force_refresh matters after DNS changes), so the baseline 3 applies.

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

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

States a specific verb and resource ('Look up MX records for a domain') and then spells out what the result actually means: inbound mail servers plus the inferred email hosting provider. That inference (Google Workspace, Microsoft 365, Proofpoint) also implicitly separates it from the sibling check_mx_reputation, which is about reputation rather than configuration.

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

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

Gives explicit trigger conditions ('Use when asked which email provider hosts inbound mail for a domain, or to see MX record configuration') and places itself in the scan_domain audit workflow. It never states when NOT to use it or names a sibling to prefer instead, so it falls short of the top band.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by naming specific blocklist providers and mentioning reverse DNS verification. It does not describe rate limits or result interpretation, but those are secondary given the rich 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 front-loaded with the core action, then adds reverse DNS verification, then usage and sibling differentiation. All three sentences earn their place with 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 tool has an output schema and comprehensive annotations, so the description need not explain return values. It covers purpose, behavior, usage, and sibling routing sufficiently for an agent to 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%, so the schema already documents domain, format, and force_refresh fully. The description does not add parameter syntax or constraints beyond what the schema provides. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

States a specific verb and resource: checks MX IP addresses against spam blocklists and verifies reverse DNS. It explicitly distinguishes itself from check_rbl by explaining that check_rbl checks a specific IP directly. An agent can identify the tool's scope without opening the schema.

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

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

Provides clear 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.' It also names the closest alternative, check_rbl, and states the selection condition. No further routing is needed.

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, so the safety profile is covered. The description adds real value beyond that by disclosing conditional behavior ('when the infrastructure probe is available') and the scope of what is compared (parent vs child NS sets, AA responses, glue), which an agent could not infer from annotations alone.

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 compact sentences with the core action and scope front-loaded and no filler. The dense enumeration of checks is informative rather than redundant, though the sentence could be marginally 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?

With an output schema present, return values need not be explained, and annotations cover safety and idempotency. The description covers what, why, and workflow placement; the only gap is a slightly vague dependency on 'the infrastructure probe' without stating the fallback behavior when unavailable.

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

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

Schema description coverage is 100%, so all three parameters (domain, format, force_refresh) are already documented in the schema, and the description adds no syntax or format detail. Baseline 3 applies when the schema carries the parameter burden.

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

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

States a specific verb and resource ('Audit a domain's nameserver delegation and redundancy') and then enumerates the concrete checks performed: provider identification, parent/child NS comparison, AA response verification, and glue address checks. This is clearly distinguishable from siblings like check_authoritative_dns_infra or check_root_server_set.

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

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

Gives explicit use cases ('detect stale registrar delegations, lame nameservers, and intermittent resolution risk') and situates the tool within the scan_domain audit workflow. It stops short of naming when to prefer an alternative sibling or stating exclusions, so it is not a full 5.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds substantive behavioral context by naming the concrete conditions it flags (plain NSEC zones, weak NSEC3 parameters, opt-out flags), which is more than the annotations convey.

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

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

A single front-loaded sentence naming the purpose first and the detection specifics second, with zero filler. Every clause earns its place.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description fully covers the tool's analytical intent. Only the absence of when-to-use routing against the many sibling checks keeps it short of 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 domain, format, and force_refresh are already documented in the schema. The description adds no parameter-level detail (e.g., cache implications of force_refresh), 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?

States a specific verb+resource ('Assess zone walkability risk') plus the mechanism ('analyzing NSEC3PARAM configuration') and enumerates what it detects. This distinguishes it from generic siblings like check_dnssec or check_zone_hygiene, though it doesn't explicitly name a sibling it replaces.

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?

Usage is implied by the described detection scope (zone enumeration risk), but there is no explicit when-to-use or when-not-to-use guidance, nor any routing to alternatives such as check_dnssec or check_zone_hygiene. An agent can infer intent but gets no explicit selection criteria.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the FCrDNS framing but says nothing about caching, DNS resolution behavior, or failure modes beyond what annotations already provide.

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

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

Two short sentences, front-loaded with the core purpose and followed by the workflow context. Nothing is wasted and no sentence is filler.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description is complete enough for a read-only single-domain check, though a brief note on what a failing FCrDNS result means would have added value.

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 all three parameters documented including the format enum and force_refresh's cache-bypass purpose. The description adds no parameter-level meaning, 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?

States a specific verb ('Verify') and resource ('forward-confirmed reverse DNS (PTR/FCrDNS)') with the target scope ('for mail servers'). This distinguishes it from siblings like check_mx, check_spf, and check_dnssec, which operate on different DNS records.

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 'Part of the scan_domain audit' gives implied context for when this tool belongs in a workflow, but there are no explicit when-to-use/when-not conditions or named alternatives. An agent must infer the usage 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: the MX-to-IP resolution step performed first, and the concrete set of blocklists queried. It omits caching behavior and any rate-limit/query-volume implications.

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 front-loaded sentences with the core operation first and the resolution pre-step second; no filler. The parenthetical blocklist enumeration is defensible but slightly verbose for a description.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description supplies what is checked and the pre-resolution step, leaving only minor gaps such as the cache interaction implied by force_refresh.

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 all three parameters are self-documented, so the schema does the heavy lifting. The description adds no parameter-level detail beyond implying that 'domain' is the input whose MX hosts get resolved.

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?

Specific verb (Check) plus a precise resource (MX server IP reputation) and the mechanism (DNS-based blocklists), with a useful pre-step disclosed. It is not explicitly differentiated from the close sibling check_mx_reputation, so it falls short of a 5.

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?

Usage is implied rather than stated: knowing it evaluates MX-derived IPs against blocklists tells an agent this applies to mail deliverability/blocklist concerns. There is no explicit when-to-use, when-not-to-use, or named alternative (e.g., check_mx_reputation, check_dbl) to route against.

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/open-world semantics, so the bar is lower. The description adds genuinely useful operational context annotations cannot: it only works when provisioned by the operator, and degrades gracefully to an informational result otherwise. It doesn't mention rate limits or cache TTL, but force_refresh in the schema implies 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?

Three short sentences with zero filler; the core purpose is front-loaded and the caveats follow in priority order (sibling distinction, then deployment caveat).

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, return values need not be described, and the key operational caveats are covered. Minor gap: what 'degrades to info' concretely returns is left implicit, though the output schema likely resolves it.

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

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

Schema description coverage is 100%, so domain, format, and force_refresh are already documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (Check) and resource (domain) against a named threat feed, and explicitly positions itself against a sibling category: 'Distinct from DNSBL checks' separates it from check_dbl/check_rbl. An agent can identify this as a threat-intel lookup rather than a blocklist lookup without opening the schema.

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

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

Gives the discriminating condition versus DNSBL tools and states a deployment precondition ('Operator-deploy only'). It doesn't spell out a positive use case (e.g., 'use when you suspect active targeting'), but the exclusion plus precondition is clear guidance.

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

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

Annotations already declare readOnlyHint=true 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 readOnly, idempotent, openWorld, and non-destructive, so safety is covered. The description adds real behavioral context beyond that: it samples exactly 3 rotating root servers per call and depends on the BV_INFRA_PROBE environment, degrading to embedded hints as reference-only data when absent.

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

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

Two dense sentences with no filler, and the core behavior is front-loaded before the environment caveat. Slightly jargon-heavy but every clause contributes.

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 exposition. The description covers what is compared, the sampling behavior, and the environment dependency, leaving little an agent needs in order to call 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?

With a single, fully-described enum parameter (format), the schema already carries the semantics. The description adds nothing about the format options, 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?

States a specific verb (Query/compare) and resource (root servers, priming NS set, glue, SOA serials, cross-root consistency) with the scope of the operation. An agent can tell this inspects the root server set rather than a general domain, though it does not explicitly distinguish itself from neighbors like check_ns or check_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?

There is no explicit when-to-use vs alternatives guidance. The BV_INFRA_PROBE sentence implies a prerequisite and a degraded mode, which is useful but not framed as usage direction, so the guidance remains implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the detection focus (email-auth gaps on alternate TLDs), which is useful framing, but says nothing about caching, result shape, or rate behavior even though a force_refresh parameter exists.

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

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

Two sentences, zero padding, with the core purpose front-loaded and the sibling disambiguation in the second sentence. Every clause earns its place.

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

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

With an output schema present, return values need not be described, and annotations plus the 100%-covered input schema carry the rest. The description supplies exactly the remaining need: what this check looks for and how it differs from the nearest sibling.

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 domain, format (enum), and force_refresh all documented in the schema itself. The description adds no parameter-level detail (e.g., how format auto-detection works), so the baseline 3 applies.

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

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

Specific verb+resource with a concrete example (example.net, example.co) and the outcome it targets (TLD variants with weak/missing email auth). It explicitly names the sibling check_lookalikes and how it differs, so the agent can disambiguate 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?

States exactly when to use it ('when asked about TLD variants with email auth gaps') and gives an explicit exclusion/alternative ('distinct from check_lookalikes which detects typosquat/homoglyph impersonation domains'). Nothing is left to inference.

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

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description restates what the tool returns (IP list, third-party senders, syntax errors, whitelisted mail servers), which largely duplicates the output schema rather than adding non-obvious behavior such as cache semantics or fallback handling.

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 core action, with no filler. The parenthetical '(which mail servers are whitelisted)' is mildly redundant with the preceding 'trust surface' phrasing but still clarifies terminology.

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 annotations covering safety, a 100%-covered schema, an output schema handling return values, and only one required parameter, the description is nearly complete. The one omission is sibling disambiguation against resolve_spf_chain, which matters in a tool set this dense.

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 says nothing about the optional 'format' or 'force_refresh' parameters, so it adds no meaning beyond the schema, which already documents all three.

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 ('Look up and validate the SPF record for a domain') and enumerates what the result contains. It is clearly distinct from the many unrelated check_* siblings, but it does not distinguish itself from resolve_spf_chain, the closest SPF-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?

'Use when you need to know who is permitted to send email as a domain' gives a genuine usage trigger, and 'Part of the scan_domain audit' situates it in a workflow. However, there are no when-not conditions and no routing to the obvious alternative resolve_spf_chain, so the guidance is implied rather than explicit.

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

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

Annotations already declare readOnly, openWorld, idempotent and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: parallel probing of 19 prefixes, the insecure-advertisement flagging logic, and a false-negative limitation. It stops short of describing rate limits or caching behavior, which is left to the schema's force_refresh parameter.

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 core action and scope, with each sentence earning its place including the limitation caveat. The first sentence is dense with category detail but remains readable.

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, return values need not be explained, and the description covers action, scope, security-relevant behavior and a key interpretive limitation. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and all three parameters carry their own descriptions, so the schema does the heavy lifting and a 3 baseline is appropriate. The description adds no parameter-specific meaning (e.g., what 'compact' omits or when the auto-detected format applies).

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

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

States a specific verb (map) and resource (DNS-visible SRV service footprint), specifies the exact scope (19 common SRV prefixes across five categories), and describes the flagging behavior. An agent can distinguish this from sibling checkers like check_mx or check_svcb_https 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?

Explicitly says when to use it ('map DNS-visible services or flag insecure service advertisements') and adds a meaningful negative caveat that no matches is not proof of no services. It does not, however, name alternatives or state when a sibling tool would be better.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses a critical data-provenance caveat: certificate metadata comes from public CT logs and reflects the most recently LOGGED certificate, which may differ from the one currently served. It also explains why legacy-TLS detection is absent. This is exactly the kind of behavioral context an agent needs and could not infer from structured fields.

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

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

Front-loaded with the core action and scope, then the caveats. Every sentence carries information (CT-log limitation, excluded checks, usage). Slightly dense, with the withdrawn-legacy-TLS clause being wordy, but nothing is 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 domain-inspection tool with an output schema already describing returns, the description supplies what remains: scope, provenance caveats, explicit non-coverage, and a usage pointer. An agent has enough to call and interpret 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%, so domain, format, and force_refresh are already fully documented in the schema, including the cache-bypass rationale. The description adds no parameter-level syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (Check) plus a precisely scoped resource (HTTPS/TLS posture of a domain) and enumerates the sub-checks: HTTPS reachability, HSTS policy, HTTP-to-HTTPS redirect, and CT-log certificate metadata. This cleanly separates it from siblings like check_http_security, check_dane_https, and check_svcb_https.

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

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

'Use to verify HTTPS/HSTS configuration and certificate issuer/expiry' gives a clear use case, and the description draws explicit boundaries by naming what is NOT assessed (origin TLS protocol support, cipher suites, legacy TLS). It stops short of naming a sibling tool to use for those excluded areas, so it is clear context without full alternative routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the check inspects the SPF include chain, but says nothing about caching or result semantics beyond what the schema's force_refresh/format params imply.

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

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

Front-loaded with the analysis target, but the second sentence largely paraphrases the first ('dangling domain' / 'subdomain mailing risk hidden in SPF includes'), so a full sentence is spent restating rather than adding 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?

An output schema exists, so return-value explanation is not required, and the description plus annotations give enough to invoke the tool correctly. It would be stronger if it distinguished this check from the adjacent resolve_spf_chain 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 domain, format, and force_refresh are all documented in the schema itself. The description adds no syntax, default, or format nuance beyond that, which matches the baseline when the schema does the work.

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

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

States a specific verb (detect) and a specific analysis target (SPF include chain for dangling/hijackable subdomains). It clearly differentiates from neighboring tools like check_spf and resolve_spf_chain by naming the hijack/dangling-domain angle rather than generic SPF validation.

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

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

Explicitly says when to use it ('if an SPF include chain can be hijacked through a dangling domain') and places it in the broader scan_domain audit. It stops short of naming the sibling alternative to choose instead when the concern is plain SPF correctness, so the routing guidance is clear but not complete.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context: 16 provider families are probed, a 15-name built-in list is used when no subdomain list is supplied, and caching exists. It stops short of describing pagination or output shape, but output schema exists.

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

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

Front-loaded with the core purpose and vulnerability class, then usage and pairing guidance. The parenthetical provider list is somewhat long but earns its place by conveying coverage breadth. No filler sentences.

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

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

For a read-only scanning tool with an output schema, the description covers purpose, trigger conditions, companion tooling, detected-provider scope, and the built-in-list fallback. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so all four parameters are documented in the schema itself; baseline 3 applies. The description reinforces the subdomains parameter by suggesting CT enumeration or brand-audit discovery as sources, but adds no syntax beyond what the schema provides.

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

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

States a precise verb+resource+outcome: 'Sweep subdomains for dangling CNAMEs pointing to deprovisioned cloud services that could be claimed by an attacker.' It names the vulnerability class explicitly and lists the provider families detected, so an agent can distinguish it from siblings like discover_subdomains or check_shadow_domains.

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

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

Gives an explicit trigger ('Use when asked if subdomains are pointing to deprovisioned cloud services') and names the companion tool, discover_subdomains, plus the reason to pair ('widen the candidate set'), while clarifying that sibling returns only a CT sample. Routing is unambiguous.

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. The description adds only the RFC reference and domain context, but no additional behavioral details like caching behavior (beyond the force_refresh param), authentication requirements, or rate limits. With annotations covering the safety profile, this is minimal added value.

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

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

Two sentences, front-loaded with the core purpose followed by contextual placement. 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?

Given the tool's simplicity, the presence of an output schema, and full annotation coverage, the description is nearly complete. It lacks explicit routing to alternatives, but otherwise an agent has enough to call 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%, so the schema already documents all three parameters (domain, format, force_refresh). The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

States a specific verb ('Validate') and resource ('HTTPS/SVCB records (RFC 9460)'), and the scope is distinct from sibling checks like check_dane_https or check_srv. The purpose is immediately clear without opening the schema.

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

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

The description says it is 'Part of the scan_domain audit', but gives no explicit guidance on when to use this tool versus alternatives such as check_dane_https or check_srv. It provides no when-to-use or when-not-to-use conditions.

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, destructiveHint=false, so the safety profile is covered; the description adds real value by naming the exact record queried and the specific failure modes it flags (missing record, duplicates, invalid/absent reporting URI). It does not mention caching, which matters given the force_refresh parameter.

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

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

Front-loaded with the purpose in the first sentence, then the mechanics, then the sibling relationship. Four sentences, each carrying information, though slightly dense with DNS-specific detail an agent may not need.

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 formatting need not be described. The description covers what is checked, the record path, the validation rule, and the failure cases, which is everything an agent needs 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%, so domain, format, and force_refresh are already documented in the schema. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (Check), resource (SMTP TLS Reporting / TLS-RPT), the exact DNS query (_smtp._tls.<domain> / v=TLSRPTv1), and the validation performed (rua= mailto:/https:). An agent can distinguish this from check_mta_sts and the other check_* siblings without opening the schema.

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

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

Gives clear context: it complements MTA-STS and is part of the scan_domain audit. This tells the agent how the tool fits its siblings, but it never states an explicit when-not or a direct alternative choice (e.g. 'use check_mta_sts for policy, this for reporting'), 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 confirm the tool is read-only, idempotent, and non-destructive, so the description does not need to cover safety. It does not add extra behavioral context such as caching behavior (partially covered by the force_refresh parameter schema) or what the audit reports. With annotations covering the core traits and an output schema presumably describing results, a baseline 3 is appropriate.

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

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

A single, front-loaded sentence that efficiently conveys the purpose and scope. 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?

The description is concise but adequately conveys the tool's purpose for an agent to select it among TXT-related checks, especially given the rich sibling set. It could benefit from a brief note on what constitutes 'stale' or 'SaaS exposure' but is otherwise complete for a read-only audit with an output 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 all three parameters are fully documented in the input schema. The description adds no parameter details beyond what is already present, which matches the baseline for high-coverage schemas.

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 ('Audit') and resource ('TXT records') with a clear scope ('stale entries and SaaS exposure'). This distinguishes it from the many sibling check_* tools that look at other DNS record types, though it does not explicitly name an alternative for overlapping goals.

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

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

There is no guidance about when to run this versus adjacent tools like check_spf or check_dmarc, which also involve TXT records. No prerequisites or contexts are mentioned.

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