dns

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds value by explaining the drift analysis mechanism, return components (classification, delta, lists), and the dual nature of the baseline parameter (previous scan JSON or 'cached'). No contradictions with annotations.

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

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

Three concise sentences: first states core operation, second lists output components, third provides usage guidance and sibling differentiation. No redundant words, front-loaded with 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?

Despite lacking an output schema, the description covers key return values (classification, delta, improvement/regression lists), explains parameter semantics fully, and context signals show all parameters are described. The description is complete enough for an AI agent to understand the tool's purpose and usage.

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%, but the description adds significant context beyond the schema: it clarifies that baseline must be a ScanScore JSON string or 'cached' (not a policy object), explains the format parameter's auto-detection, and notes force_refresh usage. This aids correct parameter usage.

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 'Measure whether... improved or regressed' and resource 'domain's DNS security posture' and clearly distinguishes from the sibling tool compare_baseline which checks compliance against a fixed policy.

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 to answer "did our security score improve or regress since last time?"') and directly contrasts with compare_baseline, ensuring correct 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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: the need for a service binding, the fallback response { unprovisioned: true } when absent, and the representative: true flag indicating sample data until live Graph reads land. This enhances transparency without contradiction.

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

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

The description is two sentences, no wasted words. The first sentence delivers the core purpose, and the second provides critical behavioral notes. It is front-loaded and 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?

While the description covers important edge cases (service binding requirement, representative data), it does not describe the typical response format (e.g., list of unprotected users/apps, policy details). Without an output schema, more information about the normal response would be beneficial for a complete understanding.

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% for the single parameter ms_tenant_id, with a clear description in the schema. The tool description does not add any additional parameter semantics beyond what is already provided in the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Assess Conditional Access coverage gaps for a Microsoft Entra tenant — identifies users and apps not protected by any enforced policy.' The verb 'assess' and specific resource 'coverage gaps' are precise, and the outcome is defined. It distinguishes itself from siblings like get_ca_policies (which lists policies) and map_compliance by focusing on gap identification.

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 includes a requirement ('Requires m365Proxy service binding') and a behavior when missing, but does not provide explicit guidance on when to use this tool versus alternatives like get_ca_policies or map_compliance. The context is implied but not articulated as a decision rule.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the composite nature and output details but does not reveal new behavioral traits beyond the hints. It provides moderate context without contradictions.

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

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

Two succinct sentences: the first explains the computation and output, the second provides usage guidance. Every sentence adds value, with no redundancy or unnecessary text.

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

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

Given no output schema, the description sufficiently explains the return values (risk level, sub-scores, summary) and the scoring scale. It covers the tool's complexity and provides enough detail for an AI agent to understand what 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 baseline is 3. The description does not add parameter-specific details beyond what is in the input schema (e.g., format auto-detection, force_refresh for DNS changes are already described in 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 identifies the tool's purpose: computing a composite email spoofability risk score from SPF, DMARC, and DKIM. It distinguishes itself from sibling tools like check_spf, check_dmarc, and check_dkim by focusing on a combined assessment, and explains the output components.

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

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

The description explicitly states when to use the tool: 'when asked how easy it is to spoof email from a domain, or for a composite email spoofing risk score.' It provides clear context but does not explicitly list exclusions or 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?

The description adds value beyond annotations by revealing parallel execution (up to 10 domains) and the specific return data (score, grade, finding counts). It does not contradict annotations. Minor omission: no explicit mention of caching behavior, but force_refresh parameter covers it.

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

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

Three sentences, each serving a distinct purpose: action/constraint, output, usage guidance. Front-loaded with core function. 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 no output schema and 100% parameter documentation, the description covers all critical aspects: purpose, constraints (max 10, parallel), output format, and usage context. No 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%, so description does not need to add parameter details. The description mentions domain count limit (10) which aligns with the schema's maxItems constraint, but does not elaborate on format or force_refresh beyond what the schema already provides. 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's action: bulk-scan up to 10 domains in parallel, and specifies the output (score, NIST-aligned grade, finding counts). It also distinguishes itself from compare_domains, a 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?

The description explicitly says 'Use when you want to audit multiple domains at once or do a bulk scan' and contrasts with compare_domains, providing clear when-to-use and alternative 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?

Description discloses async nature, immediate return with { auditId, queuedAt, targetCount, etaSeconds }, quota consumption per target. Annotations (readOnlyHint=false, etc.) are consistent and the description adds behavioral context that annotations alone cannot convey, making it highly transparent.

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 key action and constraints. Every clause adds value (quota, polling workflow). No fluff. Excellently structured for quick parsing.

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 (10 params, async, quota), the description covers the essential workflow (enqueue, poll, fetch), quota impact, and output shape. Combined with rich schema and output schema, the description is fully complete for an AI agent to use correctly.

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

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

Schema has 100% coverage with descriptions for all 10 parameters. Description adds value by noting that 'csc_complement' view requires enterprise tier, which is not in the schema. Also explains the purpose of brand_aliases and candidate_domains in context. Contributes beyond schema without being repetitive.

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 identifies the resource as 'async brand audit across up to 50 target domains'. It clearly distinguishes from sibling tools like brand_audit_single (single domain) and brand_audit_status/brand_audit_get_report (polling and results).

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 to poll with brand_audit_status and fetch results with brand_audit_get_report. Mentions quota consumption. Does not explicitly state when not to use or compare with brand_audit_single, but context implies batch use. Clear enough for an AI agent.

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

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

Adds significant behavioral context beyond annotations: returns 'notReady' for in-flight audits, mentions PDF sidecar with authenticated download link, and pdfPending flag for still-rendering PDFs. No contradictions with annotations.

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

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

Concise and well-structured: first sentence states core purpose, then outlines conditional behavior and additional metadata. No filler sentences; every sentence adds value.

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

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

Given the output schema exists (describing possible fields), the description covers polling, PDF sidecar, authentication, and result differentiation. It is complete for a report retrieval 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% (descriptions for both parameters). The description adds meaning: explains that omitting target returns aggregate, setting target returns per-result, and ties auditId to brand_audit_batch_start. This is above the baseline 3.

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

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

The description clearly states it fetches the result JSON for a completed brand audit, distinguishes between aggregate and per-target results, and is specific about the resource and verb. It stands out from sibling tools like brand_audit_status which only check 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?

Provides clear context on when to use (for completed audits) and optional behavior with target. However, it does not explicitly exclude usage for non-audit-related tasks or mention alternatives like brand_audit_status for status-only queries.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds substantial behavioral detail: what the audit discovers (brand-related domains, registrar/registrant lookups), classification logic, and quota gating. No contradictions with annotations.

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

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

Two sentences deliver the core purpose, process, and quota constraints without extraneous words. The first sentence front-loads the primary action, making efficient use of space.

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

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

The description adequately covers the tool's main functionality, behavioral nuances, and quota gating given the presence of an output schema (which handles return values) and the high schema coverage. No critical missing context.

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

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

Schema coverage is 100%, but the description adds context for key parameters like depth, brand_aliases, and candidate_domains ('optional standard/deep discovery depth', 'optional public brand aliases', 'caller-supplied candidate domains'), going beyond the schema's descriptions.

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

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

The description uses a specific verb ('Run a full brand audit') and identifies the resource ('single target'), clearly distinguishing this from sibling tools that focus on individual checks (e.g., check_dmarc, check_spf) or batch processes (brand_audit_batch_start).

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

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

The description implicitly differentiates from batch tools by specifying 'single target' and mentions tier-based quotas. However, it does not explicitly state when to choose this tool over siblings like brand_audit_batch_start or single-check tools, leaving some ambiguity.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the behavioral risk is low. The description adds value by explaining the polling nature, progress format, and the notFound response for unauthorized auditIds, which goes beyond the annotations.

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

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

Two sentences, no fluff. The first sentence front-loads the action ('Poll the status'), and the second adds essential context about owner-scoping. 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 a single parameter, 100% schema coverage, and the presence of an output schema, the description is complete. It covers purpose, behavior, and scoping without needing to elaborate on return values. No 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?

The input schema has one parameter with full description coverage, referencing brand_audit_batch_start. The description adds marginal value by noting owner-scoping but does not elaborate on the parameter format or constraints beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description explicitly states it polls the status of an enqueued brand audit, specifying returned fields (audit-level status, progress, per-target statuses) and owner-scoping. It clearly differentiates from sibling tools like brand_audit_batch_start and brand_audit_get_report.

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

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

The description clearly indicates when to use the tool (after enqueuing a brand audit) and notes the owner-scoping behavior. It does not explicitly list alternative tools or when not to use, but the context is sufficient for an AI agent to infer usage.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context: it uses Private-Use SVCB param code points pending IANA assignment, and mentions caching behavior 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?

The description is about five sentences, front-loaded with the main purpose, and efficiently covers the tool's scope. It is concise without being overly verbose, though it could be slightly more structured for clarity.

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

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

Given the tool's complexity (6 parameters, 1 required, output schema exists), the description covers the main security checks and notes read-only behavior. It does not repeat output schema details. It is fairly complete for a security assessment tool, though mentioning the output format briefly could help.

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 good parameter descriptions. The description adds functional context beyond the schema, such as explaining that verify_cap relates to capability-document integrity checking and that force_refresh bypasses cache. This enhances understanding of how parameters affect behavior.

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

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

The description clearly states the tool assesses the security posture of IETF BANDAID agent-discovery records, listing specific checks (SVCB records, DNSSEC anchoring, DANE/TLSA binding trust, capability-document integrity). The verb 'assess' and resource 'agent-discovery records' are specific and distinguish it from sibling tools like check_dnssec or check_dane.

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 checking BANDAID agent-discovery security but does not explicitly state when to use this tool versus alternatives like check_dnssec or check_dane. There is no guidance on context or exclusions, only a statement of what it does.

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 non-destructive. The description adds context about using BV_INFRA_PROBE for evidence types (raw DNS, routing, RPKI, vantage-point), but no further behavioral traits like caching, performance, or error handling. With annotations, this is adequate.

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

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

Two sentences: first states the core purpose, second adds implementation detail. No unnecessary words, well-structured and efficient.

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

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

Given the presence of an output schema and complete parameter descriptions, the description covers the tool's basic function. However, it lacks usage context relative to siblings and does not elaborate on output structure or edge cases. Adequate but not exceptional.

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

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

Schema coverage is 100% (all 3 parameters have descriptions). The description does not add meaning beyond the schema; it only restates the tool's general purpose. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Check' and the resource 'authoritative DNS infrastructure posture for a hostname'. It distinguishes from siblings like check_ns or check_dnssec by being a broader posture assessment. The mention of BV_INFRA_PROBE adds specificity.

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

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

No explicit guidance on when to use this tool vs. siblings (e.g., check_ns, check_dnssec). The description implies it is for a comprehensive check, but lacks when-not or alternative recommendations.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and non-destructive nature. The description adds context by explaining the specific checks (logo URL, VMC certificate, DMARC prerequisite) and the type of findings returned, which is beyond the annotation metadata.

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 well-structured sentences, each adding essential information without redundancy. It starts with the main action, then details the validation, mentions the output, and ends with the use case. No fluff.

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

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

Given the rich annotations and output schema, the description provides sufficient context: what is checked, the DNS record location, validation criteria, prerequisites, and intended use. It fulfills all necessary information for an agent to decide when and how to invoke this 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 clear parameter descriptions. The tool description adds value by linking the domain parameter to the specific subdomain (default._bimi.<domain>) and explaining the relevance of the format and force_refresh parameters in the context of BIMI checks.

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 the BIMI brand-logo record, specifies the exact DNS location (default._bimi.<domain>), details the validated elements (l=, a=, p=), and explains its purpose of verifying conditions for mail clients. It distinguishes from sibling tools by focusing on BIMI readiness.

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 to 'Use to assess brand-indicator readiness in inboxes' and notes it is part of the scan_domain audit. However, it does not explicitly compare to sibling tools or state when not to use it, leaving some ambiguity.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that it shows authorized CAs, which is consistent. No new behavioral traits beyond the annotations are disclosed. The description does not contradict 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-loading the core function and value. Every sentence serves a purpose. No redundant or vague 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?

With an output schema present, the description does not need to detail return values. It covers the core purpose and context (part of an audit). Slightly more context about when to use it or its relationship to the broader audit could move it to 5, but it's satisfactory.

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 description does not need to elaborate on parameters. The description provides contextual meaning for the domain parameter via 'CAA records' but does not add details beyond the schema. Baseline 3 applies.

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

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

The description clearly states the tool looks up CAA records for a domain and specifies what CAA records indicate (authorized CAs). It distinguishes itself from sibling 'check_*' tools by targeting a specific DNS record type. The context 'Part of the scan_domain audit' further clarifies 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 implies usage when CAA records are needed but does not explicitly state when not to use this tool or suggest alternatives. Given the sibling list includes many DNS checks, the agent can infer context, but explicit guidance is missing.

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

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

Description details internal behavior: resolves MX hosts, looks up TLSA records, verifies DNS binding. Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint, so description adds context 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?

Concise, front-loaded with purpose, then usage guidance, then alternative. Every sentence adds value with no 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 annotations and output schema presence, description covers purpose, usage, and internal steps. Could mention output format but output schema handles that.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters. Description does not add additional parameter semantics beyond what the schema provides.

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

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

Description clearly states 'Check DANE/TLSA certificate pinning for SMTP at port 25', specifying verb, resource, protocol, and port. It distinguishes from sibling tool check_dane_https for HTTPS.

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

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

Explicitly says 'Use when asked if SMTP connections are protected by DANE/TLSA pinning' and provides alternative: 'For HTTPS DANE at port 443, use check_dane_https 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?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the specific DNS lookup behavior (TLSA records at _443._tcp.{domain}), which is useful beyond annotations. No contradictions.

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

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

The description is three sentences, each adding value: purpose, technical detail, and distinction from sibling. No wasted words, well-structured, and front-loaded with the main action.

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

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

Given the presence of an output schema, the description does not need to explain return values. It covers the core behavior and context. Could implicitly hint at the output (e.g., pinning status), but overall it is complete enough for an agent to understand.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond what the schema already provides for the parameters (domain, format, force_refresh). It implies domain is used for the lookup but adds no new semantics.

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

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

The description clearly states the tool verifies DANE certificate pinning for HTTPS connections by looking up TLSA records at a specific DNS location. It uses a specific verb ('Verify') and resource, and distinguishes itself from the sibling tool check_dane.

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 contrasts with check_dane (SMTP port 25), guiding when to use this tool. It also mentions it's part of the scan_domain audit, providing context. It does not list exclusions or prerequisites, but the distinction is clear.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds that it returns decoded return codes, which is useful but not extensive. No mention of caching behavior or rate limits beyond the force_refresh parameter hint.

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?

Extremely concise (two sentences, ~20 words), front-loaded with the core purpose, and no superfluous information. Every sentence contributes value.

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

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

Given the existence of an output schema and the simplicity of the tool (checking reputation against specific lists), the description adequately covers the main purpose, lists, and return type. Minor gap: doesn't elaborate on how checks work, but output schema likely handles return details.

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

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

Schema coverage is 100% with clear descriptions for all 3 parameters. The tool description does not add meaningful semantic details beyond what the schema already provides, staying at the baseline for high-coverage schemas.

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

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

The description clearly specifies the tool checks domain reputation against specific DNS-based block lists (Spamhaus DBL, URIBL, SURBL) and returns decoded return codes, distinguishing it from sibling tools like check_rbl or check_realtime_threat_feed.

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

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

No explicit guidance on when to use this tool over the many sibling check tools (e.g., check_rbl, check_realtime_threat_feed). Usage is implied by the named lists but lacks alternative comparisons.

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 readOnly, idempotent, and non-destructive hints. The description adds behavioral details: probing common selectors, validating algorithm (RSA-1024/2048, Ed25519), and reporting key strength. 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, each adding value. First sentence states purpose, second adds algorithm detail, third provides usage and context (part of scan_domain audit). No fluff.

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

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

Given the presence of an output schema (explaining return values), the description covers the tool's purpose, key behavior (selector probing, algorithm validation), and usage context. It is sufficient for an agent to understand when and how to invoke the tool.

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

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

Schema coverage is 100%, so the schema already describes all parameters. The description adds context about probing common selectors (related to the selector parameter) and output specifics, but does not significantly enhance parameter understanding beyond the schema.

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

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

The description clearly states the action ('Look up DKIM records') and the resource ('for a domain'), with specifics on probing common selectors and validating signing algorithms. It distinguishes from siblings by focusing on DKIM specifically, which is unique among many DNS 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?

The description explicitly says 'Use to verify that outbound email signatures are cryptographically sound,' providing clear use case. While it doesn't explicitly name alternatives like check_dmarc or check_spf, the context of sibling tools makes the distinction implicit.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint as true, and destructiveHint false. The description adds transparency about caching (force_refresh parameter bypasses cache) and validation behavior. It does not contradict 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, front-loads the main purpose, then details outputs, and ends with usage differentiation. It is efficient without being overly terse, but could slightly tighten wording.

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

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

Given the presence of an output schema and annotations, the description covers key aspects: core function, output fields, usage context, and differentiation. It is complete for an AI agent to understand when and how to use the 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 adequate descriptions for all 3 parameters. The description does not add additional parameter semantics beyond what's in the schema; it focuses on output interpretation.

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 verb 'Look up and validate' and the resource 'DMARC record for a domain'. It lists specific output fields (enforcement level, alignment mode, reporting destinations) and explicitly distinguishes from sibling tools check_shadow_domains and assess_spoofability.

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

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

The description clearly states when to use: to determine DMARC enforcement level, report status, or protection against email impersonation. It explicitly contrasts with two sibling tools, providing differentiation.

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

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

The description adds behavioral details beyond annotations, such as reporting algorithms and flagging deprecated ones, and clarifies it is independent of chain validation. Annotations already declare it as read-only and idempotent.

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 with two clear sentences: first defining purpose and behavior, second stating when to use. No redundant or 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 complexity (3 parameters, output schema exists, many sibling tools), the description is complete. It covers purpose, usage, behavioral nuances, and context (part of scan_domain audit).

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

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

Schema coverage is 100%, so baseline is 3. The description does not add parameter-specific details beyond what the schema provides, but the schema already sufficiently describes each parameter.

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

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

The description clearly states the tool audits cryptographic strength of DNSKEY algorithms, specifies what it reports (algorithm names, deprecated flags), and distinguishes it from sibling tools like check_dnssec by noting independence from DNSSEC chain validation.

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

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

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 does not explicitly mention when not to use, but the context implies alternatives exist among sibling tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about verifying DNSSEC status and reporting if enabled, which aligns with these annotations but doesn't disclose additional behavioral traits like caching behavior or error handling.

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

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

The description is concise with three sentences: first states the purpose, second explains what it verifies, third gives context. It is front-loaded and contains no extraneous information.

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

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

Given the tool's simplicity (3 parameters, one required), annotations covering safety and idempotency, and the presence of an output schema (not shown but exists), the description is sufficiently complete. It also notes the tool's role in scan_domain audit.

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

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

Schema coverage is 100%, so the input schema already describes all parameters with good descriptions. The tool description does not add further semantic meaning beyond what the schema provides, resulting in a baseline score of 3.

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

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

The description clearly states the tool checks DNSSEC status for a domain and explains what it verifies (tamper-proof, cache poisoning protection). It distinguishes from sibling check_* tools by focusing specifically on DNSSEC, using a specific verb and resource.

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?

While the description mentions it's part of scan_domain audit, it provides no explicit guidance on when to use this tool versus alternatives like check_dnssec_chain or check_dnskey_strength. No exclusionary language or recommended contexts are given.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral context: it walks the full chain, traces records, and is step-by-step. No contradictions, and it complements the annotations well.

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?

Exactly two sentences: first defines the tool's action, second specifies usage context. No redundant information, and the most critical information is front-loaded.

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

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

The description covers the core purpose and usage context. The presence of an output schema (indicated true) means return values are handled. The tool is complex but the description is adequate, though it could mention caching behavior or prerequisites.

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%: all three parameters (domain, format, force_refresh) have descriptions in the schema. The tool description does not add extra meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description uses specific verbs and nouns: 'Walk the full DNSSEC chain of trust from the DNS root down to the target domain, tracing DS/DNSKEY records and algorithm usage at each zone level.' This clearly distinguishes the tool from siblings like check_dnssec (which likely just checks if DNSSEC is enabled) and check_dnskey_strength.

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

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

The description explicitly states when to use: 'Use when asked to trace the chain of trust from the DNS root, or to see the full DNSSEC delegation path step by step.' While it does not mention when not to use, the context of siblings provides implicit 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 mark the tool as read-only, idempotent, and not destructive. The description adds behavioral details such as performing multiple query rounds, comparing IP sets and TTLs, and mentions caching behavior via the 'force_refresh' parameter. This provides additional context beyond the annotations.

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

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

The description is three sentences long and front-loads the purpose. It is concise but could be slightly tighter; some repetition of the method occurs. Overall, it efficiently conveys the key information 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?

Given that an output schema exists, the description does not need to detail return values. It covers the detection technique, parameters are fully described in schema, and annotations provide safety context. It might lack guidance on performance or rate limits, but for a read-only tool it is sufficiently complete.

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

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

All parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description adds no new information about individual parameters; it only contextualizes the overall process. The relationship between 'rounds' and the multiple queries is implicit but not elaborated.

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

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

The description explicitly states the tool's purpose: detect fast-flux DNS behavior. It describes the method (multiple rounds of A/AAAA queries, checking IP rotation) and distinguishes from sibling check_* tools by targeting a specific DNS anomaly.

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

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

The description explains what the tool does but does not provide explicit guidance on when to use it versus alternatives. There is no mention of prerequisites, scenarios, or sister tools like check_dnssec or check_mx that might be more appropriate for 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?

Annotations already declare tool as read-only, idempotent, and non-destructive. Description adds detail: inspects specific headers, returns per-header findings, detects CDN/WAF interception. No contradictions, and it enriches behavioral understanding 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?

Description is three sentences, front-loaded with purpose, and every sentence adds value. No redundant or rambling content. Efficient and well-structured.

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

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

Given the presence of an output schema (not shown but indicated), the description appropriately omits return value details. It covers all relevant aspects: purpose, scope, specific checks, and integration with broader audit. Complete for an 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 has 100% coverage for parameter descriptions, so baseline is 3. Description does not add new information about parameters beyond what schema provides, e.g., 'force_refresh' explanation matches schema. No extra semantics added.

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

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

Description uses specific verb 'Audit' and clearly states it inspects browser-facing HTTP security headers over HTTPS. It lists specific headers and attack types, making the tool's purpose unambiguous. Distinguishes from siblings by focusing on a specific audit aspect.

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?

Description notes it is 'Part of the scan_domain audit', giving context for when to use. However, it does not explicitly compare with sibling tools or state when not to use, though the specialization is clear.

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

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

Annotations already convey safe, idempotent read-only behavior. Description adds specifics about detecting character-substitution and visual-confusion domains, and that domains are registered by attackers, offering useful context 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?

Two sentences only, front-loaded with purpose and key differentiators. No fluff, every word adds value.

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

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

With robust annotations, output schema present, and clear differentiation from siblings, the description is fully complete for agent decision-making.

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 good parameter descriptions. The tool description adds no additional parameter meaning, so 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?

Description clearly states the tool detects active typosquat and lookalike/homoglyph domains for brand impersonation, with explicit differentiation from sibling tools check_shadow_domains and discover_brand_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?

Explicitly specifies when to use (detect phishing domains) and contrasts with alternatives, providing agents with clear decision 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 indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds value by explaining the internal mechanism (queries DNS, fetches policy file) and mentions caching behavior via the 'force_refresh' parameter. This supplements the annotation context.

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

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

The description is concise (four sentences) with no redundant information. Each sentence adds value: defining purpose, explaining method, stating usage and alternatives, and contextualizing within the broader audit toolset. It is well-structured and front-loaded.

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

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

Given the presence of an output schema (not shown but indicated), the description does not need to detail return values. It covers the tool's purpose, methodology, report outputs (mode and MX coverage), and relationship to other tools and workflows (part of scan_domain audit). This is complete for effective tool selection.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description provides minimal additional insight into parameter specifics, such as mentioning DNS query for domain and policy fetch, but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the tool checks MTA-STS enforcement for a domain, using a specific verb ('Check whether') and resource ('domain enforces SMTP TLS for inbound mail via MTA-STS'). It distinguishes itself from the sibling tool 'check_dane' by noting the different mechanism (MTA-STS vs 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?

The description explicitly advises when to use ('Use to verify whether inbound SMTP is protected against TLS downgrade or MITM') and differentiates from one key sibling ('distinct from check_dane'). While it doesn't exhaustively list alternatives, it provides clear context for 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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying that it identifies the email hosting provider (e.g., Google Workspace, Microsoft 365), which goes 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 extremely concise: two sentences that cover purpose, usage, and context without any wasted words. Front-loaded with the primary action.

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

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

Given that an output schema exists (not shown but indicated), the description need not explain return values. It covers purpose, usage, and context thoroughly enough for an AI agent to decide when and how to invoke it.

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

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

Schema coverage is 100%, so the JSON schema already describes all three parameters. The description adds no additional parameter semantics beyond what the schema provides, which meets the baseline expectation.

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

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

The description clearly states it looks up MX records to identify mail servers and the email hosting provider. It distinguishes itself from sibling tools by specifying it's part of the scan_domain audit and by its specific use case.

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: 'Use when asked which email provider hosts inbound mail for a domain, or to see MX record configuration.' Also mentions it's part of a larger audit, providing 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=true, destructiveHint=false, idempotentHint=true. Description adds no additional behavioral context beyond verifying reverse DNS, which is implicit. No contradiction.

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

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

Two sentences, first sentence states action and scope, second sentence gives usage guidance and sibling differentiation. No wasted words.

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

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

Covers what it does, when to use, specific blocklists, reverse DNS check, and distinguishes from sibling. Output schema exists so return values are covered.

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 good parameter descriptions. The tool description adds no new semantics beyond what is already in 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?

Clearly states it checks MX IPs on spam blocklists and verifies reverse DNS. Distinguishes from sibling tool check_rbl by specifying it checks MX for a domain rather than a specific IP.

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 use case: 'Use when you want to know if your mail server IP is blacklisted', with alternative tool mention 'distinct from check_rbl'.

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

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

Annotations provide readOnlyHint, idempotentHint, and destructiveHint. The description adds context about identifying the provider and showing delegation/redundancy, which goes beyond the annotations and clarifies the tool's output 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, front-loading the core action and then adding context. Every sentence adds value without redundancy or 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 output schema exists (not shown but indicated) and the annotations cover safety, the description sufficiently explains the tool's purpose and behavior. It mentions the key outputs (provider, delegation, redundancy) and the audit context.

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

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

Schema coverage is 100%, so the description does not need to elaborate on parameters. It adds minimal extra meaning beyond the schema, such as mentioning 'delegation and redundancy', but does not describe parameter details. 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 verb 'Look up' and the resource 'NS (nameserver) records'. It specifies the purpose: to identify the DNS nameserver provider, delegation, and redundancy. This distinguishes it from sibling tools like check_mx 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 advises 'Use to find out which authoritative nameserver or DNS hosting service is used for a domain.' It lacks explicit when-not-to-use indications or alternatives, but the context of sibling tools makes the usage clear enough.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds context about what configurations are analyzed, but does not disclose additional behaviors like caching behavior, network dependencies, or how output is structured. Given the annotation coverage, this is adequate.

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

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

The description is a single sentence that is front-loaded with the core purpose and then lists specific detections. It is concise with no redundant words, earning its place efficiently.

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

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

For a focused check tool with 3 parameters, an output schema, and annotations covering safety, the description is largely complete. It explains the why and what is detected. However, it lacks usage guidelines and does not mention the availability of an output schema or caching behavior, making it slightly less than fully self-contained.

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. The description adds some context by mentioning that NSEC3PARAM configuration is analyzed, which relates to the 'domain' parameter, but it does not elaborate on the 'format' or 'force_refresh' parameters. Since the schema already documents all parameters thoroughly, the description provides minimal 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 purpose: assess zone walkability risk by analyzing NSEC3PARAM configuration. It specifies what it detects (plain NSEC zones, weak NSEC3 parameters, opt-out flags), which is a specific verb-resource combination. Among sibling tools like 'check_dnssec' and 'check_zone_hygiene', this tool is uniquely focused on NSEC walkability, providing clear differentiation.

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

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

No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when to prefer it over similar checks (e.g., 'check_dnssec', 'check_zone_hygiene'), or when not to use it. The description only states what it does, leaving usage context implied.

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

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive. Description adds only that it verifies PTR and is part of an audit, adding minimal behavioral insight 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?

Two sentences, zero waste. Core action is front-loaded. Every word 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?

Output schema exists, so return values are covered. Description is adequate for a simple DNS check, though it could briefly mention that it performs both forward and reverse lookups. Given sibling tools, context is sufficient.

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

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

Schema coverage is 100%, so baseline is 3. Description does not elaborate on parameters (domain, format, force_refresh); schema descriptions already handle that.

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

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

Description clearly states it verifies PTR/FCrDNS for mail servers and identifies as part of a larger audit. The verb 'verify' and resource 'forward-confirmed reverse DNS' are specific, and it distinguishes itself from sibling tools that check other DNS records (e.g., DKIM, 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?

Implies use when needing PTR verification, but no explicit statement of when to use vs. alternatives like check_mx or check_dmarc. No exclusions or conditions provided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool resolves MX hosts to IPs, checks against 7 RBLs, and may use cache (with force_refresh for fresh checks). This context goes 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?

Two sentences: first states the core action and specific RBLs, second explains the resolution step. No unnecessary words, front-loaded with key 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?

With an output schema present, the description need not cover return values. It explains the RBL coverage, resolution, and caching behavior. Minor gap: no mention of what happens if domain has no MX records or if all RBL checks pass.

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 3 parameters (domain, format, force_refresh). The description adds context about MX resolution and RBL type but does not elaborate 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 7 specific DNS-based RBLs (SpamCop, UCEProtect, etc.) and resolves MX hosts to IPs first. This distinguishes it from sibling tools like check_mx (MX records) or check_dbl (domain blocklist).

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

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

The description does not explicitly state when to use this tool versus alternatives like check_mx_reputation. Usage context is implied by the specific RBLs listed, but no when-not or alternative guidance is provided.

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

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

The description adds significant behavioral context beyond the annotations: deployment constraint ('Operator-deploy only'), degradation behavior ('degrades to info when unprovisioned'), and source specificity ('curated intel-gateway feed'). Annotations already indicate read-only, idempotent, and non-destructive, and the description complements these without contradiction.

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

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

Two sentences, front-loaded with the core purpose. Every word is informative; no redundancy or fluff. Highly concise.

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

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

The description covers purpose, distinction, deployment constraints, and fallback behavior. With a full output schema (not shown but present) and rich annotations, the description is nearly complete. It could marginally benefit from clarifying when to use this vs. other threat feed tools, but given the sibling list context, it's sufficient.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema provides for any parameter (domain, format, force_refresh). No parameter-specific elaboration is given.

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 a domain against BlackVeil real-time threat intelligence (curated intel-gateway feed).' It specifies the action (checking a domain) and the resource (intel-gateway feed), and explicitly distinguishes itself from DNSBL checks, differentiating it from similar sibling 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 usage context: 'Operator-deploy only; degrades to info when unprovisioned.' It also mentions 'Distinct from DNSBL checks,' offering some differentiation. However, it does not explicitly state when to use this tool vs. other threat-checking siblings or provide comprehensive 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 provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds no additional behavioral context (e.g., what constitutes inconsistency, which specific resolvers are used). With good annotation coverage, a score of 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 a single, front-loaded sentence that conveys the core purpose without waste. Every word is necessary and the structure is optimal for a simple tool.

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

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

The tool has 3 parameters and no output schema, yet the description is very brief. It does not explain what 'consistency' means, what the output looks like, or which resolvers are used. This leaves significant gaps for an agent to interpret results or set expectations.

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

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

Schema description coverage is 100% and each parameter is clearly described in the schema. The tool description adds no further parameter semantics (e.g., does not restate or elaborate). Baseline score of 3 as per guidelines.

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 exactly what the tool does: 'Check DNS consistency across 4 public resolvers.' It uses a specific verb ('check') and resource ('DNS consistency'), and distinguishes it from many other check_* tools by focusing on resolver-level 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 for checking DNS consistency across resolvers but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. Among many DNS-related siblings, more direction would help.

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 the specific evidence types checked, which is useful context but does not disclose additional behavioral traits (e.g., rate limits, auth needs).

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 of 20 words, front-loaded with the action and resource. It contains no fluff and is highly efficient.

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

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

The tool has an output schema, one fully described parameter, and annotations covering safety. The description enumerates the types of cross-root evidence checked, making the function clear. However, it omits any prerequisites or context (e.g., how the root server set is obtained), but given the low complexity, this is minor.

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 description's lack of parameter info is acceptable per rules. The schema alone defines the 'format' parameter with enum and description. The description adds no extra meaning 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 identifies the tool's purpose with a specific verb 'Check' and resource 'DNS root server set', and lists the types of evidence checked (root hints, root glue, delegation, serial, DNSKEY cross-root). This distinguishes it from other check_* tools that focus on different DNS aspects.

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

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

The description does not explicitly state when to use this tool over alternatives. While the specific check scope implies context, no when-not or alternative comparisons are provided. Given many sibling check tools, some guidance would improve usability.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description's incremental contribution is limited. It adds context about what the results signify (weak email auth, spoofing potential). No annotation contradiction is present.

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, consisting of two well-structured sentences. It front-loads the core action and provides a usage hint in the second sentence. Every word adds value.

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

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

Given the tool's complexity (3 parameters, output schema present, good annotations), the description is complete. It specifies the domain of applicability, differentiates from a sibling, and notes the security context. An agent has enough information to select and invoke the tool correctly.

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

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

Schema description coverage is 100%, so each parameter has a description in the schema. The tool description does not add additional semantics beyond the schema baseline. A score of 3 is appropriate as the description doesn't need to compensate for missing schema details.

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: 'Find alternate TLD variants of a domain ... that have weak or missing email authentication'. It specifies the resource (domain), action (find variants), and condition (weak auth). It also explicitly distinguishes itself from the sibling tool check_lookalikes.

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 asked about TLD variants with email auth gaps'. It also contrasts with check_lookalikes, stating that tool handles typosquat/homoglyph impersonation, which helps the agent decide which tool to invoke.

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 context beyond annotations by detailing what the tool does (list IPs, flag errors, show trust surface) and its caching behavior (implied by force_refresh parameter). Annotations already indicate read-only and idempotent, so the description complements them well.

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

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

The description is three focused sentences, front-loaded with the main action, followed by outputs and usage. Every sentence provides value without 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 moderate complexity (3 parameters, output schema exists), the description covers purpose, key outputs, usage scenario, and relationship to scan_domain. It is comprehensive enough for an agent to decide when and how to invoke it.

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

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

Schema coverage is 100%, so the parameters are fully documented in the schema. The description does not add extra meaning to the parameters (domain, format, force_refresh) beyond what the schema already provides. 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 action ('look up and validate'), the resource ('SPF record for a domain'), and the specific outputs (IPs, third-party senders, syntax errors, trust surface). It effectively differentiates from related DNS check siblings like check_dkim or check_dmarc by focusing on SPF.

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

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

The description explicitly says 'Use when you need to know who is permitted to send email as a domain', providing a clear use case. However, it does not mention when not to use or compare with the sibling tool 'resolve_spf_chain', which could be a related alternative.

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

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

Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as true/true/true/false. The description adds valuable behavioral context beyond the annotations: it mentions parallel probing of ~16 prefixes and the flagging of insecure service advertisements. This enhances understanding 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 extremely concise: two sentences. The first sentence states the tool's primary function and key details, and the second provides usage guidance. There is no redundant information, and every word adds value. Front-loaded with the most critical information.

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

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

Given the tool's complexity (3 parameters fully documented in schema, annotations covering safety and idempotency, and an output schema existing), the description completes the picture by explaining the parallel probing and security flagging behavior. No gaps are apparent for an agent to correctly invoke the 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 all three parameters (domain, format, force_refresh) having descriptions in the input schema. The tool's description does not add additional meaning beyond what the 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 clearly states the tool maps a domain's DNS-visible service footprint by probing ~16 common SRV record prefixes in parallel, covering email, calendar, messaging, web, and directory. It explicitly distinguishes from sibling check_ tools by focusing on SRV records and flagging insecure advertisements, which other tools do not do.

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 ends with 'Use when asked to map DNS-visible services or flag insecure service advertisements,' providing explicit context for when to invoke the tool. While it doesn't list when not to use it or alternatives, the sibling tool list implies that for specific record checks (e.g., DMARC), other tools should be used. This is clear but not as comprehensive as it could be.

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

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

Annotations already declare readOnly, openWorld, idempotent, non-destructive. Description adds value by listing specific output fields (issuer, expiry, protocols, HTTPS config) beyond what annotations provide. 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 concise sentences: first states purpose and outputs, second gives usage, third places it in context. Front-loaded with the key action, 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 tool with annotations and output schema, the description is fully adequate. It covers what, why, and where it fits into the broader workflow.

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

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

All parameters are described in the schema (100% coverage) with meaningful descriptions (domain example, format enum with auto-detection, force_refresh explanation). The description adds little beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states 'Check the SSL/TLS certificate for a domain' with specific outputs (issuer, expiry, protocols, HTTPS config). It distinguishes from siblings like check_dmarc or check_dnssec which cover different aspects of domain security.

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

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

Explicitly says 'Use to verify certificate validity and who issued it' and mentions it's part of scan_domain audit. However, it doesn't contrast with similar tools like check_http_security or describe when not to use it.

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

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, so the safety profile is covered. The description adds that it analyzes SPF include chains and detects risks, but does not disclose additional behavioral traits like caching behavior or permission requirements beyond what annotations imply. It adequately supplements 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 concise sentences. It front-loads the core purpose, then provides usage context, and finally notes it is part of a larger audit. Every sentence adds value with no 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 presence of an output schema (not shown but noted), the description adequately covers the tool's function and usage. It could briefly mention the output type (e.g., risk report) but the schema likely handles that. The description is complete for a specialized detection tool with good annotations.

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

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

Schema description coverage is 100% with detailed parameter descriptions for domain, format, and force_refresh. The tool description adds no new information about parameters beyond what the schema already provides. 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 detects SubdoMailing risk by analyzing SPF include chains for dangling or hijackable subdomains. It differentiates from siblings like check_spf (general SPF check) and check_subdomain_takeover (general subdomain takeover) by focusing specifically on SPF include chain hijacking.

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

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

The description explicitly tells when to use the tool: 'when you want to know if an SPF include chain can be hijacked through a dangling domain, or to detect subdomain mailing risk hidden in SPF includes.' It does not mention alternatives or when not to use, but the usage context is clear and 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, openWorldHint, idempotentHint, and non-destructive. The description adds that it sweeps subdomains, detects 16 provider families, supports explicit subdomain lists (capped at 1000), and includes a force_refresh option to bypass cache. No contradiction.

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

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

Three efficient sentences: main purpose, provider families, and usage guidance. No wasted words, front-loaded with key 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?

With an output schema present, the description need not cover return values. It covers all aspects: purpose, input parameters (including optional vs built-in), caching behavior, and integration with discover_subdomains. Complete for a scanning 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%, and the description adds valuable context: subdomains parameter details (deduped, capped at 1000, source suggestions), format auto-detection, and force_refresh use case. This goes beyond the schema's basic descriptions.

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

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

The description clearly states the tool's purpose: sweeping subdomains for dangling CNAMEs indicating subdomain takeover vulnerabilities. It specifies detection of 16 provider families, making it distinct from sibling tools like check_http_security or check_ssl.

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

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

The description says 'Use when asked if subdomains are pointing to deprovisioned cloud services' and suggests pairing with discover_subdomains for full inventory. While it provides clear context, it does not explicitly state when not to use this tool.

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

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

Annotations already declare the tool as read-only, idempotent, open-world, and non-destructive. The description adds context about the validation purpose and its role in an audit, which is consistent and provides behavioral context 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 extremely concise: one sentence specifying the function and one sentence placing it in the audit workflow. It is front-loaded with the verb and resource, and every part adds value.

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

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

Given the presence of an output schema, the description appropriately does not detail return values. It covers purpose and context well. However, among many similar checks, it could briefly mention when this particular check is relevant (e.g., after DNS changes or for HTTPS compliance).

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 clear descriptions for all three parameters (domain, format, force_refresh). The tool's description does not add additional parameter information beyond what the schema already provides, so it meets the baseline of 3.

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

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

Description clearly states it validates HTTPS/SVCB records per RFC 9460 for modern transport capability advertisement, and notes it's part of scan_domain audit. This distinguishes it from sibling check_* tools by specifying the exact record type and standard.

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?

Description only says 'Part of the scan_domain audit', which gives minimal context. It does not explicitly state when to use this tool vs alternatives like check_dane_https, nor does it mention prerequisites or when not to use it. The force_refresh parameter description offers a slight hint but is part of schema.

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

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

Annotations already indicate read-only, idempotent, non-destructive. Description adds details on DNS query and validation criteria, providing additional transparency 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?

Three concise sentences, front-loaded with purpose, 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?

Covers what the tool does, DNS query, and validation logic. Output schema presumably covers return values, so description is sufficiently complete for a simple DNS check.

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 good param descriptions. The tool description adds overall context but does not elaborate on individual parameters 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?

Description clearly states the tool checks TLS-RPT configuration, specifies DNS record queried, and validation logic. It distinguishes from sibling MTA-STS by noting it complements that 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?

Description implies usage context (complementing MTA-STS, part of scan_domain audit) but does not explicitly state when not to use or list 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, so the tool is safe. The description adds behavioral context by specifying the audit focuses (stale entries and SaaS exposure), which goes beyond raw record retrieval. No contradictions.

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

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

The description is a single 9-word sentence, highly concise and front-loaded. Every word contributes to understanding the tool's purpose.

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

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

Given the presence of an output schema and high schema coverage, the description is adequate. It could briefly explain what constitutes 'stale entries' or 'SaaS exposure' for better context, but the tool is simple enough to be understood.

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 have descriptions). The tool description does not add extra meaning beyond the schema, so it meets the baseline of 3 without enhancement.

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 TXT records, specifically for stale entries and SaaS exposure. It uses a specific verb ('Audit') and resource ('TXT records'), distinguishing it from sibling tools 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 usage for TXT record hygiene checks, but does not explicitly compare to alternative sibling tools or provide when-not-to-use guidance. Given the unique focus, it is clear but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds value by detailing what the audit identifies (subdomains, SOA records, propagation issues), providing behavioral context beyond the annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and every sentence adds value. No extraneous words or repetition.

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

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

Given the presence of an output schema and comprehensive annotations, the description adequately covers the tool's purpose and use cases. It could mention the output format briefly, but the output schema handles that responsibility.

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 meaning beyond the schema, so a baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'audit' and the resource 'DNS zone hygiene', and lists specific items it identifies (sensitive subdomains, stale SOA records, propagation issues). It distinguishes itself from sibling tools like check_dmarc or check_spf by focusing on broad zone cleanliness rather than individual record types.

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 two explicit use cases: finding sensitive subdomains and auditing overall zone cleanliness. While it does not explicitly mention when not to use or alternatives, the context is clear and sufficient for most scenarios.

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, establishing a safe, non-destructive profile. The description adds context by specifying the baseline is a 'fixed policy' and not a prior scan, clarifying what the tool does not do. No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the main purpose, and every word earns its place. No unnecessary elaboration or repetition of schema 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 description fully covers purpose, usage, and parameter semantics. However, there is no mention of the output format (e.g., compliance status). Given the tool's simplicity and good annotations, this is a minor gap, but completeness is otherwise high.

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

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

Schema coverage is 100% with detailed parameter descriptions. The tool description adds value by emphasizing the 'fixed policy baseline' and the baseline parameter description clarifies it is 'NOT a prior scan' and distinguishes from analyze_drift. This adds semantic meaning 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 states a specific verb ('Compare'), resource ('domain's current security configuration against a fixed policy baseline'), and purpose ('to determine compliance'). It explicitly distinguishes from sibling tools: 'not for tracking improvement/regression over time (use analyze_drift) and not for comparing multiple domains (use compare_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?

Clearly indicates when to use ('check whether a domain meets a policy requirement') and explicitly states when not to use, with named alternatives ('use analyze_drift' for drift, 'use compare_domains' for multi-domain comparison).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds value by detailing what the comparison shows (relative scores, category gaps, unique weaknesses), providing clarity 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?

Two sentences with no wasted words. First sentence defines purpose and outputs, second sentence gives usage context. Efficient and front-loaded.

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

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

For a tool with 3 parameters, no output schema, and clear annotations, the description sufficiently sets expectations about outputs and usage. Could be improved by mentioning the caching behavior related to force_refresh, but not required.

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 is well-documented in the schema. The description mentions the domain count range but does not add significant new parameter semantics beyond the schema. 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 'Side-by-side security comparison of 2–5 domains' with specific outputs like relative scores, category gaps, and unique weaknesses. It distinguishes from siblings like compare_baseline by focusing on security posture 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?

Provides explicit use cases: 'Use when comparing your security posture against a competitor, or doing a head-to-head comparison between multiple domains.' Does not explicitly mention when not to use, but context is clear.

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

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

Annotations already cover read-only, idempotent, and non-destructive behaviors. The description adds value by noting the tool flags high-risk ASNs and uses Team Cymru DNS, implying external network calls. 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 concise sentences cover action, outputs, and a key differentiator. No unnecessary words; every sentence earns its place.

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

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

Given the presence of output schema and comprehensive annotations, the description is largely complete. It describes the core functionality and outputs. Minor gaps include lack of mention of error conditions or domain resolvability prerequisites.

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 elaborate on the 'format' or 'force_refresh' parameters beyond the schema's own descriptions. Minimal added meaning for parameters.

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

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

The description clearly states the tool maps domain IPs to ASNs via Team Cymru DNS, listing specific return fields and a distinguishing feature (flagging high-risk ASNs). It differentiates from sibling tools by specifying the data source and output focus.

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 ASN information is needed for a domain's IPs, but does not explicitly state when not to use or name alternatives among sibling tools (e.g., rdap_lookup). It provides 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?

Discloses permanent removal (aligning with destructiveHint=true) and return type (confirmation). Adds ownership scoping behavior beyond annotations, enhancing 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?

Two sentences, no redundant information, front-loaded with key action and immediate consequence.

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 one parameter with 100% schema coverage, annotations present, and output schema, the description adequately covers usage, scope, and return value without 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?

The single parameter watchId is fully described in the schema. The description does not add additional syntax or semantics beyond referencing the source of the ID, so meets 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 action (permanently removes) and the resource (recurring brand-audit watch), distinguishing it from sibling tools like register_brand_audit_watch and list_brand_audit_watches.

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 mentions owner-scoping and the notFound behavior for watches owned by others, providing clear context on when to use. Lacks explicit when-not-to-use but scope is well-defined.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds behavioral context by explaining the aggregation of certificate, DNS, redirect, and mail-policy signals. It also mentions cache bypass via force_refresh. No contradictions with annotations.

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

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

The description is very concise: two sentences plus a key instruction. It front-loads the purpose and avoids any fluff. Every sentence adds value.

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

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

Given the tool's complexity (12 parameters, 2 required) and the existence of an output schema, the description adequately covers core use cases and key behavioral notes. It does not explain every parameter in detail, but that is handled by the schema. The description is complete enough for an AI agent to use correctly.

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

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

Schema coverage is 100%, so all parameters are documented. The description adds extra guidance on the 'domain' parameter (pass verbatim, no normalization) and briefly explains 'discovery_mode'. This adds marginal value beyond the schema, justifying a 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 it discovers domains belonging to a brand's portfolio using multiple signals. It provides a specific verb and resource and distinguishes this tool from siblings like 'discover_subdomains' by focusing on brand-wide portfolio discovery.

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

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

Explicitly states when to use: 'when asked what domains are part of a brand portfolio, or to find all domains related to a brand.' Also gives a critical usage instruction: pass the exact seed domain verbatim. It lacks explicit when-not-to-use guidance, but the provided context is strong.

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