BlackVeil DNS & Email Security Scanner

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

The annotations already establish that this is a read-only, non-destructive, idempotent, open-world operation. The description adds useful behavioral context by explaining that the tool compares current state to a prior scan and returns a drift classification, score delta, and lists of improvements/regressions. It does not add much about caching behavior or operational limits, but the schema covers those parameter-level 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 front-loaded with the core action and comparison model, then states the return shape, then gives the intended question and sibling distinction. Every sentence serves a clear purpose, and there is no repetitive or wasted text.

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 tool with no output schema, the description helpfully names the returned drift classification, score delta, and improvement/regression lists. Combined with rich annotations and fully documented parameters, it gives an agent enough context to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline 3 applies. The description reinforces that comparison is against a prior scan snapshot and not a policy object, but that distinction is already present in the baseline parameter schema description. It adds little additional meaning for domain, format, or force_refresh beyond what the schema already provides.

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

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

The description states a specific action and resource: measuring whether a domain's DNS security posture improved or regressed by comparing current state to a prior snapshot. It names the drift classification outputs and explicitly distinguishes this from compare_baseline's fixed-policy compliance check, so an agent can tell the siblings apart.

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

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

It gives a direct use case: answering whether the security score improved or regressed since last time. It also explicitly names the nearby alternative, compare_baseline, and states that compare_baseline checks compliance against a fixed policy rather than improvement over time.

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. The description adds valuable behavioral context: the 0–100 score range with higher meaning more spoofable, the risk-level scale, per-control sub-scores, and a plain-language summary—information not present in annotations or an output schema.

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

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

Two tightly written sentences with no wasted words. The core computation and score direction are front-loaded, followed by return details and usage guidance.

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 composite nature, no output schema, and full schema coverage for inputs, the description covers what it computes, what it returns (risk level, sub-scores, summary), and when to use it. It stops short of detailing the scoring methodology, but an agent has enough 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 fully documents all three parameters (domain, format, force_refresh). The description adds no additional parameter meaning beyond what the schema already provides, which is the baseline case.

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 ('Compute') and resource ('composite email spoofability risk score') with the exact inputs combined (SPF, DMARC, DKIM). This implicitly distinguishes it from individual check_* siblings, but does not name them explicitly.

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

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

Provides a clear usage context: 'Use when asked how easy it is to spoof email from a domain, or for a composite email spoofing risk score.' It does not state when to prefer individual checks or name alternatives, leaving some inference to the agent.

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

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

Annotations already declare read-only, idempotent, open-world, so the safety profile is covered; the description adds genuinely new behavior — parallel fan-out capped at 10, per-domain result structure, once-per-batch version stamp hoisting, and a warning not to compare scoringModelVersion with dnsChecksPackageVersion. Gaps remain: no mention of partial-failure behavior when one domain errors, timing/rate limits for a 10-domain batch, or cache lifetime despite force_refresh.

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

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

Front-loads the action, scope, and return shape in the first sentence, then the sibling discriminator. The version-stamp passage is longer than needed for invocation guidance — it is citation policy rather than calling information — but it is still useful context and 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?

With no output schema, the description carries the return-value burden and does so by naming score, the A+/A/B/C/D/F bands, finding counts, and the hoisted version fields. It is thin on failure semantics for a multi-domain batch (what is returned if 3 of 10 domains fail) and on what 'full' vs 'compact' format does to the response.

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; format, domains, and force_refresh are all documented in the schema. The description adds only 'in parallel' and re-states the 10-domain cap that maxItems already encodes, and it never discusses force_refresh's cost or the format enum's effect on payload size.

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 ('bulk-scan up to 10 domains in parallel') plus the concrete outputs (score, NIST 6-band letter grade, finding counts per domain). It explicitly separates itself from compare_domains, but says nothing about how it differs from the closely named siblings batch_scan_start / batch_scan_status / batch_scan_findings or from single-domain scan_domain, leaving real ambiguity in a crowded family.

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 use condition ('audit multiple domains at once') and names one alternative with the discriminator ('compare_domains does side-by-side analysis of 2–5 domains'). It omits the other obvious decision points: when to prefer scan_domain for a single domain, and when to use the async batch_scan_start/batch_scan_status pair instead of this synchronous call.

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, non-destructive, and closed-world, so the safety profile is fully covered. The description adds useful context with 'owner-scoped' (access is limited to the caller's own jobs) and 'completed' (results only exist after the job finishes), but says nothing about result volume, pagination, or error 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?

One sentence, no filler, with the scope and the prerequisite front-loaded before the resource. Every word carries weight.

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 two-parameter read-only retrieval tool with a fully documented schema and rich annotations, this is nearly sufficient. The only real gap is the absence of any hint about result size, pagination, or whether an incomplete job returns partial data.

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 job_id and format are already documented, including the pattern and the cross-reference to batch_scan_start. The description adds no syntax, format, or default 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 concrete verb ('Fetch') and resource ('findings') plus a scope qualifier ('owner-scoped') and a precondition ('completed asynchronous batch scan'). That implicitly separates it from batch_scan_start and batch_scan_status, though it never names a sibling explicitly.

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

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

The phrase 'for a completed asynchronous batch scan' signals the correct call point, and the job_id schema description points back to batch_scan_start. But there is no explicit guidance on what to do when status is still running, and no mention of an alternative to prefer.

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 idempotentHint=true, so the description earns credit for going further by spelling out the exact replay conditions — same principal, normalized inputs, and scoring versions return the same job — which is real operational context an agent cannot get from the boolean hint. What is missing is job lifecycle information: TTL, whether results expire, and how to retrieve them.

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

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

Two sentences, zero filler, with the core action and its return value front-loaded before the idempotency nuance. Nothing repeats the schema or annotations verbatim.

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 an asynchronous batch-start tool with no output schema, the description should close the loop by pointing at the status/findings siblings and describing job lifetime. It covers initiation and idempotency well but leaves the agent without an explicit retrieval path, which is the most consequential remaining gap.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including idempotency_key and force_refresh, which puts the baseline at 3. The description reinforces the 1–10 domain bound and adds genuine replay semantics for the idempotency key, but leaves format and force_refresh entirely to the schema, so it does not rise above baseline decisively.

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 ('Start a durable asynchronous scan of 1–10 domains') plus the immediate result ('Returns a stable job ID'), so an agent knows exactly what the tool initiates. It stops short of naming the companion poller (batch_scan_status) or distinguishing itself from the non-start sibling batch_scan, so differentiation is inferred rather than stated.

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 words 'durable asynchronous' and 'job ID' imply the follow-up pattern (start, then poll a status tool), but no explicit when-to-use, when-not-to-use, or alternative is named. An agent in a toolset containing batch_scan, batch_scan_status, and batch_scan_findings must guess the intended workflow.

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=false and destructiveHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact not in the annotations: results are 'owner-scoped', so jobs belonging to other callers will not be visible. It still says nothing about whether the response reports progress, terminal states, or expiry, and with no output schema that gap is left open.

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?

One sentence with zero waste, and the key qualifier ('asynchronous') and the access constraint ('owner-scoped') are front-loaded. It is efficient but borders on under-specified for a polling tool.

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

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

With no output schema, the description is the only place to explain what a status read returns (state, progress, completion signal) and it does not. The parameters and safety hints are adequately covered elsewhere, so it is callable, but an agent still cannot predict the response shape or the correct follow-up call.

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%: job_id carries its pattern and a pointer to batch_scan_start, and format documents its enum plus auto-detection. The description adds no parameter-level detail beyond that, which is acceptable given the schema does the work, but it earns no extra credit.

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 plus resource ('Read ... status') and scopes it to an asynchronous batch scan, which separates it from batch_scan_start and batch_scan_findings by phase. It never names those siblings explicitly, so the agent must infer the start-poll-read workflow from naming 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?

'asynchronous batch scan' implies this is the polling step after batch_scan_start, but the description never says when to call it, how often, or what to call once the job finishes (batch_scan_findings). Usage is implied rather than stated.

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

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

Goes well beyond annotations by disclosing the quota cost (1 unit per target against monthly BRAND_AUDIT_QUOTAS), async behavior, and the immediate return shape. These are non-obvious operational traits that materially affect invocation decisions.

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 tightly packed sentences, front-loaded with the core action, then return/poll guidance, then quota cost. Zero waste.

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?

Strong coverage for a complex 10-param tool: workflow, return shape, and quota are all addressed. However, advanced params like planner_mode, discovery_mode, view, and ownership_verified are left entirely to the schema with no prose context.

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

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

Schema coverage is 100%, so all 10 parameters are already documented. The description restates a few (domains, depth, aliases, candidate domains) but adds no format or behavioral detail 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+resource ('Enqueue an async brand audit') with scope (up to 50 target domains), clearly distinguishing it from the single-domain sibling brand_audit_single.

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 describes the async workflow: poll with brand_audit_status and fetch results with brand_audit_get_report once complete. Lacks explicit contrast against brand_audit_single or batch_scan_start, but the follow-up routing is clear.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful contextual behavior: notReady for in-flight audits, pdfUrl authentication requirements, and pdfPending when a PDF is still rendering.

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 purpose is front-loaded, and each sentence carries distinct operational information about target behavior, readiness, and PDF sidecar handling. There is no redundant restatement of the tool name or 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?

Given no output schema, the description still explains the main return modes, readiness state, and PDF-related metadata. Combined with full parameter schema coverage and annotations, an agent has enough information to invoke and interpret this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful semantics for the target parameter by explaining that setting it returns a per-target CheckResult while omitting it returns the aggregate; format behavior is left to the schema.

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

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

States a specific verb and resource: fetch the result JSON for a completed brand audit. It also distinguishes target-level output from audit-level aggregate output, so the tool is clearly differentiated from status/start siblings.

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

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

The description makes clear this is for completed audits and explains the target-vs-aggregate branching. It does not explicitly name brand_audit_status as the alternative for polling an in-flight run, so routing guidance is strong but not fully 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 declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety burden is partly covered. The description adds genuinely non-obvious behavior beyond that: tier-wide BRAND_AUDIT_QUOTAS with per-tier numbers (free/agent=0 through owner unlimited), registrar+registrant enrichment, and classification into five relationship categories. It stops short of disclosing expected runtime or whether results are cached/persisted for the report siblings.

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, front-loaded with the action and followed by the pipeline and gating facts; little waste. The classification clause is a long noun list that could be tightened, but nothing is gratuitous.

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 11 parameters, no output schema, and an open-world scan, the description covers the important unknowns: what gets discovered, what gets looked up, what categories come back, and the quota gate. The absence of any statement about runtime, result retrieval, or interaction with the brand_audit_get_report/status siblings is the main remaining gap.

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

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

Schema description coverage is 100%, so all 11 parameters are already documented, and the description merely mirrors a subset (depth, brand aliases, candidate domains). It adds no interpretation for view, planner_mode, discovery_mode, or min_confidence 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?

The description states a specific verb and resource ('Run a full brand audit on a single target') and enumerates the concrete outputs: discovery, registrar/registrant lookup, and classification into named relationship categories. It is clearly a single-target counterpart to the batch siblings, though the description itself never names brand_audit_batch_start as the alternative, relying on the tool name for that distinction.

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

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

Usage context is only implied: 'single target' plus per-tier quota gating tells the agent roughly when this is affordable, and depth/ownership_verified hints at prerequisites. There is no explicit when-to-use vs brand_audit_batch_start, brand_audit_get_report, or discover_brand_domains, and no stated exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely non-obvious behavior: results are owner-scoped and auditIds owned by other principals surface as notFound, which an agent cannot infer from the annotations or 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: action first, return shape second, ownership caveat last. No filler, and the most important scoping constraint is not buried.

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

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

There is no output schema, but the description fully compensates by naming the status values, progress format, per-target statuses, and the notFound edge case. For a simple two-parameter read tool, nothing needed to call or interpret it 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 the auditId description already points to brand_audit_batch_start, so the schema carries parameter meaning. The tool description adds no syntax or format detail for auditId or format beyond what is already structured, which is the baseline case.

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 ('Poll the status of an enqueued brand audit') and enumerates exactly what is returned (audit-level status enum, progress 'N/M', per-target statuses), which inherently distinguishes it from brand_audit_get_report and brand_audit_batch_start.

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 'enqueued brand audit' clearly places it in the lifecycle after brand_audit_batch_start, giving an agent solid context for when to call it. It does not explicitly name alternatives such as brand_audit_get_report for completed audits, so there is no exclusion guidance.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive. The description adds valuable context: DNSSEC anchoring implications (unsigned = spoofable), DANE/TLSA evaluation, capability-document integrity checks, and the use of Private-Use SVCB param code points. Missing are error behaviors or performance characteristics, but overall strong.

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 main purpose and packs necessary details without excessive verbosity. It is dense but appropriate for the complexity, though some phrases could be slightly tightened.

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

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

Given the tool's complexity, the description covers the purpose, what it detects, security implications, and read-only nature. The output schema exists, so return values need not be explained. Together with full parameter descriptions, an agent has enough 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 all parameters are fully documented in the schema. The description does not add any parameter-level meaning beyond what the schema provides, so it meets the baseline of 3.

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

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

States a specific verb ('Assess'), resource ('IETF BANDAID agent-discovery records'), and names the draft and record patterns. Clearly distinguishes from sibling tools like check_svcb_https or check_dane by focusing on agent-discovery rather than general SVCB/HTTPS or TLSA.

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 context about what the tool checks and implies when to use it (for agent-discovery security posture). However, it does not explicitly name alternatives or state when not to use it, which is a minor gap given the unique resource.

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, the description discloses important behavioral details: direct DNS-over-TCP/53 from a single vantage, that DNSKEY/RRSIG checks are presence-only and not validation, that zone-transfer testing is authenticated-only and retrieves no zone data, and that many adjacent infrastructure signals are not measured. It also notes the BV_INFRA_PROBE dependency.

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 purpose and remains information-dense, but it is a long run-on sentence with many semicolon-separated checks and non-checks. The negative list is useful for avoiding misinterpretation, though the density makes it less 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?

Given the tool's complexity, the annotations, the fully described schema, and the existing output schema, the description provides enough context about what is measured, what is not measured, authentication-dependent behavior, and the probe dependency. Return values and parameter details are appropriately left to the structured fields.

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 domain, format, and force_refresh parameters are already documented in the input schema. The description does not add parameter-specific meaning beyond referring to a hostname and authenticated callers, 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 opens with a specific verb and resource: measure authoritative DNS infrastructure posture for a hostname over direct DNS-over-TCP/53 from a single vantage. It clearly enumerates the measured checks and distinguishes DNSKEY/RRSIG presence from validation, but it does not explicitly name sibling tools or route the agent between them.

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 detailed scope: authoritative DNS posture over TCP/53, with an explicit list of adjacent metrics that are not measured and therefore inconclusive. However, there is no direct when-to-use statement or named alternative such as check_dnssec, check_ns, or check_zone_hygiene.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description earns credit for the extra disclosures it does make: the a= tag is a bare URL so VMC vs CMC cannot be determined, and the DMARC p=quarantine/reject precondition that mail clients enforce. It does not discuss caching behavior or the force_refresh default, which remains with 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?

The scope and the specific checks are front-loaded in the first sentence, followed by the important caveat about a= and the DMARC prerequisite. Every sentence carries information, though the density makes it slightly heavy for a single-check tool.

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

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

With an output schema present, the description need not describe return values, and it correctly characterizes outputs qualitatively (findings for missing/malformed records or unmet prerequisites). Given annotations and full schema coverage, the only remaining gap is cache/refresh semantics, which the schema already handles.

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 documented there, including the format enum and the force_refresh cache-bypass note. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

Names a specific verb and resource (check the BIMI record at default._bimi.<domain>) and enumerates exactly the three things validated: the l= logo URL, the a= evidence tag, and the DMARC enforcement prerequisite. An agent can distinguish it from check_dmarc, check_dkim and check_spf 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 and a routing relationship to scan_domain. It stops short of explicit exclusions (e.g., when to prefer check_dmarc for the underlying enforcement check), so it is not a full when/when-not rubric.

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 provide strong behavioral guarantees (read-only, idempotent, non-destructive). The description only adds that it is part of a specific audit sequence, providing workflow context but not deeply revealing any hidden behavioral traits.

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 highly efficient, using only two sentences. The first sentence defines the action, and the second provides context, making it easy to digest.

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?

It is highly complete for an initiation step, telling the agent precisely what data is retrieved (authorized CAs) and the scope of the operation (a specific domain). While perfect, it relies slightly on the output schema to explain the actual return structure.

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?

Since the schema description coverage is 100%, the baseline for parameter semantics is 3. The description provides no additional semantic meaning to the domain, format, or refresh parameters beyond what is already detailed 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 clearly defines the tool's purpose: looking up CAA records to show which Certificate Authorities are authorized. It is specific to the resource (CAA records) and the goal (issuance authorization).

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 tool states it is part of the 'scan_domain audit,' which provides general context. However, it does not offer specific guidance on when to choose `check_caa` over other DNS checks like `check_dnssec` or `check_dane`.

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, so the description focuses on what annotations cannot convey: the record is reported 'present but UNVERIFIED' because there is no port-25 certificate probe, and the comparable pipeline in check_dane_https is itself kill-switched. This prevents an agent from over-claiming a passing pin.

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 verb, target and port, then the mechanism, then the caveat and the alternative. Dense but every clause carries signal, though the nested aside about check_dane_https's kill-switch is slightly bulky for this tool's own 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 values need not be explained. For a read-only DNS-analysis tool, the description covers scope, validation depth, the key limitation, and routing to the sibling — nothing needed to call or interpret 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 domain, format and force_refresh are already fully documented. The description adds essentially no parameter-level detail beyond implying the domain is the target; 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 with protocol and port: 'Check DANE/TLSA certificate pinning for SMTP at port 25', then spells out the mechanism (MX resolution, _25._tcp.<mx-host> TLSA lookup, field/DNSSEC validation). It is immediately distinguishable from check_dane_https, which is named explicitly.

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

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

Gives an explicit trigger ('Use when asked if SMTP mail servers publish DANE/TLSA pinning'), an explicit exclusion ('this does not confirm the pin matches the live certificate'), and the alternative ('For HTTPS DANE at port 443, use check_dane_https instead'). Also notes its role in the scan_domain audit.

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 far beyond the annotations (which only declare readOnly/idempotent/openWorld safety) by disclosing a critical behavioral caveat: results are always reported UNVERIFIED, certificate comparison is withdrawn, and a stale pin will NOT be detected. It even names the finding metadata (notAssessedReason probe_vantage_intercepted), which an agent needs to interpret output 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?

Dense but front-loaded, with the purpose stated first and the critical unverified caveat immediately after. Every sentence carries necessary information (scope, caveat, sibling distinction, audit membership), though the run-on caveat sentence is slightly 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?

With an output schema present and full annotation coverage, the description completes the picture by explaining that returned records are present-but-unverified and why. An agent has everything needed to call the tool and correctly interpret the 'not detected' limitation.

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

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

Schema description coverage is 100%, so every parameter (domain, format, force_refresh) is already documented in the schema. The description adds no per-parameter syntax or format details beyond implying the domain feeds the TLSA lookup, 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 ('Verify DANE certificate pinning for HTTPS connections') and even names the exact lookup target (_443._tcp.{domain}). It explicitly distinguishes itself from the nearest sibling, check_dane (SMTP/port 25), so an agent can route 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?

Provides clear usage context: HTTPS DANE checking, the port-25 SMTP sibling it is NOT, and its place in the scan_domain audit. It lacks explicit 'when not to use' guidance relative to other TLS-ish siblings like check_svcb_https or check_ssl, but the primary routing decision is well covered.

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

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

Annotations already establish that this is a read-only, idempotent, open-world, non-destructive operation. The description adds useful context by naming the blocklist sources and mentioning decoded return codes, but does not discuss caching behavior, rate limits, or other operational details beyond what annotations and schema 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?

The description is two tight sentences that front-load the core action and list the sources checked. Every sentence contributes directly to understanding the tool's purpose.

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 strong annotation coverage, the description provides enough context to call the tool correctly: what it checks, which blocklists it uses, and what kind of result it returns. It could be more complete by distinguishing itself from nearby reputation-checking siblings, but no critical gap remains for invocation.

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

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

Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds no parameter-level semantics beyond what the schema provides; its mention of decoded return codes relates to output rather than input parameters.

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

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

The description states a specific verb and resource: checking domain reputation against DNS-based Domain Block Lists, and names Spamhaus DBL, URIBL, and SURBL. This distinguishes it from broader reputation checks, though it does not explicitly contrast with sibling tools such as check_rbl or check_mx_reputation.

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 'Check domain reputation against DNS-based Domain Block Lists', which signals when this tool is relevant. However, it provides no explicit when-not-to-use guidance or routing to alternatives like check_rbl for IP-based lists.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive behavior. The description adds useful context beyond annotations by explaining that it probes common selectors, validates signing algorithms, and reports key strength.

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 purpose and followed by behavior and usage context. No wasted text.

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?

Complete for an agent: annotations cover safety profile, the schema fully documents parameters, an output schema exists, and the description explains what the tool checks and why to use 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 all four parameters including selector omission behavior. The description adds little parameter-level detail beyond what the schema provides, such as format or force_refresh semantics.

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

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

States a specific verb and resource: look up DKIM records for a domain. The description also distinguishes the tool from broader email-auth siblings by focusing on DKIM signatures, selector probing, signing algorithms, and 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?

Gives a clear use case: verify that outbound email signatures are cryptographically sound, and notes it is part of the scan_domain audit. It does not explicitly say when not to use it or name alternative sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered structurally. The description adds the useful facts that it inspects live DNS and is a component of the scan_domain audit, giving the agent context about scope and relation to a larger workflow. It stops short of noting caching behavior, though the force_refresh param implies 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?

Front-loaded with the core action and scoped alternatives in three tight sentences. Slight redundancy between 'Shows the enforcement level (none/quarantine/reject)' and 'Use to determine a domain's DMARC enforcement level' repeats content without adding a new decision cue.

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, so return-value explanation is unnecessary, and annotations cover the safety profile. The description supplies purpose, output semantics at a high level, sibling disambiguation, and audit lineage, which is everything an agent needs 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% with three well-documented params, including the format enum and force_refresh purpose, so the schema carries the load. The description adds no parameter-level guidance such as when 'compact' vs 'full' is appropriate or when a refresh is warranted, so the 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 ('Look up and validate the DMARC record for a domain') and enumerates what is surfaced: enforcement level, alignment mode, and reporting destinations. It explicitly distinguishes itself from check_shadow_domains and assess_spoofability by name, 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?

Provides an explicit 'Use to determine...' clause with three concrete decision contexts (enforcement level, aggregate reporting, impersonation protection) and names the two nearest siblings it should not be confused with. Both when-to-use and the alternatives are stated, not inferred.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real value by disclosing which algorithms are reported, that deprecated ones (RSA/SHA-1, DSA) are flagged, and that results are independent of chain validation 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?

Front-loaded with the core action and reporting scope, then usage and placement. The 'Use when asked what algorithm is used for DNSSEC signing keys' clause mildly restates the opening sentence, a small 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 annotations covering the safety profile and an output schema covering return values, the description supplies what the agent needs: scope, what is reported, and what is flagged. Nothing critical is missing; only minor alternative routing detail is implied rather than stated.

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 in the schema, so the baseline is 3. The description adds no extra meaning about parameter behavior beyond the schema.

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

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

States a specific verb ('Audit') and resource ('cryptographic strength of DNSKEY signing algorithms'), and explicitly scopes the tool as assessing algorithm choice 'independent of whether the DNSSEC chain validates', which separates it from check_dnssec and check_dnssec_chain.

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

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

Gives explicit trigger conditions ('Use when asked what algorithm is used for DNSSEC signing keys, or if deprecated DNSKEY algorithms are in use') and positions it within the scan_domain audit. It implies but does not directly name the chain-validation siblings as the alternative to use for validation results.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description still adds real value beyond that: it names the records inspected (DNSKEY, DS) and the threat model (cache poisoning, spoofing), and describes the verdict returned (enabled and validating). It stops short of discussing latency or cache behavior for force_refresh, but the schema covers that.

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

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

Three short sentences, front-loaded with the core action and its scope. There is mild redundancy between "Check DNSSEC status" and "Reports whether DNSSEC is enabled and validating," but the threat-model sentence earns its place by explaining why the check matters.

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, annotations cover the safety contract, and the schema fully documents the three parameters. The description supplies the validation method and outcome semantics; the only notable omission is how this differs from check_dnssec_chain, which matters given the dense check_* sibling set.

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, including the auto-detection behavior of format and the cache-bypass semantics of force_refresh. The description adds nothing parameter-specific, which is the expected baseline when the 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 and resource ("Check DNSSEC status for a domain") and explains the mechanism it validates (DNSKEY and DS records) plus the outcome reported (enabled and validating). However, it never distinguishes itself from the very close sibling check_dnssec_chain, so an agent must infer the boundary between a basic status check and a chain validation.

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

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

"Part of the scan_domain audit" gives some routing context, implying it can be run standalone or as part of a broader scan. But there is no explicit when-to-use guidance and no mention of alternatives such as check_dnssec_chain, check_dnskey_strength, or check_dane, which overlap heavily with this tool.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is fully covered. The description adds the per-zone walking behavior (DS/DNSKEY, algorithm usage at each level), which is useful context, but it says nothing about latency, number of network round trips, or cache behavior beyond what the force_refresh parameter implies.

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

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

Two sentences, front-loaded with the core action and followed by usage guidance, 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?

With an output schema present and annotations covering the safety profile, the description needn't explain return values. It is complete for invocation purposes, though a hint about whether it performs live network queries (versus cached reads) would round it out given the openWorldHint.

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 the enum and caching parameter are self-documenting, so the baseline is 3. The description adds no syntax or format detail beyond what the schema already provides.

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

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

The description gives a specific verb and scope: walk the full DNSSEC chain of trust from the DNS root to the target, tracing DS/DNSKEY and algorithm usage per zone. This distinguishes it conceptually from the sibling check_dnssec by emphasizing the full root-to-domain delegation path, but it never names that sibling explicitly.

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

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

It states when to use it — tracing the chain of trust from the root, or viewing the full delegation path step by step. There is no explicit when-not or named alternative (e.g., check_dnssec for a flat check), which keeps it 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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the tool issues multiple query rounds rather than a single lookup, and it compares answer sets and TTLs across rounds. It omits cost/latency implications of those repeated queries and how caching interacts with the check.

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 verb and resource, with no filler. There is mild redundancy in restating the malicious-infrastructure motivation twice ('botnet or malicious infrastructure' then 'to hide malicious activity').

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 the description covers what is detected and how. What is missing is practical guidance about the repeated-query cost and when the extra rounds matter, which is relevant given the rounds parameter.

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

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

Schema description coverage is 100%, so domain, format, rounds and force_refresh are all already documented, which sets the baseline at 3. The description mentions 'multiple rounds' generically but adds no detail on round count, caching, or output verbosity beyond what the schema states.

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

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

The description states a specific verb and resource ('Detect fast-flux DNS behavior') and explains the mechanism: multiple rounds of A/AAAA queries with IP-rotation and TTL comparison. That makes it clearly distinguishable from generic DNS siblings in practice, though it never names a sibling like check_resolver_consistency or check_realtime_threat_feed.

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 only implied by the phrase 'a sign of botnet or malicious infrastructure', which suggests threat investigations, but there is no explicit when-to-use, when-not-to-use, or alternative named among the many sibling check_* tools. An agent must infer the context itself.

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) and open-world access, so the bar is low; the description still adds real value by disclosing that it detects CDN/WAF interception (a potential source of misleading results) and that findings are per-header rather than a single verdict. It doesn't mention rate limits or how non-HTTPS domains are handled.

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

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

Two sentences, zero filler, with the core action front-loaded and the header list and return shape following in priority order. Every clause (headers named, attack classes, CDN/WAF detection) contributes useful 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-format detail isn't strictly required, yet the description still summarizes the finding shape. Combined with annotation coverage and full schema docs, an agent has what it needs; only edge behavior (non-HTTPS targets, scan duration) is 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?

Schema description coverage is 100% — domain, format enum, and force_refresh are all documented in-schema, including the cache-bypass rationale. The description adds no parameter-level meaning 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 and resource ('Audit a domain's browser-facing HTTP security headers over HTTPS') and then enumerates exactly which headers are inspected. This clearly separates it from siblings like check_ssl (certificates) or check_spf (email auth) without the agent needing to open 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?

The closing line 'Part of the scan_domain audit' tells the agent this is a component check that can be run standalone or as part of the broader scan. It gives clear context but names no exclusions or explicit 'use X instead when...' rule against the many sibling check_* tools.

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

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

Adds substantial behavior beyond the readOnly/idempotent/openWorld annotations: dedupe of same-origin vs external links, dangling-CNAME sweeps, deprovisioned-service fingerprints, npm/PyPI registry lookups for install commands, and OSV MAL- advisories. It also honestly caveats 'evidence of a dangling service, not proof it can be claimed' and lists unmeasured items under notAssessed. A 5 is withheld only because response/caching details are left to the output schema.

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

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

Front-loaded with the core action and resource, then layered with the three detection mechanisms and the detection-only caveat. It is dense but nearly every clause carries new information; only the long parenthetical chains risk slowing the 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?

Given a dedicated output schema, full-coverage parameter docs, and annotations covering the safety profile, the description supplies exactly the remaining needed context: what is inspected, how deep the checks go, and that results are detection-only with unmeasured items surfaced in notAssessed.

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 inline. The description adds no syntax or format guidance 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 (Inspect) and exact resources (/llms.txt and /llms-full.txt) plus the scope (links and install instructions an agent could inherit). An agent can distinguish this from check_agent_discovery or scan_domain 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?

Usage context is implied by the description's framing (supply-chain inheritance risk in llms.txt) and the 'Detection only; not scored' caveat, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling check_* tools.

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

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds useful behavioral context by clarifying that results concern active attacker-registered character-substitution and visual-confusion domains used for impersonation or phishing, though it does not discuss caching or output characteristics.

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 detection purpose, then briefly elaborates the threat type, then ends with useful sibling differentiation. Every sentence contributes to selection or understanding with no wasted text.

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

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

The tool is a focused check with full schema coverage, rich annotations, and an output schema. The description supplies the purpose, threat model, and sibling distinctions an agent needs before invoking it, so no additional return-value explanation is necessary.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description adds no parameter-specific meaning, which is acceptable at the baseline for fully documented schemas but not above it.

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

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

The description uses a specific verb and resource: detecting active typosquat, lookalike, and homoglyph domains that impersonate a brand. It also explicitly distinguishes the tool from check_shadow_domains and discover_brand_domains, so an agent can identify its role without inspecting 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?

It names the relevant sibling alternatives and explains their distinct scopes: check_shadow_domains covers TLD variants with auth gaps, while discover_brand_domains covers legitimate portfolio discovery. Combined with the phishing-impersonation framing, this gives clear routing guidance.

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

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds real substance: it discloses the two network operations performed (DNS TXT lookup and policy file fetch) and what is reported (mode enforce/testing/none plus MX coverage). It does not mention caching behavior, though the schema's force_refresh parameter covers that.

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

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

Three sentences, each carrying distinct information: what is checked, how it is checked and reported, and when to use it versus the sibling. The core purpose is front-loaded with no 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?

Input schema is fully documented, an output schema exists so return values need no explanation, and annotations cover the safety profile. The description fills the remaining gap by explaining the mechanism and the sibling relationship — nothing an agent needs in order to call 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 description coverage is 100% with all three parameters documented, including the enum for format and the cache-bypass semantics of force_refresh. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb and resource: checks whether a domain enforces SMTP TLS via MTA-STS against downgrade attacks. It also names the exact mechanisms queried (_mta-sts.<domain> record plus policy file) and contrasts itself with check_dane, so the agent can distinguish it from dozens of sibling check_* tools 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 an explicit use case ('verify whether inbound SMTP is protected against TLS downgrade or MITM'), names the alternative that covers a different mechanism ('distinct from check_dane which uses TLSA pinning'), and situates it in the larger workflow ('Part of the scan_domain audit').

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

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

Annotations already declare readOnly, idempotent and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context — that results identify the hosting provider and that this is a component of the scan_domain audit — which an agent cannot get from the annotations or 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: purpose, enrichment detail, then usage trigger. Front-loaded and no 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?

Output schema exists so return values need no explanation; annotations cover safety; all three parameters are documented in the schema. The description supplies the remaining context an agent needs — what the data means and where it fits in the broader audit.

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

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

Schema description coverage is 100%, so domain, format and force_refresh are all documented at the schema level. The description adds no guidance on when to pick compact vs full output or when a refresh is warranted, so it stays at the baseline.

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

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

States a specific verb and resource ("Look up MX records for a domain") and immediately elaborates what that reveals: inbound mail servers and hosting provider (Google Workspace, Microsoft 365, Proofpoint). That provider-inference framing separates it from generic DNS siblings like check_ns or check_txt_hygiene.

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 triggering question ("Use when asked which email provider hosts inbound mail") plus a secondary use case (inspect MX configuration). It does not exclude the adjacent check_mx_reputation sibling, so an agent facing a mail-hygiene question has to infer which to call first.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds real context beyond them: which blocklists are consulted and that reverse DNS for MX hosts is also verified. It stops short of noting latency or rate-limit considerations when querying multiple RBLs for multiple MX hosts, which is the main remaining unknown for a network-heavy check.

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, front-loaded with what is checked and the named blocklists, then the additional reverse-DNS behavior, then the usage guidance and sibling distinction. No 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 a full input schema, an output schema, and rich annotations, the description needs only to convey purpose, scope, and tool selection — all of which it does. The mention of which blocklists and the extra reverse-DNS check rounds out expectations for the 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 coverage is 100%, so domain, format, and force_refresh are already documented, including the cache-bypass purpose of force_refresh. The description adds nothing about parameter behavior (e.g., what 'compact' returns or when auto-detection picks a format), 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: checks whether MX IPs are listed on named blocklists (Spamhaus, Barracuda, SORBS, other RBLs), plus an additional reverse-DNS verification. It explicitly distinguishes itself from check_rbl, so an agent can pick between 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?

Gives an explicit trigger ('when you want to know if your mail server IP is blacklisted, or if your MX is on any blocklist') and names the alternative tool plus the condition that selects it ('distinct from check_rbl which checks a specific IP directly'). 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 read-only, idempotent, open-world, and non-destructive behavior. The description adds substantive context beyond that: it explains that it directly compares parent and child NS sets, verifies authoritative AA responses, checks required glue addresses, and conditions these probes on infrastructure availability.

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 a clear purpose statement and then progressively adds usage and behavioral context. All four sentences earn their place, though the final 'Part of the scan_domain audit' sentence is slightly less critical than the rest.

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

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

Given the presence of an output schema and annotations that cover the safety profile, the description is complete enough. It explains what the tool audits, when to use it, and what it checks behaviorally, leaving no obvious gap for an agent 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 fully documents the domain, format, and force_refresh parameters. The description adds no parameter-specific syntax or format details beyond what the schema provides, 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 states a specific verb and resource: 'Audit a domain’s nameserver delegation and redundancy.' It further distinguishes its scope by mentioning parent/child NS comparison, AA verification, and glue checks, which sets it apart from sibling tools like check_dnssec or check_mx.

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

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

It provides clear when-to-use guidance: 'Use to detect stale registrar delegations, lame nameservers, and intermittent resolution risk' and notes it is 'Part of the scan_domain audit.' However, it does not explicitly name alternatives or when-not to use this tool versus related siblings such as check_authoritative_dns_infra.

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 useful substance by naming what is inspected (NSEC3PARAM) and what constitutes a finding. It says nothing about caching behavior (which force_refresh implies exists) or query cost, so it stops short of rich disclosure.

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

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

Two sentences, zero filler, and the core action is front-loaded ahead of the detection detail. Every clause contributes information an agent could not get from the name alone.

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

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

For a single-domain, three-parameter read check with a 100%-covered schema and an output schema, the description covers purpose and detection scope adequately. The only real gap is how this differs from the general DNSSEC siblings, which matters in a catalog 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% and each of the three parameters is documented in the schema, including the format enum and the cache-bypass semantics of force_refresh. The description adds no parameter meaning 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 and resource ('Assess zone walkability risk by analyzing NSEC3PARAM configuration') and enumerates the three conditions detected (plain NSEC, weak NSEC3 params, opt-out), so the agent knows exactly what is being tested. It does not, however, distinguish itself from close siblings like check_dnssec or check_dnssec_chain, leaving overlap to inference.

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 only implied by the purpose: an agent can infer this is the tool for DNSSEC zone-enumeration exposure. There is no explicit when-to-use, when-not-to-use, or pointer to check_dnssec/check_dnssec_chain for the general DNSSEC case.

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 only that this is part of a domain audit; it does not discuss rate limits, caching (the force_refresh semantics live in the schema), or what a failure result means, so it contributes modest value beyond the 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?

Two tight sentences with the operation front-loaded and the audit-relationship context second. No filler, no restatement of 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 values need not be described, and annotations cover the safety profile; the description is adequate for a single-domain read check. It stops short of noting what 'forward-confirmed' requires (forward A lookup matching the PTR name) or how results relate to the scan_domain findings, which would make it fully self-sufficient.

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

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

Schema description coverage is 100% with all three parameters documented, including the format enum and the force_refresh cache-bypass rationale. The description adds no parameter-level information, 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?

Uses a specific verb ('Verify') with a precise technical resource ('forward-confirmed reverse DNS (PTR/FCrDNS)') and scopes it to mail servers. An agent can distinguish this from check_mx or check_spf, though the description does not explicitly contrast against the many other DNS-record checking siblings.

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

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

'Part of the scan_domain audit' implies this is a sub-check of the broader audit and signals the alternative (run scan_domain for the full sweep), but there is no explicit when-to-use/when-not guidance and no mention of prerequisites such as needing a resolvable MX/PTR record first.

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

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

Annotations already cover readOnly, idempotent, non-destructive, and openWorld, so the safety profile is settled. The description adds real behavioral context beyond that: the tool first resolves MX hosts to IPs, meaning it implicitly depends on MX records existing and on live DNS queries to third-party blocklists. It omits caching behavior (implied only by the force_refresh param) and per-blocklist query limits.

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

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

Two tight sentences that front-load the core action and follow with the methodological prerequisite. Minor flaw: it claims '6' blocklists but enumerates only five (SpamCop, UCEProtect, Mailspike, Barracuda, PSBL), an internal inconsistency that wastes a little trust.

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 rich annotations, the description needn't explain return values, and it correctly covers the MX-to-IP resolution step an agent should know about. The remaining gap is behavioral edge cases (what happens with no MX records) and disambiguation from sibling reputation 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%, so domain, format, and force_refresh are already fully documented with examples and rationale. The description adds no syntax or semantics beyond the schema; 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 IP reputation against DNS-based RBLs) and adds important scoping detail that the target is MX server IPs, plus the actual list of blocklists consulted. It is clear what the tool does, but it never distinguishes itself from the near-identical siblings check_mx_reputation, check_dbl, or check_realtime_threat_feed.

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 or when-not guidance, and no alternative is named despite several closely overlapping siblings (check_mx_reputation, check_dbl, check_realtime_threat_feed). The agent must infer from the name alone which of these overlapping reputation tools to call.

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 genuinely new behavioral context: the feed is a curated intel-gateway source and the tool degrades gracefully to an informational result when unprovisioned, which prevents the agent from misreading an empty/low-confidence answer as 'clean'.

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 clauses, front-loaded with the core action and no filler. The parenthetical '(curated intel-gateway feed)' is the only marginally expendable fragment, but it does distinguish the data source from a generic threat feed.

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 provisioning caveat covers the main failure mode. For a single-domain, three-parameter read tool this is close to complete; only expected latency or coverage limits are unaddressed.

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, including the enum and the cache-bypass rationale. The description adds no parameter-level meaning 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 and resource ('Check a domain against BlackVeil real-time threat intelligence') and immediately scopes it against a likely-confused category ('Distinct from DNSBL checks'). An agent can tell this apart from check_rbl, check_dbl, and check_mx_reputation 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?

The DNSBL exclusion gives a clear negative condition, and 'Operator-deploy only; degrades to info when unprovisioned' tells the agent when results will be informational rather than a real verdict. It stops short of naming the specific sibling tools (check_rbl/check_dbl) or stating positive triggers such as 'use when investigating suspected malicious reputation'.

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 fully covered. The description adds one useful behavioral fact — that it queries four public resolvers, implying external network calls and that differences reflect propagation or GeoDNS — but does not explain what constitutes 'inconsistency' or what is reported per resolver.

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 with no filler, appropriate for a read-only diagnostic with one required parameter. It is efficient but arguably too terse given the ambiguity around what a consistency result actually means.

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

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

The tool is simple (3 params, one required, no output schema, no nesting) and annotations cover safety, so the description is close to adequate. However, it omits which resolvers are used and what the verdict looks like, which matters for interpreting a cross-resolver comparison in a large DNS-tooling suite.

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 enum values or constraints, so the schema already does the heavy lifting. The description adds only the implicit point that the resolver set is fixed (four public resolvers) rather than parameterized, and says nothing about how record_type or format shape the comparison.

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 ('DNS consistency') with a concrete scope ('across 4 public resolvers'), which is more precise than the bare name. It implicitly distinguishes itself from per-record siblings like check_ns or check_mx by focusing on cross-resolver agreement, but it never names those siblings to make the distinction explicit.

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 on when to use this versus check_ns, check_authoritative_dns_infra, check_root_server_set, or compare_domains, all of which are adjacent concerns. The agent must infer that this is a propagation/consistency diagnostic rather than an authoritative-configuration check.

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 behavior, so the safety profile is covered. The description adds context the annotations cannot: each call samples only 3 rotating root servers, so consecutive calls may return different observations, and the env-var dependency changes whether results are real probes or static reference data. Minor tension with idempotentHint, but that hint concerns side effects, not identical output, so it is not a contradiction.

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

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

Two dense sentences with no filler; the sampling behavior and the comparison targets lead, and the degraded-mode caveat follows. Every clause carries information an agent needs.

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

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

With an output schema present, return values need no explanation, and annotations cover the safety profile. The description still supplies the two non-obvious facts (3-server rotating sampling, probe-optional degradation), leaving only minor gaps like expected latency or frequency limits.

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

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

Schema coverage is 100% and the single optional format enum is documented with auto-detection behavior in the schema itself. The description adds nothing about the parameter, 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 (query root servers) plus the exact dimensions compared: priming NS set, glue, SOA serials, and cross-root consistency. No sibling tool targets the root server set, so an agent can route here unambiguously from the name and 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?

Gives clear operational context: it works best with BV_INFRA_PROBE available, and without it returns embedded hints as reference data only, which tells the agent when the output is actionable vs. informational. It stops short of naming alternatives such as check_resolver_consistency or saying when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it reports on email authentication posture of the variants and frames results as spoofing risk. It does not mention whether TLD coverage is a fixed curated list or exhaustive, nor any per-call cost, 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?

Two sentences, zero filler: the first defines the operation and its risk framing, the second handles routing. The key distinguishing information is front-loaded before the sibling comparison.

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 all params documented, the description need not explain return values, and annotations carry the safety profile. What remains unstated is scope breadth (how many TLDs are evaluated, whether the root domain itself is included), which slightly affects interpretation of results.

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 only the example domain, which duplicates the schema's own example. 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 and resource: 'Find alternate TLD variants of a domain', with a concrete example (example.net, example.co) and the security rationale (weak/missing email auth). It explicitly marks the boundary with check_lookalikes, so an agent can distinguish the two TLD-adjacent tools 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?

'Use when asked about TLD variants with email auth gaps' gives an explicit trigger condition, and the trailing clause names the alternative tool (check_lookalikes) with the reason it is not a substitute (typosquat/homoglyph). This is a clean when-to-use plus negative routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond them by disclosing what the output contains: whitelisted senders, flagged syntax errors, and the exposed trust surface. It stops short of noting rate limits or how stale/cached results are signalled.

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 its outputs, with the usage cue and audit context at the end. There is mild redundancy between "Lists all IP addresses and third-party senders authorised to send email" and "Use when you need to know who is permitted to send email", but nothing is wasted at length.

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-shape explanation is not required, and annotations carry the safety profile; the description covers scope, outputs and a usage cue. It is only slightly thin on how this tool relates to resolve_spf_chain and scan_domain, which matters given the dense sibling set.

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 every parameter (domain, format enum, force_refresh) is documented in the schema itself. The description adds no parameter-level meaning, such as what 'full' vs 'compact' actually changes or when to set force_refresh beyond the schema note, 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+resource ("look up and validate the SPF record for a domain") and enumerates the outputs (IPs, third-party senders, syntax errors, trust surface). It is clearly distinguishable from DMARC/DKIM siblings by resource, though the near-neighbour sibling resolve_spf_chain is never mentioned, so full sibling differentiation is incomplete.

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 an implied trigger condition, and "Part of the scan_domain audit" hints at orchestration context. But there are no exclusions and no routing to alternatives such as resolve_spf_chain (for recursive/flattened lookups) or scan_domain (for a full audit), leaving the agent to infer.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior. The description adds value beyond them: parallel probing of 19 prefixes, the returned artifacts (discovered services + insecure-advertisement flags), and a genuine caveat that absence of matches is not proof of no services. It omits freshness/caching semantics that would fully close the loop.

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 well-scoped sentences: behavior, return/caveat, and usage trigger, all front-loaded and earning their place. Slightly dense but no 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, full schema coverage, and annotations covering safety, the definition gives an agent enough to call correctly, plus an important false-negative caveat. Minor gaps like caching behavior don't undermine 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%, so each of the three parameters is already documented in the schema. The description adds no syntax or format detail for domain/format/force_refresh, 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 ('Map') and resource ('DNS-visible service footprint'), plus the exact mechanism (probing 19 common SRV record prefixes across email, calendar, messaging, directory, web). This clearly differentiates it from DNS siblings like check_svcb_https and check_mx, which share the SRV/record space.

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?

Ends with an explicit usage trigger ('Use when asked to map DNS-visible services or flag insecure service advertisements'). However, it never names or routes to an alternative sibling when that condition isn't met, so no exclusions are given.

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 substantial behavioral context beyond the annotations: certificate metadata comes from public Certificate Transparency logs and may describe a different certificate than the one currently served. It also discloses that origin TLS protocol support and cipher suites are not assessed and that legacy-TLS detection has been withdrawn because the probe cannot observe the origin handshake. These are exactly the kind of limitations an agent needs to know.

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 four sentences with zero waste and front-loads the core scope before explaining the CT-log caveat and use case. Every sentence earns its place, including the important limitation about not assessing origin TLS and the note that it is part of the scan_domain audit.

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

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

Given that an output schema exists, the description does not need to explain return values. It fully covers what the tool does, what it does not do, a critical caveat about CT-log certificate metadata, and its relationship to the broader scan_domain audit, leaving no important gap for an agent.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description does not add any parameter-specific meaning beyond what the schema provides, making the baseline score of 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?

The description states a specific verb and resource—checking HTTPS/TLS posture of a domain—and enumerates the exact checks: HTTPS reachability, HSTS policy, HTTP-to-HTTPS redirect, and certificate metadata. It also explicitly scopes out origin TLS protocol support and cipher suites, though it does not name a sibling tool such as check_http_security or check_dane_https to differentiate directly.

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

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

It gives a clear use case: verify HTTPS/HSTS configuration and certificate issuer/expiry, and notes it is part of the scan_domain audit. It does not explicitly state when to prefer an alternative sibling tool, but the scope exclusions (no origin TLS/cipher assessment) provide implicit guidance about what this tool is not for.

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 establish that this is a read-only, idempotent, non-destructive, open-world check. The description adds useful context about what it inspects—the SPF include chain and dangling subdomains—but does not disclose caching behavior, rate limits, or other operational traits beyond what the schema and annotations already convey.

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

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

The description is front-loaded and adequately short, but the second sentence largely restates the same idea as the first: checking whether an SPF include chain can be hijacked through a dangling domain. That redundancy 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?

For a focused read-only check with an output schema and rich annotations, the description supplies enough purpose and usage context. It lacks explicit sibling-tool routing and operational detail, but 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 coverage is 100%, so all three parameters are already documented in the schema. The description adds no parameter-specific guidance beyond the domain being the target of the SPF include analysis, 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?

The description names a specific verb and target: it detects SubdoMailing risk by analyzing the SPF include chain for dangling or hijackable subdomains. It clearly distinguishes this from general SPF or subdomain-takeover checks by focusing on the email-sending abuse path.

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

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

It gives clear usage context: use it when you want to know if an SPF include chain can be hijacked through a dangling domain, or to detect mailing risk hidden in SPF includes. It does not, however, name specific alternative tools such as resolve_spf_chain or check_subdomain_takeover, so the routing guidance is strong 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 readOnly, idempotent, non-destructive, open-world behavior, so the description need not restate safety. It adds real value by disclosing the default built-in 15-name sweep versus a user-supplied list, and the provider coverage scope. It stops short of stating rate-limit or timing expectations for a live DNS sweep.

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 and vulnerability class before the provider list and usage notes. Dense but every clause carries information; the provider enumeration is slightly long but useful for scope-setting.

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 so return values needn't be explained, and annotations cover the safety profile. The description supplies the default-behavior context and the sibling caveat, leaving only minor gaps like runtime expectations for a live external 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 coverage is 100%, so the baseline is 3. The description's note about subdomain sourcing echoes what the schema already documents for the subdomains parameter; it adds only marginal semantics (CT enumeration / brand-audit sourcing) beyond structured fields.

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

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

States a specific verb (sweep/check) and resource (subdomains), and precisely names the vulnerability class (dangling CNAMEs to deprovisioned cloud services claimable by an attacker). It enumerates 16 provider families, which distinguishes it sharply from siblings like check_subdomailing or discover_subdomains.

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 triggering condition ('Use when asked if subdomains are pointing to deprovisioned cloud services') and an explicit pairing instruction with discover_subdomains, including the crucial caveat that discover_subdomains returns a CT sample rather than a full inventory. That is exactly the routing information an agent needs.

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 elsewhere. The description adds no behavioral context beyond that - nothing about caching behavior (only the parameter schema mentions cache bypass), rate limits, or what happens when no SVCB record exists. With a rich annotation set the bar is lower, but this adds essentially nothing.

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

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

Two compact sentences with the resource and standard front-loaded; nothing is padded. The second sentence is short but slightly ambiguous - it is unclear whether scan_domain invokes this tool or whether this is an alternative to it.

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 and all parameters are documented in the schema, so return values and inputs need no further explanation. What remains missing is selection guidance in a crowded namespace of similar check_* tools, which is the one thing the description should have supplied.

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 including the format enum and force_refresh cache semantics are already fully documented in the schema. The description contributes no additional parameter guidance, 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?

States a specific verb ('Validate') and resource ('HTTPS/SVCB records'), plus the RFC 9460 standard and the capability being tested ('modern transport capability advertisement'). This is clear enough to act on, but it never distinguishes itself from near-siblings like check_dane_https or check_srv, which an agent could easily confuse it with.

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' gives a usage context, implying it is a component of a broader audit rather than a standalone entry point. However, there is no explicit when-to-use vs when-not, no mention of prerequisites (e.g., requires prior NS/DNSSEC checks), and no routing to or away from the overlapping DANE/SRV tools.

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

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

Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered. The description adds real value beyond that: what is queried, what rua destinations are accepted, and the three failure conditions it flags (missing, duplicate, invalid/absent URI). It does not mention caching behavior explicitly, though force_refresh's presence implies a cache.

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 tightly packed sentences with the core action front-loaded and the validation semantics following. Dense but not padded; the 'Part of the scan_domain audit' clause earns its place by giving context.

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

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

With an output schema present, return-value explanation is unnecessary, and parameters plus annotations are fully documented in structured fields. The description supplies purpose, target record, accepted rua schemes, and failure modes — enough to call correctly. Minor gaps: no explicit caching note and no contrast with the broader batch/audit entry points.

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 documented in the schema, which establishes the baseline of 3. The description adds the domain semantics indirectly by naming the query pattern, but says nothing about the format or force_refresh parameters beyond what the schema already conveys.

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), a specific resource (TLS-RPT for a domain), and even the exact DNS name queried (_smtp._tls.<domain>) plus the record type and validation logic. It explicitly positions itself against a sibling: 'Complements MTA-STS'.

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 for when the tool is relevant ('Part of the scan_domain audit', complements MTA-STS for TLS delivery failure visibility), but doesn't state explicit exclusions or say 'run X instead when Y'. The invocation context is clear without alternatives being spelled out.

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, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuine analytical context by naming the two detection classes (stale entries, SaaS exposure), but says nothing about cache behavior despite force_refresh existing, nor about output shape.

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 with zero filler, though it is arguably too terse for a tool with three parameters and two distinct detection modes.

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. Still, the description leaves 'stale' and 'SaaS exposure' undefined and gives no invocation context, which is thin for a tool whose main value is interpretation of findings.

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 force_refresh cache-bypass rationale and the format enum. The description adds nothing 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?

States a specific verb (audit) and resource (TXT records) plus the two things it looks for: stale entries and SaaS exposure. That distinguishes it reasonably from sibling record checks like check_spf or check_dmarc, though it never names a sibling explicitly.

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