dns

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

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

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

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

Three sentences with clear information architecture: purpose, output, usage/alternatives. No wasted words; every sentence earns its place.

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

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

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

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

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

Schema description coverage is 100%, with detailed per-param explanations (e.g., baseline's 'cached' literal and exclusion of policy objects). The description itself doesn't add parameter-level semantics beyond schema, so a baseline 3 is appropriate.

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

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

The description states the tool measures DNS security posture change against a prior snapshot, using specific verbs and resources. It explicitly distinguishes from compare_baseline by contrasting improvement-over-time vs compliance-to-policy, differentiating it from a key sibling tool.

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

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

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

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

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

Beyond the annotations (readOnlyHint, destructiveHint, idempotentHint), the description discloses important runtime behaviors: the requirement for m365Proxy service binding, the 'unprovisioned' fallback, and the 'representative' sample-data flag until live Graph reads are available. These are not apparent from annotations alone and add significant transparency.

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

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

The description is three sentences with no filler. It front-loads the primary purpose, then adds necessary caveats in a logical order. Every sentence contributes essential information.

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

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

The description covers the tool's purpose, dependency, fallback, and data representativeness, which is strong given no output schema. However, it does not outline the overall response structure beyond the mentioned fields, so it leaves some ambiguity about the main result format. Still, it is largely complete for accurate selection and invocation.

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

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

The input schema fully describes the only parameter ms_tenant_id with clear text ('Microsoft Entra tenant ID (GUID or domain)'), so the baseline is 3. The description adds no additional parameter-level meaning beyond the schema, so no higher score is warranted.

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 'Assess' with a clear resource ('Conditional Access coverage gaps for a Microsoft Entra tenant') and identifies the exact deliverable: 'users and apps not protected by any enforced policy.' This distinguishes it from sibling tools like get_ca_policies or analyze_drift.

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

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

The description provides clear context for when to use the tool: when you need to identify coverage gaps in Conditional Access. It also mentions a prerequisite (m365Proxy service binding) and fallback behavior. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

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

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

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

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

Two sentences, no repetition of schema content, and the most important information (what the tool does and its output) is front-loaded. Every phrase serves a purpose, with the usage note placed last as a natural call to action.

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

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

The tool has no output schema, so the description's explanation of returned data (risk level, sub-scores, summary) is valuable. It covers the core behavior and usage context. Minor gaps like handling of invalid domains or network-only data sources exist, but they are not critical for a read-only, idempotent tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description doesn't add parameter-level details beyond what the schema already provides (domain, format, force_refresh). It doesn't harm, but it also doesn't compensate further.

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

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

The description starts with a specific verb ('Compute') and clearly names the resource ('composite email spoofability risk score'), including the 0–100 scale and direction. It explicitly distinguishes itself from sibling tools like check_spf, check_dmarc, and check_dkim by framing this as a combined/composite assessment rather than a single-control check.

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

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

The description gives explicit usage triggers: 'Use when asked how easy it is to spoof email from a domain, or for a composite email spoofing risk score.' It implies alternatives (individual control checks) exist among siblings but does not name them or state when NOT to use this tool. This is clear context but lacks exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable context beyond annotations: the parallel execution up to 10 domains, the output includes score and NIST-aligned letter grade, and that it performs a full security audit per domain. It does not fully describe potential rate limits or exact output structure, but the added detail justifies above baseline.

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

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

The description is two sentences long, front-loaded with the core action, and includes the key purpose, output summary, and sibling distinction with zero fluff. Every sentence earns its place.

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

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

For a bulk operation with no output schema, the description adequately communicates input limits (max 10), behavior (parallel, full audit), output (score, grade, finding counts), and intended usage. Combined with strong annotations and complete schema, this is sufficient for an agent to invoke and interpret results correctly.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters: domains, format, and force_refresh. The description reinforces the 'up to 10' limit for domains and mentions parallel execution, but does not add significant semantic 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?

The description clearly states a specific verb and resource: 'Bulk-scan up to 10 domains in parallel' with a full security audit. It explicitly differentiates from the sibling tool compare_domains, making its purpose unambiguous.

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

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

It provides explicit usage context: 'Use when you want to audit multiple domains at once or do a bulk scan of several domains simultaneously'. It also names the alternative compare_domains and clarifies when that sibling is more appropriate (side-by-side analysis of 2–5 domains).

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false. The description adds valuable behavioral context: the operation is asynchronous (returns immediately with an auditId), requires polling for completion, and each target consumes 1 unit of the monthly BRAND_AUDIT_QUOTAS budget. It does not conflict with annotations and provides practical cost/rate information.

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

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

The description is two sentences, front-loaded with the core action and scope, followed by return shape, follow-up tools, and quota impact. Every clause earns its place with no redundancy or filler.

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

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

Given the 10 parameters and async workflow, the description covers the full lifecycle (enqueue → status → report) and notes quota implications. The output schema and per-parameter schema descriptions handle the remaining details. It could briefly mention when to prefer brand_audit_single for a single-domain audit, but the description is otherwise sufficiently complete for correct selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds semantic linkage by mapping workflow concepts to parameters: 'standard/deep discovery depth' (depth), 'brand aliases' (brand_aliases), and 'caller-supplied candidate domains' (candidate_domains). It also clarifies the per-domain quota consumption, enriching the meaning of 'domains'.

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 ('Enqueue') and resource ('async brand audit') with clear constraints ('up to 50 target domains', optional depth/aliases/candidates). It differentiates from siblings by naming brand_audit_status and brand_audit_get_report as follow-up tools, positioning it unambiguously as the batch-start entry point.

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

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

The description clearly conveys when to use this tool: to start an async batch audit across multiple domains, and it provides an explicit follow-up workflow ('poll with brand_audit_status and fetch results with brand_audit_get_report'). However, it does not explicitly contrast with brand_audit_single or state conditions when this tool should not be used, so it lacks a full when-not/alternatives statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, lowering the bar. The description adds substantial behavioral context: conditional response based on target, notReady for in-flight, pdfUrl authentication requirements, and pdfPending for polling. This goes well beyond the annotations with no contradictions.

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

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

Three sentences, all information-dense and front-loaded with the core purpose. Every sentence contributes unique value: fetch semantics, conditional behavior, in-flight and PDF edge cases. No redundancy or fluff.

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

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

Given the simple schema (2 params, no nesting) and presence of an output schema, the description fully covers the tool's behavior across completed, in-flight, and PDF-rendering states. It tells the caller exactly what to expect in each scenario, making it complete for the tool's complexity.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description adds meaningful context by explaining how omitting target changes the response from per-target to audit-level aggregate, which is not evident from the parameter descriptions alone.

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

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

The description begins with a specific verb+resource: 'Fetch the result JSON for a completed brand audit.' It clearly distinguishes the tool from siblings by explaining the difference between per-target and aggregate results, and it is distinct from status/start tools in the sibling list.

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

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

The description provides clear context on when to use it: after a completed audit, with optional target for per-target results. It also explains behavior during an in-flight audit (returns notReady) and PDF rendering states, but it does not explicitly reference alternative tools like brand_audit_status, so usage boundaries are implied rather than explicitly stated.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context: tier-wide monthly quota limits (free/agent=0, developer=50, partner=200, enterprise=500, owner=unlimited) and the classification taxonomy (consolidated, shadowIt, vendor dependency, indeterminate, impersonation). This goes well beyond the structured annotations without contradicting them.

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

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

Three sentences with no filler: the first sentence states purpose and optionals, the second outlines the pipeline, and the third discloses quota gating. Each sentence earns its place, and the most important information is front-loaded.

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

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

For a tool with 11 parameters, an output schema, and over 60 siblings, the description covers the essential context: purpose, pipeline steps, classification categories, and quota constraints. It does not explain every parameter or return value, but those are handled by the schema and output schema. The only minor gap is lack of explicit sibling differentiation, which is acceptable given the description's clarity.

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

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

The input schema provides 100% coverage with detailed descriptions for all 11 parameters, including enums and defaults. The description only lightly echoes a few parameters (depth, brand_aliases, candidate_domains) without adding semantic detail beyond what the schema already documents. Baseline 3 is appropriate because the schema carries 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?

The description opens with a specific verb+resource combination ('Run a full brand audit on a single target') and clearly differentiates from batch/status/report sibling tools by emphasizing 'single target' and 'full brand audit'. It enumerates concrete sub-operations (discover, look up registrar/registrant, classify) and names the classification outputs, leaving no ambiguity about what the tool does.

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

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

The description implies when to use this tool (single-target comprehensive audit) and contrasts with batch operations via 'single target'. It mentions optional depth, aliases, and caller-supplied candidate domains. However, it does not explicitly name alternatives like brand_audit_batch_start or discover_brand_domains, so the guidance is clear but not exhaustive.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds valuable behavioral details: it states the exact status enum, progress format, per-target statuses, and the owner-scoping behavior where foreign auditIds surface as notFound. This significantly enhances the agent's understanding of the tool's behavior.

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

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

The description is two sentences long, front-loaded with the action and resource, and every clause provides distinct value (return types, progress format, owner scoping). No filler or redundancy.

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

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

For a simple single-parameter polling tool with an output schema, the description covers all essential aspects: what it polls, what it returns, and an important edge case (owner-scoped notFound). It is fully sufficient for an agent to invoke and interpret results correctly.

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

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

The schema already provides 100% coverage with a clear description of auditId ('Audit ID returned by brand_audit_batch_start'). The tool description does not add further parameter-specific nuances, but the baseline of 3 is appropriate given the schema's thoroughness.

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

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

The description uses a specific verb 'Poll' and resource 'status of an enqueued brand audit,' clearly distinguishing it from related tools like brand_audit_get_report (which likely retrieves full findings) and brand_audit_single. It also lists the exact return fields, making the tool's function unambiguous.

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

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

The description clearly implies usage after enqueuing an audit, and the schema reinforces this by stating the auditId comes from brand_audit_batch_start. It does not explicitly name alternative tools or exclusion conditions, but the context is sufficiently clear for an agent to know when to use this status poll.

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, non-destructive, and idempotent behavior. The description adds meaningful operational context: it notes the use of Private-Use SVCB param code points pending IANA assignment, the specific record paths checked, and the fact that it's read-only. This goes beyond the structured annotations without contradicting them.

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

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

The description is three dense sentences covering multiple technical aspects without excessive fluff. It front-loads the primary purpose and then details specific behaviors. Slightly run-on but every clause adds value; could be split for readability, but it's appropriately sized for the complexity.

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

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

Given the tool's complexity, the description covers the core behaviors: detection, DNSSEC status, DANE/TLSA evaluation, and capability integrity. Since an output schema is present, return value details are not needed in the description. It could mention how the 'protocol' parameter scopes the check, but that is already in the schema.

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

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

All six parameters have detailed schema descriptions (100% coverage), so the baseline is 3. The description adds high-level context about SVCB records and protocol indices but does not materially enhance individual parameter understanding beyond what the schema already provides. For instance, 'verify_cap' is already well described 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 states the tool's purpose: assessing the security posture of IETF BANDAID agent-discovery records. It enumerates specific checks (SVCB detection, DNSSEC anchoring, DANE/TLSA binding, capability-document integrity), making it distinct from sibling tools like check_dane or check_dnssec by tying everything to the agent-discovery context.

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

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

The specialized scope implies when to use the tool, but the description does not explicitly state when to prefer it over alternatives or provide exclusions. For example, it doesn't mention that generic check_dane would suffice without the BANDAID agent-discovery context. Usage is implied rather than directly instructed.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so the description adds value by disclosing the data sources (BV_INFRA_PROBE) and the types of evidence considered (raw DNS, routing, RPKI, vantage-point). This provides useful contextual behavior beyond the annotations, though it doesn't specify fallback behavior when BV_INFRA_PROBE is unavailable.

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

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

The description is two sentences, with the first sentence front-loading the core purpose and the second adding key evidence sources. There is no redundant information, and it earns a top score for conciseness.

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

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

Given the output schema, annotations, and simple parameter set, the description is mostly sufficient. However, it lacks guidance on selection among the many sibling DNS check tools and doesn't explain the behavior when BV_INFRA_PROBE is unavailable, which is a contextual gap. It covers the basic what and how but not the when.

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

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

The input schema already documents all three parameters with descriptions, and schema coverage is 100%. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate. It doesn't clarify auto-detection of format or force_refresh cache behavior beyond schema.

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

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

The description clearly states the tool's action ('Check') and resource ('authoritative DNS infrastructure posture') for a specific scope ('for a hostname'). This is specific enough to distinguish it from broad or vague descriptions, and it aligns with the tool's name without being a tautology.

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

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

The description provides no explicit guidance on when to use this tool versus the many sibling DNS-related tools (e.g., check_ns, check_dnssec). It only implies usage through the action and resource, but there is no 'use this when' or 'for alternatives, use X' context. The mention of 'when available' refers to BV_INFRA_PROBE, not tool selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by detailing what the tool validates (l=, a=, p=), the DMARC prerequisite, and that it 'Returns findings for a missing/malformed record or unmet prerequisites.' This gives behavioral insight beyond the annotations without contradicting them.

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

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

Three sentences, each earning its place. The first sentence states the action and target. The second explains what is validated. The third gives usage context. No redundancy, no filler, and key details are front-loaded.

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

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

Given the tool's moderate complexity, the description covers the core behavior (checking a DNS record, validating specific fields, returning findings) and its role in a broader audit. An output schema exists but is not included in the description; however, the system provides it separately, so the description need not explain return formats. The only minor gap is not detailing what the 'format' parameter outputs, but that is covered by the schema.

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

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

Schema description coverage is 100%—all three parameters (domain, format, force_refresh) have descriptions. The tool description adds context about the record fields (l=, a=, p=) but does not add new meaning to the parameters themselves. Since the schema already handles parameter semantics, the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Check') with a precise resource ('BIMI brand-logo record at default._bimi.<domain>'). It clearly distinguishes itself from sibling DNS check tools by naming the exact record type and its purpose (validating logo URL, VMC evidence, and DMARC prerequisite). This leaves no ambiguity about what the tool does.

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

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

The description states 'Use to assess brand-indicator readiness in inboxes' and notes it is 'Part of the scan_domain audit,' providing clear context for when to use it. However, it does not explicitly mention when not to use it or name alternative tools (e.g., check_dmarc), so it falls short of a full 5 but is well above a bare minimum.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the audit context and the nature of the lookup, but it does not disclose additional behavioral details such as caching behavior (despite force_refresh param) or any rate limits. No contradiction with annotations.

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

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

The description is two concise sentences, front-loaded with the primary purpose, and every sentence adds meaningful context. No wasted words.

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

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

For a simple read-only DNS lookup tool with an output schema and fully described parameters, the description covers purpose and context sufficiently. It does not need to explain return values thanks to the output schema, and the audit context is provided.

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 parameter descriptions for domain, format, and force_refresh already present. The tool description provides no additional parameter semantics beyond what the schema already states, 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?

The description clearly states the tool performs a DNS lookup for CAA records and explains what those records indicate (authorized Certificate Authorities). This specific verb+resource combination distinguishes it from sibling DNS tools like check_dmarc or check_dkim.

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

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

The description implies usage when CAA records need to be checked as part of a domain audit, but it provides no explicit guidance on when to choose this tool over alternatives or when not to use it. The phrase 'Part of the scan_domain audit' gives context but no exclusionary or preferential criteria.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds behavioral context beyond annotations: it discloses the network operations (resolving MX hosts, querying TLSA records at _25._tcp.<mx-host>, verifying DNSSEC-backed binding). This goes beyond just stating it's read-only.

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

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

The description is concise and front-loaded, with two sentences that deliver the core purpose, the exact DNS lookup pattern, usage guidance, and a sibling alternative. No filler or redundant statements.

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 are already covered. The description supplies the operational context (port 25, MX host resolution, TLSA record location), the purpose (protect against CA misissuance and MITM), and the relationship to the broader scan_domain audit. It is complete for an agent to invoke this tool correctly.

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

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

Schema description coverage is 100%, with each parameter (domain, format, force_refresh) well-described in the schema itself. The tool description does not add parameter-level detail, but doesn't need to since the schema carries the full semantic load.

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

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

The description uses a specific verb ('Check') and resource ('DANE/TLSA certificate pinning for SMTP at port 25'), and clearly differentiates from the sibling check_dane_https by specifying port 25 and SMTP. It also explains the mechanism (resolving MX hosts and looking up TLSA records), making the tool's purpose unmistakable.

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

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

Explicitly states when to use this tool: 'Use when asked if SMTP connections are protected by DANE/TLSA pinning.' It also names the alternative for HTTPS: 'For HTTPS DANE at port 443, use check_dane_https instead.' This gives clear decision guidance.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context by explaining the DNS lookup mechanism and that it's part of a broader audit, which goes beyond the annotations. It doesn't contradict annotations, but stops short of describing potential side effects like DNS query volume or cache behavior beyond the force_refresh parameter.

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

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

The description is three concise sentences, with the primary verb and resource front-loaded. Each sentence serves a purpose: stating the function, providing the technical method, and distinguishing from the sibling tool. No unnecessary words.

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

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

Given the tool's moderate complexity (3 params, 1 required), full schema descriptions, and presence of an output schema, the description is complete. It covers the core behavior, the specific DNS record checked, the port distinction, and its role in the audit. The output schema handles return value details, and annotations cover safety.

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

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

Schema covers all parameters with descriptions (100% coverage). The description adds the specific record name (_443._tcp.{domain}) which enriches the domain parameter's meaning, but the other parameters (format, force_refresh) are already well-documented in the schema. Baseline 3 is appropriate since the description only provides marginal added value.

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

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

The description clearly states the tool's function: 'Verify DANE certificate pinning for HTTPS connections.' It specifies the exact mechanism (TLSA record lookup at _443._tcp.{domain}) and explicitly distinguishes it from the sibling tool check_dane for SMTP, making the purpose unambiguous.

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

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

The description identifies when to use this tool (for HTTPS DANE verification) and explicitly differentiates it from check_dane (SMTP at port 25), providing an alternative. It also situates it within the scan_domain audit, giving clear contextual 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, and non-destructive behavior, so the bar is lower. The description adds value by naming the specific block lists queried and noting that return codes are decoded, but it does not discuss caching behavior, network prerequisites, or rate limits. This is a moderate addition beyond annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and contains no filler or redundant information. Every word earns its place.

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

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

For a read-only, idempotent lookup tool with good annotations and an output schema, the description is sufficient. It explains what the tool checks and what it returns (listing status with decoded codes). The presence of an output schema means the description does not need to enumerate return values.

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 fully describes all parameters. The description does not add any parameter-level semantic information (e.g., how format or force_refresh interacts with behavior), so it stays at the baseline for high schema coverage.

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

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

The description clearly states the verb 'Check' and the resource 'domain reputation against DNS-based Domain Block Lists', naming specific lists (Spamhaus DBL, URIBL, SURBL). This is specific and distinguishes it from sibling tools that check other reputation sources, such as check_rbl for IP-based block lists.

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

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

The description implies the tool is for domain-level block lists but does not explicitly state when to use it versus alternatives like check_rbl, check_mx_reputation, or check_realtime_threat_feed. It gives context but no exclusions or direct comparisons, so usage guidance is only implied.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description adds meaningful behavior: probing common selectors, validating algorithm types (RSA-1024/2048, Ed25519), and reporting key strength. It also implies DNS lookups and offers a cache-bypass concept via the force_refresh parameter. No contradiction with annotations.

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

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

Three sentences, front-loaded with the main action, with no redundant wording. Each sentence adds value: what it does, what it validates, and when to use 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?

The description fully explains the tool's purpose and behavior in the context of an email security audit. With an output schema present and clear annotations, the description does not need to detail return values or safety. It is complete for a read-only lookup tool.

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

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

Schema coverage is 100%, with each parameter already well-described. The description adds minimal extra meaning beyond the schema, though 'probes common selectors' reinforces the selector parameter's behavior. Baseline of 3 is appropriate given 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?

The description clearly states the tool looks up DKIM records, probes common selectors, validates signing algorithms, and reports key strength. It distinguishes itself from sibling tools like check_dmarc and check_spf by focusing on DKIM-specific cryptographic validation.

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

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

The description explicitly says 'Use to verify that outbound email signatures are cryptographically sound' and notes it is 'Part of the scan_domain audit,' giving clear context for when it should be used. It does not explicitly name alternatives or exclusions, but the tool's specific purpose is evident.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value by specifying what the tool reports (enforcement, alignment, reporting destinations) and framing it as part of a scan_domain audit. No contradiction with annotations.

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

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

Two sentences front-load the primary purpose and immediately provide distinguishing sibling comparisons. Every phrase contributes meaning without redundancy, fitting the 'part of scan_domain audit' context in a natural way.

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

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

Given the output schema exists and annotations already cover safety/idempotency, the description is complete for agent decision-making. It clarifies the domain of operation, expected outputs, and relationship to sibling tools, so no critical context 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 parameters are already fully documented. The description adds context for the domain parameter by implying what the lookup does, but it does not add meaning for format or force_refresh beyond the schema. Baseline 3 is appropriate.

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

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

The description starts with a specific verb+resource ('Look up and validate the DMARC record for a domain') and lists concrete outputs (enforcement level, alignment mode, reporting destinations). It also explicitly distinguishes itself from check_shadow_domains and assess_spoofability, which clarifies uniqueness among siblings.

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

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

The description states when to use the tool ('Use to determine a domain's DMARC enforcement level, whether it sends aggregate reports, or if it is protected against email impersonation') and names two alternatives with their differing purposes. It does not explicitly state a when-not-to-use scenario, but the alternative guidance is strong.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about reporting algorithms and flagging deprecated ones, but does not mention caching behavior or force_refresh implications, which would be extra value beyond annotations.

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

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

The description is three sentences with no filler: purpose, examples/behavior, and usage. It is front-loaded with the primary action and every sentence provides value.

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

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

The output schema exists, so return details are covered. The description addresses purpose, usage, and a key behavioral nuance (independence from chain validation), making it complete for a read-only audit tool.

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

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

Schema description coverage is 100%, so parameters are already well-documented in the schema. The description does not add additional parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool audits cryptographic strength of DNSKEY signing algorithms, provides concrete examples (RSA/SHA-1, ECDSA P-256, etc.), and explicitly distinguishes it from chain validation, making it distinct from siblings like 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?

Explicit usage guidance is provided: 'Use when asked what algorithm is used for DNSSEC signing keys, or if deprecated DNSKEY algorithms are in use.' It also clarifies independence from chain validation, helping the agent decide when to use this tool over alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context about the validation method (DNSKEY/DS records) and what it reports (enabled/validating), but does not discuss caching or output details, which are partially handled by 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?

The description is three sentences long and front-loaded with the core purpose. Each sentence adds meaningful detail (verification method, reporting, audit context) without redundancy or fluff.

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

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

Given the rich output schema and annotations, the description provides sufficient context. It explain the tool's role in scan_domain audit and the validation mechanism. It could mention specific sibling relationships, but that is not strictly required for completeness.

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

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

Schema description coverage is 100% because all three parameters (domain, format, force_refresh) have descriptions in the schema. The tool description does not add parameter-specific information, so the baseline score of 3 applies.

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

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

The description clearly states 'Check DNSSEC status for a domain' with a specific verb and resource, and elaborates on validating DNSKEY/DS records and reporting enabled/validating status. This distinguishes it from sibling tools like check_dnssec_chain and check_dnskey_strength by focusing on overall status.

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

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

The description provides clear context by noting 'Part of the scan_domain audit', indicating when this tool is used. However, it does not explicitly mention alternative tools or when not to use it, though the purpose is narrow enough to imply appropriate usage.

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

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

Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds substantive behavioral detail: tracing DS/DNSKEY records and algorithm usage at each zone level, and providing a step-by-step delegation path, which goes beyond what annotations alone convey.

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

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

The description is two sentences, front-loaded with the action, and contains no filler. It efficiently states both what the tool does and when to use it, earning every word's place.

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

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

The tool has a rich output schema, comprehensive annotations, and full schema coverage. The description covers purpose and usage sufficiently, and the output schema handles return values, so the description is complete for agent selection and invocation.

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

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

Schema description coverage is 100%, with each parameter (domain, format, force_refresh) already documented. The description does not add further parameter-level meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb 'walk' and clearly identifies the resource: 'full DNSSEC chain of trust from the DNS root down to the target domain'. It distinguishes from sibling tools like check_dnssec by emphasizing the full chain trace and DS/DNSKEY record tracing at each zone level.

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

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

Explicit usage guidance is provided: 'Use when asked to trace the chain of trust from the DNS root, or to see the full DNSSEC delegation path step by step.' This gives clear context for selection, though it doesn't mention exclusions or alternative tools by name.

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

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

Annotations already declare readOnly, openWorld, and idempotent behavior, lowering the bar. The description adds valuable behavioral detail beyond annotations: it performs multiple query rounds, compares IP sets and TTLs, and describes the detection heuristic. It does not discuss caching behavior or rate limits, but the core multi-round approach is clearly disclosed.

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

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

Two sentences, front-loaded with purpose and method, with zero filler. The first sentence states what it does and how; the second elaborates the detection mechanism. Every word earns its place.

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

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

With an output schema present, annotations covering safety and idempotence, and a description explaining the behavioral heuristic, the tool is fully contextualized. The agent understands what it checks, how it checks, and what kind of result to expect.

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 does not repeat parameter definitions but indirectly references the 'rounds' concept via 'multiple rounds of A/AAAA queries'. It adds no syntax or format detail beyond the schema, which is acceptable given full schema coverage.

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

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

The description uses a specific, action-oriented verb ('Detect') and clearly identifies the resource and scope: fast-flux DNS behavior via multi-round A/AAAA queries. It distinguishes itself from sibling DNS-check tools by focusing on IP rotation and TTL comparison.

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 context for when to use: to identify botnet or malicious infrastructure hiding behind rapidly rotating DNS answers. It does not explicitly name alternative tools or state when not to use it, but the purpose-driven context is strong enough for an agent to select it appropriately.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds valuable context by listing exactly which headers are inspected and what security weaknesses are flagged (unsafe-inline, wildcards, etc.), plus CDN/WAF interception detection. This goes beyond the annotations without contradicting them.

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

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

The description is a single, information-dense paragraph that front-loads the core purpose and then lists specifics. Every sentence earns its place, and the length is appropriate given the number of headers and checks involved. No fluff or redundant phrasing.

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

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

Given the tool's complexity, an output schema exists, and annotations cover safety, the description fully explains what the tool inspects and what it returns (per-header findings). It also situates the tool within the broader scan_domain audit. No critical missing context for an agent to select and invoke it.

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

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

Schema description coverage is 100%, so the parameters (domain, format, force_refresh) are already well-documented. The description does not add extra parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool audits a domain's browser-facing HTTP security headers over HTTPS, enumerating specific headers and concerns (CSP, X-Frame-Options, etc.). This specific verb+resource combination distinguishes it from sibling tools like check_ssl or check_dmarc, making the purpose unambiguous.

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

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

The description implies usage as part of the scan_domain audit and clarifies the scope (browser-facing HTTP security headers). However, it does not explicitly mention when to use this tool versus alternatives or provide exclusions, so it stops short of the 'explicit when/when-not/alternatives' standard.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds context about what the tool detects (character-substitution and visual-confusion domains, phishing risk) and that it finds 'active' domains, which is useful behavioral information beyond the annotations.

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

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

The description is three sentences with no wasted words. It front-loads the primary action ('Detect active typosquat...'), then clarifies scope, and finally differentiates from siblings. Every sentence earns its place.

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

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

With annotations, schema (100% param coverage), and a likely output schema (not shown but flagged as present), the description is quite complete. It covers detection scope, excludes related tools, and notes 'active' domains. It doesn't mention limitations like inability to detect unregistered lookalikes, but that's largely implied by 'active' and not a major 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 parameters are already fully documented in the schema. The description mentions 'active' and 'registered by attackers' which provides domain context, but doesn't add parameter-specific meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('Detect') and resource ('active typosquat and lookalike/homoglyph domains'), clearly stating the tool's purpose. It explicitly distinguishes itself from sibling tools check_shadow_domains and discover_brand_domains, making the scope precise.

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

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

The description tells when to use the tool (to detect typosquat/phishing domains) and explicitly names alternatives for related but different tasks ('Distinct from check_shadow_domains... and discover_brand_domains...'). This gives clear guidance on selecting this tool over its siblings.

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

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

Annotations already provide the safety profile (read-only, idempotent, non-destructive), and the description adds meaningful behavioral details: the DNS query, policy fetch, and reported fields (mode and MX coverage). This goes beyond simple annotation restatement, though it could mention potential failure modes if no policy exists.

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

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

Three concise sentences: purpose, mechanism, usage/alternative. No filler or redundancy; information is dense and well-organized.

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

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

With an output schema present and annotations covering safety, the description still contributes critical uniqueness: the exact DNS mechanism, report modes, and differentiation from a sibling tool. No significant gaps for this tool's complexity.

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

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

The schema descriptions already cover all parameters, so the baseline is 3. The description adds minor context by showing the DNS query pattern for the domain parameter, but doesn't dive deeper into format or force_refresh beyond what the schema provides.

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

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

The description clearly states the tool's function: checking whether a domain enforces SMTP TLS via MTA-STS. It specifies the mechanism (queries _mta-sts.<domain>, fetches policy file) and output (mode and MX coverage), and distinguishes it from check_dane by mentioning TLSA pinning.

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

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

Explicitly states when to use this tool ('verify whether inbound SMTP is protected against TLS downgrade or MITM') and names a specific alternative (check_dane) with the distinction. Also notes it is part of the scan_domain audit, providing appropriate context.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds useful functional context (identifies mail servers and provider) but does not go beyond the schema in disclosing behavioral details like caching behavior, which is already implied by the force_refresh parameter. This is adequate but not rich.

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

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

Three sentences, front-loaded with the core verb and resource. Each sentence earns its place: action, outcome/provider identification, and usage context. No redundancy or filler.

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

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

Given a rich output schema, complete parameter documentation, and strong annotations, the description fully covers what the tool does, when to use it, and its role in the scan_domain audit. There are no significant missing context hints for the agent.

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

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

Schema coverage is 100%, and each parameter already has a descriptive declaration, so the baseline is 3. The description adds no new parameter-specific meaning beyond what the schema provides. It does not need to compensate for any gaps.

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

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

The description uses a specific verb and resource: 'Look up MX records for a domain.' It clearly distinguishes itself from sibling tools like check_mx_reputation by focusing on mail server identification and provider detection. The mention of Google Workspace, Microsoft 365, and Proofpoint adds concrete purpose.

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

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

It explicitly states when to use the tool: 'Use when asked which email provider hosts inbound mail for a domain, or to see MX record configuration.' It also notes it is 'Part of the scan_domain audit,' providing context. However, it does not mention when not to use it or name specific alternatives, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by listing the specific blocklists checked (Spamhaus, Barracuda, SORBS, and other RBLs) and stating that reverse DNS is verified. It also implicitly conveys that the tool performs multiple network lookups and may rely on MX resolution, which is useful beyond the annotations.

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

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

The description is exceptionally concise at two sentences, with the primary action stated first. Every phrase earns its place: it covers the main function, the secondary verification (reverse DNS), and usage guidance with an alternative. There is zero wasted wording, making it easy for an agent to parse quickly.

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

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

Given that an output schema exists, the description doesn't need to explain return values. The tool is of moderate complexity, and the description adequately covers purpose, usage context, and distinguishes from a sibling tool. It doesn't mention potential rate limits or prerequisite conditions, but the annotations (openWorldHint, idempotentHint) fill in some gaps. This is slightly above the minimum but not exhaustive.

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

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

The input schema has 100% coverage, so the baseline is 3. The description adds some semantic value by clarifying that the 'domain' parameter is used to resolve MX hosts ('mail server (MX) IP addresses'), which isn't obvious from the schema's 'Domain to check.' However, it doesn't elaborate on the 'format' or 'force_refresh' parameters beyond what the schema provides, so it doesn't significantly exceed the baseline.

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

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

The description clearly states the tool's function with a specific verb+resource+scope: 'Check whether the mail server (MX) IP addresses are listed on spam blocklists... Also verifies reverse DNS for MX hosts.' It also explicitly distinguishes the tool from sibling check_rbl, saying 'distinct from check_rbl which checks a specific IP directly.' This makes the purpose unambiguous and differentiates it from similar tools.

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

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

The description provides explicit usage guidance: 'Use when you want to know if your mail server IP is blacklisted, or if your MX is on any blocklist.' It also names the alternative tool (check_rbl) and explains the difference, which tells the agent when NOT to use this tool. This is exactly what the dimension asks 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool 'shows delegation and redundancy' and identifies the provider, which is useful context. However, it doesn't go beyond this to explain caching behavior, rate limits, or other operational traits, so with annotation coverage, a 3 is appropriate.

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

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

The description is three sentences, each with a distinct purpose: the operation, the specific outputs (provider, delegation, redundancy), and the use case. It is front-loaded with the core action and contains no filler or repetitive content.

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

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

For a read-only lookup tool with only 3 parameters, an output schema, and comprehensive annotations, the description fully covers purpose, output semantics, and context (part of scan_domain audit). There are no significant gaps that would prevent an agent from selecting and invoking 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?

All 3 parameters have detailed schema descriptions, with 100% coverage. The description's mention of 'delegation and redundancy' hints at what output the format parameter might control, but it doesn't add significant meaning beyond the schema. Baseline 3 applies because 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?

The description uses a specific verb ('Look up') with a clear resource ('NS records for a domain') and distinguishes itself from sibling tools by detailing its unique focus on identifying the DNS provider and analyzing delegation/redundancy. It goes beyond a mere label and clearly states what the tool does.

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

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

Provides a clear use case: 'Use to find out which authoritative nameserver or DNS hosting service is used for a domain.' It also places the tool in context as part of the scan_domain audit. However, it doesn't explicitly mention when not to use this tool or name alternatives like check_authoritative_dns_infra, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds meaningful context beyond annotations by specifying what the tool inspects (NSEC3PARAM configuration) and the specific detection outputs (plain NSEC, weak NSEC3, opt-out flags), which helps the agent anticipate behavior.

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

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

The description is just two sentences, front-loaded with the primary verb and purpose. Every phrase earns its place: the analysis method ('NSEC3PARAM configuration') and the specific detection categories are included without fluff.

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

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

With an output schema present, the description need not explain return values. It sufficiently covers the tool's purpose and detection capabilities. It could mention cache behavior or refresh implications, but force_refresh is documented in the schema, so the description remains complete for a read-only check tool.

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

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

Schema description coverage is 100%, so parameters are already fully documented in the input schema. The description does not add parameter-level detail beyond the schema, but the baseline of 3 applies given the high schema coverage.

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

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

The description is specific and actionable: 'Assess zone walkability risk' names the verb and resource, while 'by analyzing NSEC3PARAM configuration' and 'Detects plain NSEC zones, weak NSEC3 parameters, and opt-out flags' clearly delineate the tool's scope. It distinguishes itself from sibling check_* tools (e.g., check_dnssec) by focusing on NSEC walkability.

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

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

The description implies a use case (assessing walkability risk) but does not explicitly state when to prefer this tool over alternatives like check_dnssec_chain or check_zone_hygiene. No exclusions or alternative suggestions are provided, so guidance is only implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the mail-server-specific purpose and audit context but does not disclose other behavioral traits like caching behavior or network dependencies beyond what the schema 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 short sentences with no filler. The primary action is front-loaded, and the second sentence adds useful context without redundancy.

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

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

Given the low complexity (3 parameters, 1 required, output schema present) and strong annotations, the description is sufficient. It explains the tool's role in the domain audit and the schema covers the invocation details, though it could mention explicit exclusions or alternative tools.

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

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

Schema description coverage is 100%, with all parameters having clear descriptions. The tool description does not add parameter-specific meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Verify') and resource ('forward-confirmed reverse DNS (PTR/FCrDNS) for mail servers'), clearly distinguishing it from sibling DNS-check tools like check_spf or check_dmarc. It also notes it is part of the scan_domain audit, giving additional context.

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

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

The phrase 'Part of the scan_domain audit' implies use within a broader domain audit, but there is no explicit guidance on when to use this tool versus alternatives or when to avoid it. The description gives context but leaves selection 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 description discloses that it resolves MX hosts to IPs first, a behavioral detail beyond the read-only annotation. It also enumerates the exact blocklists used, adding useful context. However, it does not mention caching, rate limits, or other behavioral traits, though annotations cover the safety profile.

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

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

The description is two sentences long, front-loaded with the main purpose and followed by specific details. Every word serves a purpose; there is no filler or repetition.

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

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

The description, combined with the schema and annotations, provides a comprehensive picture. It covers what the tool does, the specific RBLs, the resolution step, and the safety profile. The output schema handles return-value documentation, so the description is sufficient.

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

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

All three parameters have descriptions in the schema, so the baseline is 3. The description contributes minimal extra parameter semantics, only implying that 'domain' is the domain to resolve for MX IPs. It does not explain 'format' or 'force_refresh' beyond the schema.

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

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

The description clearly states the tool checks MX server IP reputation against seven specific DNS-based RBLs, naming them explicitly. It also notes the MX resolution step, making the scope unambiguous and distinguishing it from generic MX checks or other reputation tools.

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 conveys a clear use case—checking a domain's mail server reputation against RBLs—but does not explicitly state when to prefer this over sibling tools like check_mx_reputation or check_dbl. No exclusions or alternative guidance is provided, so usage is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the feed is curated via intel-gateway, operator deployment is required, and it degrades gracefully to info when unprovisioned. No contradiction detected.

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

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

Two sentences, front-loaded with the primary action, followed by critical differentiators. Every word adds value: the feed name, distinction from DNSBL, deployment restriction, and degradation behavior. No repetition or filler.

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

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

For a simple lookup tool with a rich output schema and clear annotations, the description covers purpose, differentiation, and operational constraints. It does not explain what 'info' means when unprovisioned, but that is a minor gap. Overall, it is complete enough for an agent to select and invoke correctly.

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

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

Schema descriptions cover 100% of parameters, each with meaningful explanations (domain, format, force_refresh). The description does not add parameter-specific semantics beyond the schema, but it provides context about the data source and operational behavior, which informs usage. Since schema coverage is full, a baseline of 3 is appropriate.

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

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

Description uses a specific verb ('Check') and resource ('domain against BlackVeil real-time threat intelligence'), and explicitly distinguishes itself from DNSBL checks. This makes the tool's function clear and separates it from sibling tools like check_rbl and check_dbl.

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

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

The description provides clear usage context: it is distinct from DNSBL checks, operator-deploy only, and degrades to info when unprovisioned. While it names an alternative category (DNSBL), it doesn't list specific alternative tool names, but the guidance is still actionable.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds that exactly 4 public resolvers are used. However, it does not explain what 'consistency' means in terms of output or behavior (e.g., whether it reports mismatches only, or includes details).

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

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

The description is a single, focused sentence that is front-loaded and contains no wasted words. It conveys the core function quickly and clearly.

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

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

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

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

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

Schema coverage is 100%; each parameter already has a description. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Check') and clearly identifies the resource ('DNS consistency across 4 public resolvers'). It distinguishes this tool from sibling DNS-checking tools like check_dnssec or check_ns by focusing on cross-resolver consistency.

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

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

The description implies usage when DNS consistency across public resolvers is needed, but it does not explicitly state when to choose this tool over alternatives or when not to use it. No exclusions or alternative-recommendations are provided.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds value by specifying the behavioral scope—what evidence sources are consulted (root hints, root glue, delegation, serial, DNSKEY). This goes beyond the annotations and gives the agent a concrete understanding of the tool's internal checks.

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

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

The description is a single, tightly packed sentence that front-loads the action and resource. It contains no filler or redundant phrases. Every word contributes to explaining the tool's purpose, making it highly efficient.

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

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

The tool is simple (one optional parameter), has an output schema, and strong annotations. The description explains the core purpose and evidence types. However, it omits any context about when such a check is relevant or what the output might look like—though the output schema covers return values. Given the available structured metadata, the description is nearly sufficient, but the lack of usage context slightly lowers completeness.

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

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

Schema description coverage is 100% for the single parameter 'format', which is described in the schema as 'Output verbosity. Auto-detected if omitted.' The tool description adds no additional parameter semantics, so the baseline of 3 applies. The schema fully documents the parameter, so no gap exists.

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

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

The description clearly states the specific verb 'Check' and the resource 'DNS root server set', and enumerates the exact evidence types checked (root hints, glue, delegation, serial, DNSKEY). This makes the tool's purpose unambiguous and distinguishes it from sibling tools like check_dnssec or check_ns, which target different DNS aspects.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention any specific context, prerequisites, or exclusions. Given the crowded sibling namespace of check_* tools, the absence of usage differentiation is a clear gap.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable context about the security-relevant behavior (email spoofing), without contradicting the annotations. No hidden side effects are disclosed beyond annotation coverage, but the added risk context warrants a strong score.

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

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

The description is two sentences long and front-loaded with the core action and purpose. Every sentence earns its place—the first defines the tool, the second gives usage context and distinguishes it from a sibling, with no wasted words.

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

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

For a read-only lookup tool with rich annotations, a complete input schema, and an output schema present, the description fully covers what the tool does, when to use it, and how it differs from a similar option. Nothing essential is missing for an agent to select and invoke it correctly.

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

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

The input schema provides 100% parameter documentation, including descriptions for domain, format, and force_refresh. The description does not add extra parameter-level meaning beyond what schema already provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific action ('Find alternate TLD variants of a domain') with a clear purpose ('weak or missing email authentication and could be used to spoof email'). It also explicitly distinguishes itself from the sibling tool check_lookalikes, so there is no ambiguity about its scope.

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

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

The description gives explicit when-to-use guidance: 'Use when asked about TLD variants with email auth gaps'. It also names the alternative: 'distinct from check_lookalikes which detects typosquat/homoglyph impersonation domains'.

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

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

Annotations already signal safety (readOnly, idempotent, non-destructive). The description adds context about outputs—listing authorized senders, flagging syntax errors, and revealing trust surface—without contradicting annotations. This goes beyond the schema explanations.

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

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

Three sentences, front-loaded with the core action. Each sentence adds distinct value: purpose, outputs, and usage context. No filler or redundancy.

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

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

For a read-only validation tool with a comprehensive schema and output schema, the description sufficiently explains what it does and when to use it. It covers the trust surface aspect, which gives the agent useful context. No major gaps.

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

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

Schema coverage is 100% with descriptions for domain, format, and force_refresh. The tool description does not add additional meaning about parameters; the schema already carries the burden. Baseline of 3 is appropriate.

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

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

The description clearly states the tool looks up and validates SPF records for a domain, enumerating specific outputs (IPs, third-party senders, syntax errors, trust surface). This specific verb+resource combination distinguishes it from sibling tools like check_dmarc 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?

Provides explicit guidance: 'Use when you need to know who is permitted to send email as a domain.' It also situates the tool as part of the scan_domain audit. However, it does not mention when not to use it or point to alternatives like resolve_spf_chain.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safe-read nature is clear. The description adds valuable context beyond annotations: it probes ~16 prefixes in parallel and specifically flags plaintext IMAP/POP3 without an encrypted variant. This gives deeper insight into the tool's execution and output without contradicting the annotations.

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

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

The description is exactly two sentences: the first delivers the core function and output, the second gives a crisp usage directive. No filler or redundant phrasing, and the key information is front-loaded.

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

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

The tool has a moderate complexity (3 params, one enum, output schema present), and the description covers the essential aspects: purpose, scope (~16 prefixes), return type (discovered services), a notable safety behavior (flagging insecure ads), and usage guidance. Return formatting is handled by the output schema, so the description need not elaborate. It is complete for an AI agent to select and invoke this tool correctly.

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

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

The input schema already describes all three parameters with 100% coverage (domain, format, force_refresh), so the baseline is 3. The description does not add additional parameter-specific semantics beyond what the schema provides, but it does frame the domain parameter's role by mentioning prefix probing. Overall, no significant additional meaning is contributed.

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

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

The description clearly states a specific verb ('Map') and resource ('a domain's DNS-visible service footprint' via SRV record prefixes). It explicitly lists what is returned (discovered services) and the key behavior of flagging insecure advertisements, which distinguishes it from the many sibling 'check_*' tools focused on other record types (e.g., check_mx, check_spf).

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

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

The description provides an explicit 'Use when ...' directive covering both mapping DNS-visible services and flagging insecure service advertisements. It does not, however, mention exclusions or recommend alternative tools for cases where the user might actually need MX, SPF, etc., so it stops short of the strongest level.

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

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

The description discloses key behavioral details beyond the annotations: certificate metadata is read from public CT logs and may differ from the currently served certificate, and TLS protocol versions/cipher suites are NOT returned. This is valuable contextual information not covered by readOnlyHint or idempotentHint.

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, front-loaded with the main purpose, followed by a caveat, exclusions, and usage. Each sentence adds necessary information with no redundancy or fluff.

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

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

The description covers all critical aspects: primary checks, the CT log caveat, what is not returned, and intended usage. With an output schema present and annotations declaring safety profile, this is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, with descriptions for all three parameters. The tool description does not add extra parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool checks HTTPS/TLS posture with specific checks (reachability, HSTS policy, HTTP-to-HTTPS redirect) and certificate metadata from CT logs. It distinguishes itself from sibling tools by focusing on the TLS/HTTPS aspect and notes it is part of the scan_domain audit.

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

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

The description provides an explicit use case: 'Use to verify HTTPS/HSTS configuration and certificate issuer/expiry.' It does not explicitly name alternative tools or exclusions, but the intended context is clear and practical.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is not burdened with safety disclosure. The description adds value by explaining the analytical process (SPF include chain analysis) and that it's part of the scan_domain audit. No contradiction with annotations.

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

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

The description is concise: two sentences plus a contextual note. It front-loads the purpose, then gives usage guidance, and ends with audit context. Every sentence contributes meaning without redundancy.

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

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

With an output schema present and annotations covering safety, the description sufficiently covers purpose, usage, and context. It also ties the tool to the broader scan_domain audit, making it clear where this fits in the workflow. No critical gaps.

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

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

Schema description coverage is 100%, so all parameters are documented in the schema itself. The description does not add additional semantic value beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool detects SubdoMailing risk by analyzing the SPF include chain for dangling or hijackable subdomains. It distinguishes itself from sibling tools like check_subdomain_takeover (which focuses on actual subdomain takeover) and check_spf (SPF record validation) by specifying the exact risk and mechanism.

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 provides when-to-use guidance: 'Use when you want to know if an SPF include chain can be hijacked through a dangling domain, or to detect subdomain mailing risk hidden in SPF includes.' This clearly signals the intended use case and differentiates from other checks.

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

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

Beyond the read-only and idempotent hints, the description discloses key behavioral traits: the default 15-name built-in subdomain list, the ability to supply an explicit subdomain list (capped at 1000), cache-bypassing via force_refresh, and the provider family detection scope. This adds substantial context not captured by 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?

The description is dense but efficient, front-loaded with the core purpose and followed by operational details. Every sentence adds value: provider coverage, usage trigger, pairing advice, and a caveat. No filler or redundancy.

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

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

Given the tool's complexity (16 provider families, multiple parameters, output schema), the description is remarkably complete. It covers what the tool does, when to use it, how to expand the candidate set, parameter options, and caching behavior. The annotations and schema handle safety and return format, allowing the description to focus on unique value.

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

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

Schema coverage is 100% (baseline 3), but the description enriches the subdomains parameter by explaining its source (CT enumeration or brand-audit discovery) and adds practical context for force_refresh (useful after DNS changes). It doesn't explain the format enum, but the schema already does.

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

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

The description clearly states the tool's purpose with a specific verb ('Sweep') and resource (subdomains), and explains the vulnerability type (dangling CNAMEs leading to subdomain takeover). It differentiates from sibling tools by specifying the detection of 16 provider families, making it distinct among the many check_* tools.

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

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

It explicitly states when to use the tool ('Use when asked if subdomains are pointing to deprovisioned cloud services') and provides a concrete pairing recommendation with discover_subdomains, including a caveat about the CT sample not being a full inventory. This gives clear usage context and alternatives.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds context about validating modern transport capability and RFC compliance, but no additional behavioral details like caching or rate limits. With annotations present, this is acceptable.

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

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

Two concise sentences that front-load the primary purpose and provide context. No wasted words or redundancy.

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

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

The tool is simple, read-only, and has full schema plus output schema. The description covers what it does and its role in scan_domain, making it complete for selection and invocation.

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

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

Input schema covers 100% of parameters with descriptions. The description adds no further parameter detail; the schema already explains domain, format, and force_refresh semantics, so the baseline holds.

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

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

The description clearly states the tool validates HTTPS/SVCB records per RFC 9460, with a specific verb and resource. It distinguishes itself from siblings like check_dane_https by focusing on transport capability advertisement.

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

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

The description notes it is 'part of the scan_domain audit,' implying usage during domain scans, but does not explicitly compare with alternatives or state when not to use it. This is implied rather than explicit.

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

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

Annotations already declare this as read-only, idempotent, and non-destructive, lowering the burden. The description adds valuable behavior details: it queries the specific TXT record, validates the rua destination (mailto:/https:), and flags missing/duplicate records or invalid URIs. This gives the agent a clear model of what the tool will do beyond the safe-operation hints.

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 focused sentences, with the main purpose front-loaded. Each sentence adds distinct information: the check, the validation behavior, and its complementary role. No filler or redundant phrasing.

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

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

Given the low complexity, rich annotations, full schema coverage, and presence of an output schema, the description is complete. It explains the DNS query, the validation criteria, typical failure flags, and the audit context. No missing prerequisites or side effects need disclosure for a read-only tool.

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

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

Input schema has 100% coverage with all three parameters (domain, format, force_refresh) already described. The tool description does not add extra semantics about these parameters beyond the schema, so the baseline 3 is appropriate. The mention of 'rua= mailto:/https:' is about validation logic, not parameter meaning.

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

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

The description starts with a specific action and target: 'Check whether a domain has SMTP TLS Reporting (TLS-RPT) configured.' It clearly identifies the resource (_smtp._tls.<domain>) and differentiates from sibling tools like check_mta_sts or check_dmarc by focusing on TLS-RPT. The inclusion of 'Part of the scan_domain audit' also provides context on its role.

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 states 'Complements MTA-STS by giving visibility into TLS delivery failures,' which gives clear contextual guidance on when to use it—alongside MTA-STS checks. However, it does not explicitly exclude alternatives or mention when not to use it, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as safe, so the safety profile is clear. The description adds the audit focus but does not disclose additional behaviors like caching or result interpretation beyond what annotations 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 a single sentence that is front-loaded with the action verb 'Audit', immediately states the resource, and adds meaningful scope. No unnecessary words.

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

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

For a simple read-only audit tool with a well-documented schema and full annotations, the description is sufficient to understand what the tool does. The output schema exists to handle return values, so that is not a gap. Slightly lacking in usage context but otherwise complete.

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

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

Schema coverage is 100% with rich parameter descriptions, so the baseline is 3. The tool description does not add any extra meaning to parameters; it relies entirely on the schema to explain domain, format, and force_refresh.

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 ('Audit') and resource ('TXT records'), and further clarifies the focus ('stale entries and SaaS exposure'). This clearly distinguishes it from sibling DNS checks like check_spf or check_dmarc.

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

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

The description implies when to use the tool (to audit TXT hygiene) but provides no explicit guidance on when-not-to-use or alternatives among the many sibling DNS tools. There is no mention of how this relates to check_zone_hygiene or other domain-level audits.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not expected to repeat that. It adds context about the types of findings (stale SOA, propagation issues) but does not disclose other behavioral traits like cache behavior, timing, or limitations. No contradiction with annotations.

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

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

The description is two sentences, with the key verb and resource front-loaded. Every sentence adds value: the first states what the tool does, the second states when to use it. There is no redundancy or filler.

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

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

Given the tool's read-only nature, the presence of an output schema, and fully described parameters, the description covers the essential context: purpose, use cases, and types of issues found. No significant gaps remain for an agent to select and invoke this tool correctly.

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

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

The input schema has 100% description coverage for all three parameters, so the schema already carries the semantic weight. The description adds no additional parameter-level meaning, though it hints at the audit topics that relate to parameters like force_refresh. 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 uses a specific verb ('Audit') and resource ('DNS zone hygiene'), and clearly enumerates what it identifies (sensitive/forgotten subdomains, stale SOA records, propagation issues). It distinguishes itself from sibling tools by focusing on overall zone hygiene rather than a single DNS record type.

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

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

The description provides clear usage context: 'Use to find any sensitive subdomains that should not be publicly visible, or to audit overall DNS zone cleanliness.' It does not mention exclusions or alternative tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful semantic context by defining 'fixed policy baseline' (compliance requirements) and excluding drift/regression analysis, which prevents misuse and clarifies the tool's scope. No contradiction with annotations.

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

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

Two sentences, front-loaded with the core action ('Compare...'), followed immediately by usage guidance with alternative tool names. No redundant or filler content.

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

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

The tool has a nested baseline object and no output schema, but the description plus rich schema provide sufficient context for selection and invocation: it explains the compliance purpose, explicitly excludes drift and multi-domain comparison, and the schema fully documents parameters. A minor gap is not describing the output format, but this is partially mitigated by the 'format' parameter.

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

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

Schema description coverage is 100%, so domain, baseline (including all nested require_* flags, max_* fields, grade/score floors), format, and force_refresh are fully documented. The description text does not add parameter-level detail, but the schema carries the burden, so baseline 3 is appropriate.

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

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

The description states a specific verb+resource+outcome: 'Compare a domain's current security configuration against a fixed policy baseline to determine compliance.' It also distinguishes from sibling tools by explicitly naming analyze_drift and compare_domains for other use cases.

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

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

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

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description need not repeat safety traits. It adds output details (relative scores, gaps, weaknesses) but does not disclose behavioral traits like caching, rate limits, or side effects. This matches the baseline for a description that adds some value without rich behavioral context.

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

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

The description is two sentences, front-loaded with purpose, then output details, then usage guidance. Every sentence earns its place with no redundancy or fluff.

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

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

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

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

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

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

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

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

The description clearly states a specific verb ('comparison') and resource ('domains'), and specifies output: 'relative scores, category gaps, and unique weaknesses.' This distinguishes it from sibling tools like compare_baseline, which likely compares against a baseline rather than other domains.

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

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

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

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

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds value by specifying the return fields (ASN, prefix, country, registry, organization) and the flagging of high-risk hosting ASNs, which goes beyond annotation data.

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 concise sentences deliver purpose, return fields, and a distinctive behavior with no redundancy. Every sentence earns its place.

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

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

For a read-only DNS lookup tool, the description covers purpose, returns, and a unique flagging behavior. Combined with rich schema and annotations, it is sufficiently complete, though it doesn't detail how IPs are resolved or the exact impact of the format parameter.

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

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

Input schema covers 100% of parameters with descriptive text, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already provides; it focuses on output rather than input.

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

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

The description clearly states the tool maps domain IPs to ASNs via Team Cymru DNS, with a specific verb-resource pair. It distinguishes from sibling DNS check tools by focusing on ASN attribution and listing return fields (ASN, prefix, country, registry, organization).

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

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

The description implies usage for ASN lookups and clarifies it works via Team Cymru DNS, which gives clear context. It does not explicitly exclude alternatives like rdap_lookup, but the purpose is specific enough to guide selection.

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

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

The description adds substantial behavior beyond the destructiveHint annotation: it emphasizes permanent deletion, reveals that the watchId is owner-scoped (a non-owned watch surfaces as notFound), and states that a confirmation is returned. These are specific, useful behavioral disclosures not captured by the annotations.

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

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

The description is two sentences, front-loads the action, and contains no fluff. Every clause adds meaningful information about the deletion behavior.

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

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

For a simple delete tool with only one parameter, the description covers the essential aspects: action, scope, error handling, and return value. The annotations handle safety profile, and an output schema exists, so nothing significant 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?

The schema already fully documents the single parameter (watchId) and even indicates it comes from register_brand_audit_watch. The description only mentions 'by watchId' without adding additional semantic detail, so the baseline of 3 (full schema coverage) is appropriate.

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

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

The description uses a specific verb ('removes') and identifies the exact resource ('recurring brand-audit watch') with a clear identifier ('watchId'). It distinguishes itself from sibling tools like list_brand_audit_watches and register_brand_audit_watch by focusing on deletion and clarifying owner-scoping.

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 context that this is the deletion counterpart to registration, but it does not explicitly state when to use it versus alternatives. Since no other delete tool exists among siblings, this is sufficient, though it could have explicitly said 'use when you want to stop a recurring audit watch.'

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

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

Annotations already declare the operation read-only (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the description doesn't need to restate that. It adds useful behavioral context beyond annotations: the tool aggregates multiple signal types and is highly sensitive to domain normalization (the verbatim-domain warning). No contradiction with annotations.

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

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

Three sentences, each purposeful: purpose, usage trigger, and a critical behavioral instruction. No filler, front-loaded, and the caps emphasis on the verbatim-domain rule is effective. Every sentence earns its place.

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

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

The tool is complex (12 params, output schema), but the description covers the core selection criteria and the most critical execution detail (verbatim domain). The schema and output schema handle the remaining parameter and return-value detail. It could mention the tiered-mode complexity, but that is already documented in the discovery_mode parameter. Adequate for an overview.

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

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

The input schema provides 100% coverage with detailed descriptions for all 12 parameters, so the description adds marginal semantic value. The only reinforcement is the verbatim-domain instruction, which already appears in the domain parameter's schema description. This is a repeat of structured data, not new insight.

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+resource ('Discover all domains that belong to a brand's portfolio') and clearly distinguishes the tool's scope from siblings like discover_subdomains by focusing on brand portfolio aggregation. The inclusion of signal types (certificate, DNS, redirect, mail-policy) further pins down what the tool does.

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

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

It explicitly states when to use the tool: 'Use when asked what domains are part of a brand portfolio, or to find all domains related to a brand.' It also provides a critical usage instruction (pass the exact seed domain verbatim). However, it does not mention exclusions or alternatives for cases where the tool should not be used, such as subdomain discovery.

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