dns-security-mcp

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

No annotations are provided, so the description carries the full burden. It discloses that the IP is reversed and queries run in parallel, and that results are per-list with status and reason. However, it does not mention potential rate limits, timeouts, or handling of individual list failures, which are typical concerns for an external network tool.

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

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

The description is three sentences with no fluff: it states the core action, the method (parallel queries), and the return value. Every sentence earns its place, and the most important information is front-loaded.

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

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

The description covers the key return information (per-list status and reason) and the operational approach (parallel queries), which is sufficient for an agent to understand the tool's behavior. It lacks exact result structure and error handling, but given the moderate complexity and no output schema, this is a minor gap.

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

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

Schema description coverage is 100%, so both parameters are fully documented. The description adds little beyond what the schema provides, aside from implementation details like reversing the IP and parallel queries. Baseline of 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool checks an IP address against multiple DNS-based blocklists, with a specific verb and resource. It distinguishes from siblings like bl_check_surbl by emphasizing IP-based DNSBL/RBL checks, and mentions parallel queries and per-list 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?

The description implies usage: it is for checking IP reputation against multiple blocklists, and the focus on 'IP address' helps differentiate from domain-focused alternatives like bl_check_surbl. However, it does not explicitly state when to use this versus other blocklist tools or provide exclusions, leaving room for 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?

With no annotations, the description carries the transparency burden. It clearly indicates a read-only check ('Check'), lists the specific sources queried, and states the return value (whether malware association was found and the source). This is sufficient for a simple lookup tool, though it doesn't detail potential caveats like rate limits or real-time vs. cached data.

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

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

The description is two sentences, front-loaded with the action and resource, and contains no filler. Every phrase adds value: the specific blocklist names and the return value are both essential for understanding the 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?

For a tool with one parameter and no output schema, the description is complete: it states what is checked, against which sources, and what is returned. It could potentially detail the exact response format, but for this simple lookup, the description provides enough context for an agent to use it correctly.

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

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

Schema coverage is 100% and the schema already fully describes the single parameter 'domain' with an example. The description does not add additional parameter-level semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description clearly specifies the action ('Check a domain'), the resource (malware-specific blocklists), and names concrete sources (abuse.ch URLhaus, Spamhaus DBL, SURBL malware category). This distinguishes it from sibling tools like bl_check_phishing or bl_check_dnsbl by focusing on malware-specific categories.

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

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

The description provides clear context: use when you need to check a domain specifically against malware blocklists. It doesn't explicitly mention alternatives, but the specificity of 'malware-specific' and the listed sources imply the appropriate use case, differentiating it from general DNSBL or phishing 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?

With no annotations, the description carries the full burden of disclosure. It transparently reveals that the tool makes external queries to Spamhaus DBL, SURBL, and RDAP, and it states the output includes phishing indicators and a confidence score. This provides meaningful behavioral context, though it could additionally explain failure modes or caveats about external service availability.

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

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

The description is two sentences long and front-loaded with the primary action and purpose. Every clause earns its place: the data sources, the output type, and the confidence range are all included 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?

For a single-parameter tool with no output schema, the description adequately conveys the tool's scope and return values ('phishing indicators and confidence level'). It could be more complete by specifying the structure of indicators or how confidence is calculated, but given the simplicity, it is sufficiently complete.

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

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

Schema coverage is 100% for the single 'domain' parameter, so the schema already documents it fully. The description does not add extra semantics beyond the schema's example, making the baseline score of 3 appropriate.

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

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

The description clearly states the verb ('Check'), the resource ('a domain'), and the specific purpose ('phishing indicators'). It names the exact sources (Spamhaus DBL, SURBL phishing list, RDAP), which distinguishes it from sibling tools like bl_check_dnsbl or domain_age, making its combined nature explicit.

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

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

The description implies usage for phishing-related domain checks and mentions the data sources, but it does not explicitly state when to choose this tool over alternatives such as bl_check_surbl or domain_age. No exclusions or alternative recommendations are provided, leaving the selection decision somewhat 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?

No annotations are provided, so the description must fully disclose behavior. It states that the tool returns 'listed/not listed per list with category', clearly conveying output behavior. It does not mention potential timeouts or detailed response structure, but for a simple read-only check, 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, front-loaded sentence that states the action, scope, and return value without unnecessary words. It is appropriately concise 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?

This is a simple tool with one parameter and no output schema. The description explains what it does and what it returns at a high level. It lacks detailed category enumeration, but given the simplicity, it is sufficiently complete for an agent to invoke it correctly.

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

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

The input schema has 100% coverage for the single 'domain' parameter, with a description that mirrors the tool description. The description adds no additional semantics beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool checks a domain against domain-based blocklists, naming specific lists (SURBL, Spamhaus DBL, URIBL). The verb 'Check' and resource 'domain' are specific, and it distinguishes from sibling bl_check_dnsbl by specifying 'domain-based' rather than IP-based blocklists.

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

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

The description implies the tool is for checking domains (not IPs) against domain-based blocklists, providing clear context. However, it does not explicitly mention alternatives or when not to use it, such as for IP-based checks, though sibling tools like bl_check_dnsbl exist.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It explains the inputs (domain) and outputs (score, contributing factors, verdict), but does not mention potential side effects, data source freshness, query latency, or whether it is a read-only operation. This is adequate but not rich in behavioral context.

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

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

The description is two concise sentences, front-loading the core purpose and then listing return values. Every word contributes value, with no redundancy or filler, making it an exemplary model of brevity and 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 moderate complexity (single parameter, no output schema), the description sufficiently covers what the tool does, what inputs it takes, and what outputs it returns. It could optionally mention score calculation methodology or potential delay from DNS lookups, but these are not essential for invoking the tool correctly, so it is nearly 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?

The input schema already provides 100% coverage for the single 'domain' parameter with a clear description. The tool description does not add extra semantic details about the parameter (e.g., punycode, IP addresses, or format constraints), so it meets the baseline for high schema coverage but does not exceed it.

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

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

The description uses a specific verb 'Calculate' and clearly identifies the resource: an aggregated domain risk score. It lists the contributing factors (DNSBL listings, domain age, DNSSEC presence, SPF/DMARC configuration) and distinguishes itself from sibling tools that perform individual checks, making it an aggregate scoring tool.

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

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

The description implies when to use this tool by calling it 'aggregated' and listing multiple data sources, suggesting it's suitable for a holistic risk assessment. However, it does not explicitly state when to use it over the individual sibling tools or provide any exclusion criteria, leaving the usage guidance somewhat 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?

With no annotations, the description carries the transparency burden. It discloses the method (multiple DNS resolutions with intervals) and the output (flux score 0-100). It does not mention potential wait times or failure modes, but for a read-only detection probe this is reasonably 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?

The description is three concise sentences, front-loaded with purpose, and every sentence adds useful information: the action, the indicators, and the return value. 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?

It covers what, how, and what is returned. Given there is no output schema, explaining the flux score is valuable. It lacks explicit notes on duration (samples * interval_ms) and failure handling, but overall it is sufficient for a moderately complex 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 baseline is 3. The description adds meaning by connecting the parameters to fast-flux indicators (e.g., 'multiple IPs per query' justifies 'samples', 'very low TTL' relates to resolution timing). This helps the agent understand why to tune samples and interval_ms.

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 'Detect' with a specific resource ('fast-flux DNS behavior') and explains the method (resolving a domain multiple times with intervals). It distinguishes from sibling tools like bl_check_dnsbl by focusing on fast-flux indicators.

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

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

It provides clear context for when to use the tool (when fast-flux is suspected) and lists observable indicators. However, it does not explicitly mention alternatives or exclusions, such as dns_ttl_analysis for TTL-focused inspection.

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

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

With no annotations, the description discloses the data source (CT logs), grouping logic (active/expired, wildcard/specific, CA), and return values (total count, active count, unique subdomains, CA distribution). This gives the agent a solid behavioral model, though it doesn't mention potential limitations or side effects, which are minimal for a read-only inventory operation.

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 specifies both grouping dimensions and output fields without 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 simple schema and lack of output schema, the description fully covers what the tool does and returns, making it sufficiently complete for an agent to select and invoke it.

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

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

The input schema already describes the single 'domain' parameter with an example. The tool description adds 'for a domain' but does not significantly enhance semantic understanding beyond the schema's existing description, warranting the baseline score for high schema coverage.

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

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

The description states 'Build a full certificate inventory from CT logs for a domain' with a specific verb ('Build') and resource ('certificate inventory'), and it clearly differentiates from sibling CT tools by focusing on inventory grouping and summary counts.

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 obtaining a comprehensive certificate inventory, but it does not explicitly reference alternative tools like ct_search or ct_wildcard_audit. It provides clear context but no exclusion 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?

With no annotations, the description carries the burden. It discloses analysis and flagging behaviors, but omits whether the tool is read-only, any required permissions, rate limits, or output format. It does specify analyzed tags and flags, which is meaningful, but lacks depth on side effects or response structure.

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

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

Two concise, front-loaded sentences. No fluff, every clause contributes. The structure clearly leads with the verb and resource, then details analysis and flags.

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 one parameter, no output schema, and moderate complexity. The description covers the core functionality and expected outcomes (flags), but doesn't explain return format or error handling. Given the simplicity, this is sufficient for a basic understanding, though not fully complete.

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

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

Schema coverage is 100% with a clear parameter description. The tool description adds extra semantic value by explaining that the domain and its parents are checked, which clarifies the parameter's scope beyond what the schema states. That's a valuable addition.

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 CAA DNS records for a domain and its parents, with specific actions (analyzes issue, issuewild, iodef tags) and outputs (flags missing CAA, unrestricted wildcards, missing iodef). This distinguishes it from other DNS/CT tools and is highly specific.

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

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

The description implies a clear use case: whenever CAA record validation or audit is needed. It doesn't explicitly mention alternatives or exclusions, but the scope is so focused that context is inherent. A minor gap is lack of comparisons to sibling tools like ct_wildcard_audit.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. While it states the return fields, it does not mention whether this is a read-only operation, whether it queries live CT logs, rate limits, or how it handles no results. 'Find' implies non-mutation, but important operational details are absent.

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

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

Two concise sentences deliver the core purpose and return information without redundancy. The description is front-loaded and 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?

Despite a simple 2-parameter, no-output-schema design, the description lacks clarity on what 'expiring' includes (e.g., already expired certs), whether subdomains are covered, and what happens with no matches. It is sufficient for basic use but leaves ambiguities for a monitoring tool.

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

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

Schema description coverage is 100% for both parameters, so the baseline is 3. The description adds minimal semantic value by mentioning 'N days,' which maps to days_threshold, but it does not explain parameter interactions or edge cases 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 uses a specific verb ('Find'), a clear resource ('certificates expiring within N days for a domain'), and lists return fields. It distinguishes this tool from siblings like ct_search and ct_cert_inventory by focusing on expiration thresholds.

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 expiry monitoring but provides no explicit when-to-use or alternatives. It does not mention when not to use it or compare with sibling tools like ct_monitor, leaving the agent to infer the appropriate context.

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

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

No annotations are provided, so the description must carry the transparency burden. It discloses that the tool is a read-only monitor that returns certificate data, which is the core behavioral trait. It does not describe output format, pagination, or whether it only checks exact domain matches, but for a benign lookup tool this is acceptable.

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

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

The description is two sentences, with the key action and resource in the first sentence and the return behavior in the second. It is front-loaded and contains no fluff or redundant details.

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

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

Given that the tool has only two parameters and no output schema, the description covers the essential behavior: what it does, what it returns, and the main parameters. It lacks edge-case info like empty results or domain normalization, but it is complete enough for an agent to call it correctly. Sibling differentiation is not required for completeness.

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

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

The input schema already provides full descriptions for both parameters (domain and days). The description's mention of 'last N days' and 'given domain' aligns with the schema but adds no additional syntax, format, or example details. Thus 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 tool's function: monitoring Certificate Transparency logs to return recently issued certificates for a domain. It specifies the time window ('within the last N days') and target (domain), which differentiates it from sibling CT tools like ct_expiry_monitor or ct_cert_inventory. However, it does not explicitly name alternative tools, so it misses the top bar for distinction.

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

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

The description explicitly states the use case: monitoring recently issued certificates for a domain within a specified lookback period. It provides clear context for when to use the tool, though it does not mention when not to use it or name alternatives. This meets the 'clear context, no exclusions' level.

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

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

With no annotations, the description carries the transparency burden. It explains the data source (crt.sh) and the output fields, but does not mention rate limits, result freshness, whether expired certificates are included, or pagination behavior. It does not contradict any annotations (none provided), but additional behavioral context would be beneficial.

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

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

The description is concise and front-loaded, with two sentences that start with the action ('Search') and quickly cover the resource, input, and output. There is no wasted wording or redundancy.

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

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

The tool is a straightforward read-only search with no output schema, but the description lists the return fields directly. It lacks mention of edge cases (e.g., empty results, wildcard behavior) but these are partly covered by parameter descriptions. For a simple search tool, the description is reasonably complete, though it could briefly state what the response format looks like.

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

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

The input schema has 100% coverage: each parameter (limit, domain, include_subdomains) has a clear description. The tool description adds no extra parameter detail 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's function: searching Certificate Transparency logs via crt.sh for certificates issued for a domain. It specifies the resource (crt.sh), the action (search), and the scope (for a domain), and it lists the returned fields (issuer, validity dates, serial number, common name), distinguishing it from more specialized CT sibling tools like ct_cert_inventory or ct_expiry_monitor.

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 searching CT logs but does not explicitly state when to choose this tool over specialized siblings like ct_wildcard_audit or ct_monitor. It provides no alternatives or exclusions, though the context of searching certificates by domain 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?

With no annotations provided, the description bears the full burden of behavioral disclosure. It explains the detection mechanism and that it flags unauthorized certs, but does not mention whether the operation is read-only, what external resources it relies on (e.g., CT log APIs, DNS), or how it handles cases like missing CAA records.

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

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

The description is two concise sentences that immediately state the tool's purpose and core logic. Every phrase adds value, and the structure is front-loaded with the most important 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?

While the description captures the core function, it lacks details about output format or error conditions, and there is no output schema to clarify return values. It also does not explain how the optional 'allowed_cas' parameter modifies behavior, leaving the tool somewhat underspecified for complete use.

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

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

The input schema provides 100% coverage of parameters, including descriptions for 'domain' and 'allowed_cas'. The tool description does not add additional parameter details beyond the schema, so it meets the baseline without exceeding it.

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

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

The description uses a specific verb ('Detect') and resource ('potentially unauthorized certificates') with a clear method (cross-referencing CT logs with CAA DNS records). It clearly distinguishes itself from sibling tools like ct_search or ct_check_caa by combining both data sources.

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

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

The description implies the tool is for detecting unauthorized certificates but does not explicitly state when to use it over alternatives or any exclusions. It offers no comparisons to sibling tools like ct_check_caa or ct_monitor, leaving the usage context to inference.

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

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

The description discloses the tool's output behavior—number of wildcards, issuing CAs, date ranges, and flags for multiple CAs—which is helpful given no annotations. It implies a read-only audit, though it doesn't explicitly state safety guarantees.

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

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

Two concise sentences with no fluff, front-loading the main action and then detailing outputs.

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 one-parameter tool with no output schema, the description adequately covers purpose, scope, and reported fields. It is complete for an agent to select and invoke.

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 'domain' parameter is fully described in the schema with an example, so the tool description adds no extra param semantics. 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 identifies the tool as auditing CT logs for wildcard certificates and lists specific output elements (count, CAs, date ranges, flagging). This distinguishes it from general CT search tools like ct_search.

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

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

The description establishes a clear use case: auditing wildcard certificates in CT logs. It does not explicitly mention when not to use it or alternatives, but the context is specific enough for an agent to differentiate from 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the exact protocol behavior (RD=0, no recursion), the response interpretation (answer without recursion = cached), and the inference about recent domain visits. It would benefit from noting limitations such as TTL dependence or resolvers that ignore RD=0, but the core behavior is thoroughly described.

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 (45 words), front-loaded with the action, and every sentence earns its place: the first states the operation, the second explains how to interpret the result. No filler or redundancy.

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

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

The tool is a simple two-parameter query with no output schema, so the description must convey what the tool returns or how results are presented. The interpretation logic is explained, but the concrete return format (e.g., boolean, DNS answer, or status message) and edge cases (e.g., resolvers that ignore RD=0 or cache expiration) are not disclosed, leaving a meaningful gap.

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

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

Schema description coverage is 100% — both 'domain' and 'nameserver' have clear descriptions with examples. The tool description adds no new parameter-level detail beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('Perform DNS cache snooping') and precisely identifies the target resource (a nameserver) and the mechanism (non-recursive query with RD=0). It clearly distinguishes this from sibling tools like dns_lookup or dns_recursive_check by explaining the stealthy cache-probing technique and its forensic interpretation.

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

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

The description conveys a clear use case: revealing whether someone behind a resolver recently visited a domain by inspecting the resolver's cache. It implies when to use this tool (stealthy reconnaissance) and provides the expected result interpretation, though it does not explicitly name alternatives or state 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?

No annotations are provided, so the description carries full responsibility. It discloses key behavior: parallel resolution of multiple record types, a default set of common types, and optional type/resolver filtering. It does not mention potential latency or error cases, but for a read-only network lookup, the description is sufficiently 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?

The description is two sentences: first states the core action and method, second lists returned record types and optional parameters. Every sentence is informative and there is 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?

For a straightforward DNS lookup with a small parameter set, the description covers the purpose, optional parameters, and return content. It does not cover when to prefer specialized sibling tools, but the simplicity of the operation means this is not a critical gap.

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

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

The schema already provides 100% coverage for all three parameters with clear descriptions. The tool description adds minor value by enumerating the default record types and hinting at the 'custom resolver' option, but does not significantly extend what the schema provides.

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

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

The description clearly states the tool's function: resolving all DNS record types for a domain, with an explicit list of record types. The verb 'Resolve' and resource 'domain' are specific, and the tool is distinctly the general lookup tool among many specialized DNS siblings.

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

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

The description provides clear context: this is the general-purpose DNS lookup for all record types, with options to filter by type or use a custom resolver. It does not explicitly reference sibling tools or exclusions, but the scope is evident from the description.

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

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

With no annotations provided, the description carries full responsibility. It honestly uses 'Attempt' and explicitly discloses that NSEC3 will be detected and reported, which sets expectations about failure modes. It does not mention read-only behavior or potential rate-limiting, but the DNS query nature is implied and the key limitations are covered.

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 the second sentence efficiently adds the mechanism and NSEC3 caveat. No redundant text or filler.

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

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

For a moderately simple tool with full schema coverage and no output schema, the description covers purpose, mechanism, and a key limitation (NSEC3). It could be more complete by explicitly describing the return format or exactly how NSEC3 is 'reported,' but overall it provides sufficient context for an agent 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 both 'domain' and 'limit' already having clear descriptions in the schema. The tool description adds no additional parameter-level details, so it meets the baseline 3 without exceeding it.

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

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

The description states a specific action ('Attempt DNSSEC NSEC zone walking to enumerate domain names in a signed zone') and clearly distinguishes this from sibling tools like dns_subdomain_enum or dns_zone_transfer by focusing on the NSEC record mechanism. The purpose is unambiguous and actionable.

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

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

The description implies that the tool is for DNSSEC-signed zones using NSEC, and notes that NSEC3 mitigates the technique and is 'detected and reported,' which gives context on limitations. However, it does not explicitly state when to use this over alternatives or exclude non-NSEC zones, so it falls slightly short of full 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?

No annotations are provided, so the description carries full burden. It discloses that the tool queries many public resolvers, reports per-resolver results, and provides a consistency check, which conveys the read-only nature and output behavior. It does not mention potential limitations like query time or rate limits, but for this type of non-destructive DNS check, the provided information is adequate.

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

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

The description is two sentences, front-loaded with the primary action and includes both method and output details. Every phrase contributes 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 tool's simplicity (only two parameters, both documented) and no output schema, the description adequately explains the tool's behavior and expected results. The mention of per-resolver results and consistency check provides sufficient context for an agent to invoke it appropriately.

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

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

The schema already provides complete descriptions for both parameters (domain and type, including supported types and default), so the description adds no extra parameter semantics. Per the rule, with >80% schema coverage, the baseline of 3 applies.

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

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

The description uses a specific verb 'Check' with resource 'DNS propagation' and explains the method (querying 20+ globally distributed public resolvers). It clearly distinguishes from sibling tools like dns_lookup by emphasizing global coverage and consistency checks.

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

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

The description clearly implies when to use this tool: when a global propagation check is needed, as it queries 20+ resolvers and reports geo-based differences. It does not explicitly name alternatives or exclusions, but the context is clear that for single-resolver lookups other tools might be more appropriate.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals the core behavior (sending an RD=1 query to a nameserver) and the security risk it identifies. However, it does not disclose potential side effects (e.g., generating traffic to the target, triggering alerts) or what the response format looks like, leaving some gaps.

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: the first explains the action, the second provides rationale. Both sentences are informative and concise, with no wasted words or redundant content.

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

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

For a simple one-parameter tool with no output schema, the description adequately covers the purpose and method. It does not describe the return value format, but the intent is clear and the low complexity makes this sufficient. A higher score would require explicit output 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?

The input schema fully describes the single parameter 'nameserver', including its purpose and an example. The tool description adds no further semantic detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool tests whether a DNS nameserver is an open recursive resolver, using a recursive query (RD=1) for an external domain. This is a specific verb-resource-methodology combination that fully conveys the tool's purpose and its security relevance.

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

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

The description provides clear context for when to use the tool: during security assessments of DNS nameservers to identify open recursion. It does not explicitly mention alternatives or exclusions, but the use case is evident, so it earns a 4 rather than a 5.

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

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

With no annotations, the description takes on full responsibility for behavior disclosure. It transparently describes the two-step process: resolving the PTR record and then forward-resolving the hostname to confirm mapping. It doesn't mention edge cases like missing PTR records, but the core behavior is well disclosed.

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

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

The description is two sentences: the first states the core purpose and the second elaborates the validation flow. Every word is necessary, and it's front-loaded with a clear verb.

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 one-parameter DNS tool, this description is complete: it explains both the lookup and the validation logic. There is no output schema, but the behavior is sufficiently described to understand what the tool does, though missing potential response details.

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

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

The input schema already provides a clear description for the single 'ip' parameter, and the tool description doesn't add additional parameter details. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Perform PTR lookup') with a specific resource ('IP address') and adds the distinctive validation step ('FCrDNS validation'). This clearly differentiates it from sibling tools like dns_lookup or email_check_ptr.

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

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

The description clearly implies when to use this tool (when you need reverse DNS with forward-confirmed validation), giving context for its use case. However, it doesn't explicitly name alternatives or exclusions, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explains the analysis performed (inventory, mapping, flagging, recommending) but does not disclose side effects, network access requirements, read-only nature, or what happens if no relevant records exist. It adds value but lacks comprehensive transparency.

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

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

The description is concise and front-loaded with the primary action ('Inventory all DNSSEC algorithms'). It uses three short sentences that each add distinct value (scope, mapping, recommendations) with no wasted 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?

For a focused audit tool with no output schema, the description is fairly complete: it explains the scope (record types), the mapping behavior, and the output's key elements (deprecated flags, recommendations). It could improve by hinting at the output format or what to expect when no DNSSEC records exist, but overall it provides sufficient 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?

The input schema has 100% coverage for the single 'domain' parameter, so the baseline is 3. The description does not add any additional meaning about the parameter beyond what the schema already provides, but it does not need to since the schema is sufficient.

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: to inventory DNSSEC algorithms across DS, DNSKEY, and RRSIG records. It specifies actions (inventory, map, flag, recommend) and details deprecated and recommended algorithms, making it distinct from sibling DNSSEC tools like dnssec_validate or dnssec_check_ds.

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

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

The description implies use for security audits by flagging deprecated algorithms and recommending modern ones, but it does not explicitly state when to use this tool versus other dnssec_* siblings. No exclusions or alternatives are provided, so usage context is implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden. It discloses key behaviors: distinguishing KSK vs ZSK, reporting algorithm and protocol, and flagging weak vs strong algorithms. This goes beyond a simple 'list' and gives useful behavioral insight, though it omits response format or potential failure modes.

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, front-loaded with the main action. Every sentence adds value: listing, distinguishing key types, and reporting algorithm strength. No fluff or redundancy.

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

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

For a single-parameter tool with no output schema and no annotations, the description is complete enough. It fully communicates the tool's function and output characteristics, covering all essential aspects without needing external 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?

The input schema covers the only parameter 'domain' with a clear description, achieving 100% schema coverage. The tool description adds no additional parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool lists DNSKEY records for a domain, with a specific verb ('List') and resource. It further distinguishes KSK vs ZSK and reports algorithm/protocol, which clearly separates it from sibling DNSSEC tools like dnssec_check_ds or dnssec_check_rrsig.

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

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

The description provides clear context for when to use the tool (to inspect DNSKEY records and assess key algorithms), but it does not explicitly mention alternatives or when not to use. This is clear context without exclusions, so a 4 is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It discloses the core behavior: queries DS from parent, DNSKEY from child, verifies existence, and reports algorithm strength and digest type. However, it does not mention potential side effects (none expected), error handling, or whether it performs live DNS queries, though the read-only nature is implied.

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

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

The description is exceptionally concise: two sentences that front-load the verb and quickly cover purpose, method, and output. There is no fluff or repetition of schema details, and every sentence earns its place.

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

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

With one parameter, no annotations, and no output schema, the description provides a good overview: what it checks, how it queries, and what it reports (algorithm strength and digest type). It could be more complete by describing the exact return structure or failure behavior, but for a simple tool it covers the essential context.

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

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

Schema coverage is 100%: the 'domain' parameter is already described as 'The domain name to check DS records for (e.g. 'example.com')'. The description adds no extra meaning about parameter format or constraints beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states the tool checks DS records for a domain, explicitly naming the resource (Delegation Signer records) and the action ('Check'). It further distinguishes from siblings like dnssec_check_dnskey and dnssec_validate by specifying it queries DS from parent zone and DNSKEY from child zone, and reports algorithm strength and digest type.

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

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

The description implies when to use the tool: when you need to check DS records for a domain. It provides clear context (e.g., querying both parent and child zones) but does not explicitly mention alternatives or exclusions, such as 'use dnssec_validate for full chain validation'.

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

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

With no annotations provided, the description carries the burden of disclosure. It effectively explains the tool's behavior: it reports NSEC vs NSEC3, and for NSEC3 includes hash algorithm, iterations, and salt, while flagging NSEC as an informational risk. It does not cover edge cases like non-DNSSEC zones, but the core behavior is clearly communicated.

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

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

The description is concise and well-structured, using three sentences that each add value: stating the action, explaining the distinction, and detailing the risk flag. No unnecessary 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?

For a single-parameter tool with no output schema, the description adequately explains what the tool reports (NSEC vs NSEC3, hash parameters, risk flag). It does not mention behavior for domains without DNSSEC or error cases, but given the simplicity of the tool, this is sufficient for an agent to understand the tool's scope.

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 the only parameter 'domain' having a clear description. The tool description does not add additional parameter-specific details beyond what the schema already provides, but none are needed given the schema's clarity. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Check NSEC/NSEC3 records for a domain' and distinguishes it from siblings by explicitly contrasting NSEC (enumerable) and NSEC3 (hashed names). It also specifies the outcome of flagging NSEC as a risk, making the tool's function highly distinct.

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 conveys when to use the tool (when needing to determine NSEC vs NSEC3 usage and associated risk). However, it does not explicitly mention alternatives or exclusion conditions, such as when a zone lacks DNSSEC or when other related tools like dns_nsec_walk would be more appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add value beyond the name by stating that it reports days until expiry and flags signatures expiring within 7 days. However, it does not describe error handling, behavior when no RRSIG records exist, or the exact response format, leaving some behavioral ambiguity.

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 primary purpose, followed by details on what is extracted and the key output threshold (7 days). Every sentence earns its place 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 single parameter, no output schema, and simple scope, the description covers the purpose, extracted fields, expiry reporting, and flagging threshold. It is sufficient for an agent to invoke the tool and interpret the outcome, though adding a note on return structure or non-existent RRSIG cases would improve completeness.

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

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

Schema coverage is 100% with a clear description for the 'domain' parameter ('The domain name to check RRSIG records for (e.g. 'example.com')'). The tool description does not add extra parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description uses a specific verb+resource combination: 'Check RRSIG (Resource Record Signature) records for a domain', and elaborates on what it does (extracts type covered, algorithm, etc.). This clearly distinguishes it from sibling tools like dnssec_check_dnskey or dnssec_validate by focusing specifically on RRSIG records and their expiry.

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

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

The description implies the tool is for checking RRSIG expiry information, but it does not explicitly state when to use it versus alternatives (e.g., dnssec_validate, dnssec_check_ds). There's no mention of when not to use it or how it fits into a broader DNSSEC audit workflow.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses the tool's behavior in detail: it runs seven specific checks and aggregates results into a severity-scored report with remediation guidance. This goes beyond a generic 'audits DNSSEC' and informs the agent about the tool's scope and output, though it does not explicitly mention read-only nature or potential prerequisites.

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

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

The description is two sentences long and thoroughly front-loaded, starting with 'Comprehensive DNSSEC audit' and immediately enumerating the seven checks. Every word adds value, with no filler or repetition.

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

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

For a one-parameter tool with a well-described schema and no output schema, the description sufficiently covers the tool's core function and output format (severity-scored report with remediation). It lists all sub-checks, giving a complete picture of what the audit entails. Minor gaps like error handling or runtime expectations prevent a 5.

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

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

The single parameter 'domain' has 100% schema description coverage, providing clear meaning ('The domain name to perform a full DNSSEC audit on'). The description does not add additional parameter-level semantics beyond what the schema already states, so the baseline score of 3 applies.

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

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

The description states a specific verb ('runs') and resource ('all 7 DNSSEC checks') and enumerates each check, making it clear this is the comprehensive audit tool. It distinctively differentiates from sibling tools like dnssec_check_ds or dnssec_check_rrsig by explicitly covering all checks in one operation.

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

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

The description clearly implies when to use this tool: when a full, comprehensive DNSSEC audit is needed rather than individual checks. The phrase 'all 7 DNSSEC checks' and 'comprehensive' provides clear context, though it does not explicitly name alternatives or state 'use this instead of individual dnssec_check_* tools.'

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

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

With no annotations, the description carries the full transparency burden. It reveals specific detection logic (multiple DNSKEYs, rollover methods, DS matching), which goes beyond the tool name. However, it does not disclose whether this is a read-only operation or if it requires any special access, though the nature of a DNS check implies read-only.

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

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

Three concise sentences that front-load the purpose, then detail detection logic in under 30 words. Every sentence adds information.

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

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

The description explains the tool's core purpose and what it reports (rollover method, DS mismatch condition), which partially compensates for the lack of an output schema. However, it does not detail the exact return format or include context on when rollover detection is relevant, leaving some 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% for the single 'domain' parameter, which the schema already describes clearly. The description adds no 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?

The description clearly states the purpose: checking for DNSSEC key rollover. It differentiates from sibling DNSSEC tools by focusing specifically on rollover detection and classification, with explicit behaviors like detecting multiple DNSKEYs and flagging DS mismatches.

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 DNSSEC key rollover but provides no explicit guidance on when to use this tool versus sibling DNSSEC tools like dnssec_validate or dnssec_check_dnskey. No alternatives or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool queries DNSKEY, DS, and RRSIG records at each level and reports one of three outcomes. This provides meaningful insight into the tool's operation and output, though it does not explicitly state that it is read-only or mention any prerequisites or limitations.

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

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

The description is two sentences, front-loaded with the core action, and contains no unnecessary filler. Every clause adds value, making it exceptionally concise 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?

The tool has moderate complexity with no output schema, but the description covers the key aspects: what is validated, the record types involved, and possible outcomes. It does not detail the output format or edge cases, but for a validation tool with a simple status result, this is reasonably complete.

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

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

Schema coverage is 100% for the only parameter (domain), and the schema already describes it well. The description does not add any additional parameter-level details, so the baseline score of 3 applies. No extra value is added 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's purpose: full DNSSEC chain of trust validation from root to TLD to domain. It specifies the resources queried (DNSKEY, DS, RRSIG) and the output (valid, broken, or not signed). This distinguishes it from sibling tools like dnssec_check_ds or dnssec_check_dnskey, which only validate 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 implies when to use this tool (for full chain validation) but does not explicitly contrast it with alternative sibling tools such as dnssec_full_audit or dnssec_check_*. There is no 'when-not' guidance or explicit recommendation for other tools, so the usage context is clear but not fully differentiated.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly describes the queries made (CHAOS class TXT records) and what information can be revealed, which is transparent about the operation. However, it does not mention potential side effects, such as the target server logging or blocking such queries, or the possibility that some servers return empty results. This is a minor gap but does not contradict the behavior described.

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

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

The description is two sentences long, with no wasted words. The first sentence states the action and method, and the second provides illustrative context about what can be discovered. It is front-loaded and concise, covering all essential aspects without unnecessary detail.

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 tool with one parameter and no output schema, the description is fairly complete: it explains the purpose, method, and expected outcome. It is missing a note about limitations, such as servers that do not support CHAOS queries or may return no records. However, given the low complexity, the description is sufficient for an agent to understand what the tool does and when to use it.

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

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

The input schema already fully describes the single parameter 'nameserver' with an example ('8.8.8.8'). The description adds no new meaning beyond what the schema provides, so the baseline score of 3 is appropriate. It does not need to compensate for missing schema information.

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

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

The description clearly states a specific verb ('Fingerprint') and resource ('a DNS server'), and further specifies the method (querying CHAOS class TXT records) and the exact record names (version.bind, version.server, etc.). It distinguishes itself from sibling DNS tools like dns_lookup or dns_reverse by focusing on software/version identification rather than general DNS resolution.

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

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

The description gives a clear context for when to use the tool: when you need to identify the DNS software type and version. It does not explicitly mention alternatives or exclusions, but the specific technique (CHAOS class TXT records) implies a narrow use case, making it easy for an agent to select this tool over more generic DNS query 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?

Without annotations, the description carries the burden of explaining behavior. It explains the methodology (comparing external and optional internal resolvers) but does not disclose potential side effects, network usage, or requirements such as internet access or rate limits. It also doesn't state whether the operation is read-only, though 'Detect' implies non-intrusive 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, with the first sentence delivering the core purpose and method, and the second providing a brief explanation of split-horizon DNS. Every word earns its place, making it concise 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?

The tool is relatively simple with two parameters and no output schema. The description explains the purpose and method but does not mention what the tool returns (e.g., a boolean, a report, raw responses) or any edge cases like an unreachable internal_resolver. For a detection tool, this lack of output and error context leaves some 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 already provides detailed descriptions for both parameters (domain and internal_resolver), with 100% schema coverage. The description adds a little context by explaining the role of the internal resolver in the comparison, but it does not significantly enhance the schema's parameter semantics.

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

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

The description clearly states the tool's purpose: 'Detect split-horizon (split-brain) DNS configurations by comparing responses from multiple external resolvers and an optional internal resolver.' This is a specific verb ('Detect') with a specific resource ('split-horizon DNS configurations') and a distinct method, setting it apart from sibling tools like dns_lookup or dns_reverse.

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

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

The description clearly implies when to use the tool (when split-horizon DNS is suspected) and provides context on how it works. It does not explicitly name alternatives or exclusions, but the scope is specific enough that an agent can infer appropriate use compared to other DNS-focused 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?

With no annotations available, the description carries the full burden. It discloses meaningful behavioral traits: the use of crt.sh for passive CT lookups, active DNS brute-force, result deduplication, and resolution of discovered subdomains to IP addresses. It does not mention potential rate limits, time costs, or failure modes, but it covers the core behavior 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 two sentences, front-loaded with the core action and purpose. Every sentence earns its place: the first defines the methods, the second adds deduplication and resolution behavior. No filler or redundancy.

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

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

Given no output schema and no annotations, the description does a solid job: it explains what the tool does, how it works, and implies the return value (subdomains with IP addresses). It could additionally mention default limits or error behavior, but for a subdomain enumeration tool with well-documented parameters, this is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds some context by connecting CT lookups to the use_ct parameter and brute-force to the wordlist parameter, but it does not provide additional detail beyond the schema for limit or domain. Overall, it complements the schema without adding significant new semantic depth.

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 'Enumerate subdomains' and clearly identifies the resource (subdomains of a target domain). It distinguishes this tool from siblings like 'dns_lookup' or 'ct_search' by explicitly stating the combined passive CT and active brute-force approach, along with deduplication and IP resolution.

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?

Although it does not explicitly name alternatives or state when-not-to-use, the description provides clear context: it is for subdomain enumeration using both passive CT and active brute-force. This is enough for an agent to infer when to choose this tool over simpler lookup tools, but it lacks explicit exclusions or 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the specific thresholds (<60s, >86400s) and their security/operational implications, which goes beyond a vague 'analyze' statement. It does not mention side effects (e.g., network queries) or return format, but it does reveal the analytical criteria and outcomes.

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

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

The description is two sentences, with the first stating the core purpose and the second listing the specific flags and rationale. Every sentence contributes meaningful information without redundancy or excess length, making it highly 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?

Given the tool's simplicity (one parameter, no output schema), the description adequately explains what the tool analyzes and what it flags, which is sufficient for an agent to select and invoke it. It does not describe the exact output structure, but the absence of an output schema and the clear criteria make this a minor gap rather than a critical omission.

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

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

The schema description covers the single parameter 'domain' fully, providing an example and type, so the baseline is 3. The description adds no additional semantic value beyond reiterating 'for a domain', so it neither enhances nor detracts from what the schema already provides.

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

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

The description clearly states the tool analyzes DNS TTL values across all record types for a domain, using a specific verb ('Analyze') and identifying the resource and scope. It also distinguishes itself by focusing specifically on TTL security and operational issues, which separates it from other DNS-related sibling tools like dns_lookup or dns_cache_snoop.

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

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

The description provides clear context on when to use this tool—to identify fast-flux indicators, stale cache risks, and inconsistent TTLs—making the intended use case evident. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough for an agent to select it appropriately.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the detection methodology (resolving random subdomains and comparing IPs) and the interpretation of results. It does not mention potential rate limiting or query volume, but the behavior is straightforward and read-only.

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

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

The description is three sentences, front-loaded with the action and method, with no redundant details. Every sentence contributes to understanding the tool's purpose, behavior, and relevance.

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 low complexity (two simple params), the description covers the action, method, and why it matters. No output schema exists, so return-value details would be helpful, but the description sufficiently enables correct selection and invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context about random names but does not elaborate on parameter syntax or edge cases beyond what the schema already provides, such as the default for 'samples' and the example for 'domain'.

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: 'Detect wildcard DNS configurations by resolving multiple random non-existent subdomains.' It uses a specific verb ('Detect') and resource ('wildcard DNS configurations') and explains the method, distinguishing it from siblings like dns_subdomain_enum or ct_wildcard_audit.

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

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

The description notes that 'Wildcard DNS can affect subdomain enumeration accuracy and security assessments,' which implies when this tool is valuable. However, it does not explicitly name alternative tools or provide exclusions, so usage guidance is clear but not fully explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the network protocol (TCP), the action (AXFR attempt), the outcome if successful ('all DNS records in the zone are returned'), and the security significance. However, it does not explain what happens when the transfer is refused (e.g., error or empty response), leaving some behavioral ambiguity.

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

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

The description is two sentences, front-loaded with the action and followed by impact. Every word earns its place, with no redundancy or irrelevant details.

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

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

Given the tool's simplicity (2 parameters, no output schema), the description covers its purpose, method, and outcome. It briefly describes return content ('all DNS records') but lacks explicit failure-mode behavior, which would make it fully complete for an agent.

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

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

Schema description coverage is 100% for both parameters, with clear descriptions for 'domain' and 'nameserver'. The tool description adds minimal extra semantic value beyond the schema, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's action: 'Attempt an AXFR (full zone transfer) against a domain's nameserver via TCP.' This specific verb and resource clearly distinguish it from other DNS tools like dns_lookup or infra_axfr_protection, which have different purposes.

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

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

The description provides clear context that this is a security assessment tool by stating 'An open zone transfer is a critical security misconfiguration.' It implies when to use it (to check for misconfigured nameservers) but does not explicitly mention alternatives or when-not-to-use cases, which prevents a perfect score.

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

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

With no annotations, the description carries the full burden. It discloses the data source (RDAP creation date) and the classification logic, which is useful. However, it does not mention potential failure modes (e.g., RDAP unavailability), output format, or network dependencies, so transparency is partial.

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 and highly information-dense. It front-loads the core action and includes classification thresholds without any fluff or repetition.

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

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

For a simple one-parameter tool, the description covers the main purpose and classification details. It lacks explicit return value information and edge-case handling, but the simplicity of the tool makes the description nearly complete. No output schema exists, so a bit more detail on outputs would improve completeness.

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

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

The schema already documents the single 'domain' parameter with 100% coverage, so the baseline is 3. The description adds context about RDAP methodology but does not introduce new 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?

The description clearly states the tool determines domain age via RDAP creation date and provides specific classification thresholds (<30 days suspicious, <90 days young, >365 days established). This is a specific verb+resource with distinct classification logic, distinguishing it from sibling tools like domain_whois or domain_newly_registered.

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 classification into suspicious/young/established implies usage for domain risk assessment, but the description does not explicitly state when to use this tool versus alternatives (e.g., domain_newly_registered, domain_whois). There are no exclusions or alternative references, so the guidance is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states what is evaluated (five specific characteristics) and what will be returned (a per-domain DGA probability score). It does not disclose potential side effects or error behavior, but this appears to be a pure analysis tool with no side effects, so the transparency is strong.

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

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

The description is two well-structured sentences. It front-loads the core purpose in the first sentence and adds meaningful technical detail in the second. There is no fluff or redundancy, and 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 low complexity (one parameter, no output schema, no annotations), the description is mostly complete. It explains the input and the output format. It lacks details on the score range or interpretation, but for a straightforward analysis tool with a simple input, this is sufficient. A score of 5 would require more context on expected output semantics or edge cases.

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% (one parameter, 'domains', described as 'List of domain names to analyze for DGA characteristics'). The description adds detail about the analysis methodology but not about input formatting (e.g., whether to include subdomains, protocol, or punycode). Since the schema already documents the parameter, a baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Analyze') and resource ('domains') with a clear goal (DGA characteristics). It lists concrete features (consonant ratio, bigram frequency, Shannon entropy, length, pronounceability) and states the output (per-domain DGA probability score), distinguishing it from sibling domain tools like domain_reputation or typo_soundsquat.

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

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

Usage context is implied: an agent would naturally select this tool when DGA detection is needed. However, there is no explicit guidance on when to use it over alternatives, no exclusions, and no mention of complementary tools. This is adequate but lacks the explicit 'when/when-not' that would earn a higher score.

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?

No annotations are provided, so the description carries the transparency burden. It communicates read-only behavior through 'assess', 'checks', and 'flags', and discloses exact thresholds and the transfer lock check. It omits error/edge-case behavior, but for a simple single-parameter read-only tool this is sufficient.

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

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

Three short sentences, each with a distinct purpose: core action, checks performed, and threshold logic. It is front-loaded, non-redundant, and free of filler.

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

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

For a tool with one parameter and no output schema, the description covers the essential aspects: what is assessed, via which method, and what risk categories are returned. It does not describe output structure, but the flag categories imply the return semantics adequately.

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

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

The schema already fully describes the only parameter 'domain' with an example, achieving 100% coverage. The description does not add additional parameter-level details, so the schema-coverage 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 opens with a specific verb ('Assess'), names the resource ('domain expiry risk'), and specifies the method ('via RDAP'). It distinguishes itself from sibling tools like domain_whois by clearly focusing on risk classification with thresholds rather than raw data.

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 context is clear: use this tool when you need to evaluate domain expiry risk. It does not explicitly mention alternatives or when-not-to-use, but the operational thresholds ('critical <30 days', 'warning <90 days') make the intended use obvious.

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

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

With no annotations, the description must carry the behavioral disclosure burden. It states the source (RDAP) and return type (timeline of events), but lacks detail on authentication needs, caching behavior, rate limits, or failure modes. Adequate for a simple read operation but not rich.

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

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

Two sentences, front-loaded with the core purpose, and no filler. 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?

Low complexity (1 param, no nested objects, no output schema) means modest requirements. The description explains the return value type (timeline) and enumerates event categories, which is sufficient. Minor gap: the exact structure of the 'timeline' is unspecified, but acceptable for a simple 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 a clear description for the single 'domain' parameter, including an example. The tool description adds no additional parameter context beyond the schema, so baseline 3 applies.

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

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

Specific verb+resource: 'Retrieve domain event history from RDAP' clearly states the action and data source. It distinguishes from siblings like domain_whois and domain_age by focusing on a timeline of events (registration, expiration, last changed, transfer) rather than current state or single attributes.

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

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

Usage context is implied by the name and description (use when you need event history), but no explicit when-to-use or alternatives are provided. It doesn't mention when to prefer this over domain_whois or domain_age, nor any 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?

No annotations are present, so the description carries full burden. It transparently discloses the method (resolves A record, performs reverse DNS, queries Team Cymru DNS) and the returned fields. However, it lacks caveats about error cases, timeouts, or rate limits, which prevents a 5.

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

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

The description is three sentences with no redundancy: purpose first, followed by method, then outputs. Every sentence earns its place and is immediately informative.

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 single parameter, no output schema, and no annotations, the description adequately covers the tool's behavior and return values. It lists all key outputs (IP, ASN, AS name, prefix, hosting provider) but omits potential error conditions or edge cases like NXDOMAIN.

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 a clear description for the 'domain' parameter. The tool description adds no extra semantic detail 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?

Description states a specific verb ('Get') and resource ('hosting infrastructure details for a domain') with concrete outputs (IP, ASN, AS name, prefix, provider). This clearly distinguishes it from sibling domain_* tools like domain_whois or domain_reputation, which focus on other 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 implies usage when hosting infrastructure details are needed but does not explicitly state when to prefer this over alternatives like dns_lookup or dns_reverse. There is no mention of exclusions or when-not-to-use.

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

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

No annotations are provided, so the description carries the full burden. It discloses the data source (CT logs) and the return type (domains with certificate issuance dates). However, it does not clarify that 'newly registered' is an inference from certificate issuance rather than actual WHOIS registration data, nor does it mention limitations such as CT log coverage or the default lookback period (though 'days' is in the schema). This is adequate but not deeply 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?

The description is exactly two sentences, front-loaded with the core action and purpose. No wasted words; every clause contributes meaning. It is appropriately concise for a tool of this simplicity.

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

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

For a simple 2-parameter tool with no output schema and no annotations, the description covers the essential purpose, methodology, and return value. It lacks explicit distinction from CT-related siblings (e.g., ct_search) and could clarify the 'newly registered' heuristic, but overall it is sufficiently complete for an agent to understand what the tool does and what it returns.

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%: both 'pattern' and 'days' have descriptive text in the input schema. The description adds little beyond the schema, only loosely referencing 'pattern' via 'matching a pattern' and 'recently issued' aligning with 'days'. Since the schema already fully documents parameters, 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 states a specific verb ('Search'), a resource ('CT logs'), and a clear objective ('discover newly registered domains'), which distinguishes it from sibling tools like ct_search that may also search CT logs but not specifically for newly registered domains. It also mentions the output ('Returns domains with certificate issuance dates'), making the purpose unambiguous.

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

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

The description implies the use case: when you want to discover newly registered domains via CT logs. However, it does not explicitly state when to use this tool instead of alternatives like ct_search, domain_age, or domain_whois, nor does it provide exclusions. The 'to discover newly registered domains' part gives some context but no explicit 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?

With no annotations provided, the description carries the burden of disclosure. It transparently outlines the method: resolves A record, fetches the page, and fingerprints for known parking services. This goes beyond the tool's name, though it omits potential costs like network latency or return format.

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

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

The description is two sentences with no redundancy. The first sentence states the purpose, the second explains the mechanism. 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?

For a simple one-parameter tool without an output schema, the description adequately explains what the tool does and how. It could be more complete by describing the return value or edge cases, but the core context is sufficiently 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?

The schema already provides 100% coverage for the single 'domain' parameter with a clear description and example. The tool description adds no new parameter-specific meaning beyond what the schema already offers, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Detect if a domain is a parked/for-sale page.' It clearly distinguishes this tool from siblings like domain_whois or domain_history by focusing on parking detection and enumerating known services.

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

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

The description implies the tool is for assessing whether a domain is parked/for-sale, but it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. Context is clear but not fully elaborated.

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?

No annotations are provided, so the description carries the full burden. It discloses the read-only nature and specific data sources, but does not mention output format, potential latency, or rate limits. This provides basic transparency but lacks depth.

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

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

The description is two sentences with no fluff. It front-loads the action and each sentence adds relevant information: what it does and what it returns.

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

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

For a simple single-parameter tool, the description sufficiently covers purpose and return type. It lacks details on output size or sorting, but these are not critical for basic usage, making the tool adequately complete.

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

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

Schema coverage is 100% and the parameter 'domain' has a clear description in the schema itself. The tool description adds no additional meaning beyond the schema, so the baseline 3 is appropriate.

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

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

The description uses the specific verb 'Find' and clearly defines the resource: domains related through shared infrastructure. It enumerates four distinct discovery methods (nameservers, MX, reverse DNS, CT logs), which distinguishes it from sibling tools like domain_whois that focus on single-domain details.

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

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

The description implies when to use the tool: when you need to discover domains sharing infrastructure with a given domain. It does not explicitly mention alternatives or exclusions, but the context is clear from the description and sibling tool names.

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

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

With no annotations, the description carries the burden of disclosing behavior. It states that the tool queries DNS blocklists, checks CT logs, and evaluates domain age, and returns a composite score. This is a good disclosure of the main operations, but it lacks details on potential limitations like rate limits or external service dependencies.

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 that front-load the core purpose ('Multi-source domain reputation check'), then enumerate the data sources, and finally state the output. Every sentence adds value without redundancy.

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

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

Given no output schema, the description appropriately notes that a 'composite reputation score' is returned, but it does not explain how the score is computed or what the range/meaning is. However, for a single-parameter tool with a well-defined purpose, the description is largely 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?

The schema fully describes the single 'domain' parameter with 100% coverage. The description does not add any additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Multi-source domain reputation check.' It specifies the verb 'check' and the resource 'domain reputation,' and lists the specific sources (DNS blocklists, CT logs, domain age) that distinguish it from single-source siblings like bl_check_dnsbl or domain_age.

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 this tool is for a comprehensive reputation assessment, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. There is no mention of when a single-source check would be preferable or when this tool is not appropriate.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It does indicate a read-only operation via 'Query' and lists return fields, but it does not disclose error behavior, availability limitations (e.g., RDAP not supported for all TLDs), or any access requirements. This is adequate but not rich.

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

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

The description is two sentences long, front-loaded with the primary action, and contains no filler. Every phrase adds value: method (Query), protocol (RDAP), object (domain WHOIS), and return contents.

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 (one parameter, no output schema, no annotations), the description provides a reasonable overview by listing the key returned data categories. It does not explain the return format or error cases, but for a basic lookup 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?

Schema description coverage is 100% for the sole parameter 'domain', which is already well-documented in the input schema. The description adds no additional meaning about the parameter, so the baseline of 3 applies.

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

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

The description clearly states the verb 'Query' and the resource 'RDAP for domain WHOIS information', and lists specific return fields (registrar, registration dates, nameservers, status codes). This distinguishes it from sibling tools like domain_age or domain_history, which analyze the same underlying data for different purposes.

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 raw WHOIS data is needed, but it does not explicitly state when to use this tool versus siblings such as domain_age or domain_expiry_risk. No alternatives are mentioned, so the guidance is only 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?

With no annotations provided, the description carries the full burden. It discloses that it validates the presence of specific BIMI fields, adding useful context over the name. However, it does not explain what the tool returns, whether it performs a DNS query, checks syntax validity, or verifies URL accessibility, leaving room for behavioral ambiguity.

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 followed by specific validation details. Every word is necessary; no fluff or tangential information.

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

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

The tool is simple (one parameter, no output schema). The description states what it validates but omits any detail about the return format or potential error conditions. Given the lack of annotations and output schema, the description is adequate but not fully complete, as users are left guessing what 'validates' actually yields.

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 a clear parameter description ('The domain to check BIMI records for'), and the tool description merely repeats 'domain' without adding new semantic detail. This meets the baseline expected for high schema coverage but does not enhance meaning.

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

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

The description uses a specific verb ('Check') and resource ('BIMI record for a domain'), and also lists the exact validation criteria (v=BIMI1, l=, a=). This clearly distinguishes it from siblings like email_check_spf and dns_lookup.

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

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

The description clearly implies when to use the tool (when checking a domain's BIMI record) but does not provide explicit comparisons or exclusions relative to other email-related checks. Since siblings include many similar email_check_* tools, some explicit guidance would help, but the specificity of the purpose makes it easy to infer.

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

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

With no annotations, the description carries the full burden. It discloses the tool's behavior in detail: resolves MX records, performs raw DNS queries to _25._tcp.<mx-host>, reports certificate usage/selector/matching type, and flags missing TLSA or DANE-without-DNSSEC. This provides solid transparency beyond the basic input schema, though it does not explicitly note read-only behavior or potential failure modes.

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

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

The description is four sentences long, each adding essential information: purpose, method, outputs, and special flags. There is no redundancy or filler. It is well-structured, starting with the high-level purpose and then detailing the process.

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 (a DNS query for TLSA records) and lack of output schema, the description sufficiently covers what the tool does and what it returns. It explains the query target, the resolved data, and the edge-case flags (missing TLSA, DANE without DNSSEC), making it complete for an agent to select and invoke correctly.

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

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

Schema coverage is 100% (the 'domain' parameter has a description). The tool description adds value by explaining that the domain is used to obtain MX hosts, which is not fully explicit in the schema. This clarifies how the parameter is interpreted and used.

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: 'Check DANE/TLSA records for a domain's MX hosts.' It uses a specific verb ('Check') and resource ('DANE/TLSA records'), differentiates from sibling tools (e.g., email_check_spf, email_check_dkim) by focusing on DANE/TLSA, and even details the process of resolving MX records and querying TLSA.

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

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

The description implicitly conveys when to use this tool (when checking DANE/TLSA for a domain's MX hosts) but does not explicitly mention alternatives or exclusions. No 'use instead' recommendations are given, but the clarity of the purpose makes the usage context obvious. It lacks explicit when-not-to-use guidance, so not a 5.

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

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

With no annotations, the description carries the transparency burden. It discloses detailed behavioral aspects: parsing key type, estimating RSA key size, and flagging weak keys, testing mode, and revoked keys. It does not explicitly state read-only behavior or network/rate-limit impacts, but the described checks imply non-mutating actions.

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

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

Two sentences, front-loaded with the primary action, and every sentence adds value. There is no redundant information or fluff.

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

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

The description covers key behavioral outcomes (weak keys, testing mode, revoked keys) and the probing of selectors. However, without an output schema or annotations, it omits details about the exact return format and error handling, which would make it fully complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context about probing common selectors but does not add new parameter-specific semantics beyond what the schema already provides for domain and selectors.

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 'DKIM records' for a domain, along with the method of probing common selectors. It effectively distinguishes itself from sibling email_* tools by naming the specific record type and parsing activities.

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 DKIM checking but provides no explicit guidance on when to use this tool versus alternatives like email_check_spf or email_check_dmarc. The context is clear from the name and description, but no exclusions or alternatives are mentioned.

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

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

With no annotations, the description carries the full transparency burden. It discloses analytical behavior by listing the specific tags it parses and the conditions it flags, giving the agent insight into what the check evaluates. However, it does not describe the return format or the behavior for domains with no DMARC record, which is a minor gap.

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

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

The description is exactly two sentences: first states the action, second adds precise technical scope. No filler or redundancy; every word contributes to understanding.

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

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

The tool is simple (one parameter, no output schema), and the description covers the core behavior: parsing specific tags and flagging weaknesses. It does not explicitly define the return structure, but the parsing/flagging list makes the output inferable. Missing edge-case behavior (e.g., no record found) is a minor gap.

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

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

The input schema has 100% coverage for the single 'domain' parameter with a clear description and example. The tool description adds no further semantic detail beyond stating 'for a domain,' so it does not improve upon the schema. Baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Check DMARC record for a domain.' It then enumerates the exact DMARC tags parsed (p=, sp=, pct=, rua/ruf, aspf/adkim) and the flags raised (p=none, missing reporting, relaxed alignment), which clearly distinguishes it from sibling SPF/DKIM checks.

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 DMARC validation (e.g., when a domain's email authentication policy needs assessment) but provides no explicit guidance on when to prefer this over alternatives like email_check_spf or email_check_dkim, nor any exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden. It transparently lists the steps (DNS query, HTTPS fetch, parsing) and the specific flags it produces (testing mode, short max_age, missing policy files). This gives a clear picture of the tool's behavior, though it does not describe auth requirements or rate limits, which are unlikely to be relevant for a read-only check.

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

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

The description is three sentences, each serving a clear purpose: stating the function, outlining the process, and listing the parsed/flags fields. It is front-loaded and concise with no redundant words or fluff.

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

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

The description thoroughly covers the tool's multi-step process and the types of output (mode, MX, max_age, flags). While there is no output schema, the description gives a strong sense of what the tool returns. It does not specify the exact output format, but this is a minor gap for a check tool.

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

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

The schema description coverage is 100% for the single 'domain' parameter. The description adds no additional semantic detail beyond what the schema already provides, so the baseline of 3 applies. The description merely echoes the schema by mentioning 'for a domain'.

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 for a domain, specifying the exact resource and action. It also details the steps (querying TXT record, fetching policy file, parsing fields), which distinguishes it from sibling email tools like email_check_spf or email_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 by its focus on MTA-STS checking, but it does not explicitly mention when to use this tool versus alternatives (e.g., other email security checks). No exclusions or alternative tool references are provided, so the usage context is only inferred.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently details the internal resolution chain (MX -> IP -> PTR -> forward A), verifies IP matching, and states exactly what is flagged (missing PTR, FCrDNS mismatches). It does not mention edge cases like absent MX records or multiple MX hosts, resulting in a minor gap.

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

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

The description is two sentences long, front-loaded with the core purpose, then supported by the detailed resolution method and the practical consequence. Every sentence provides value and there is no redundancy or filler.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is highly complete. It explains the purpose, the step-by-step methodology, the verification logic, and the failure scenario, leaving little ambiguity about what the tool does and why an agent would 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 baseline is 3. The description adds meaning by clarifying that the 'domain' parameter is used to resolve its MX hosts first, not just the domain itself. This is a useful semantic addition beyond the schema's generic 'domain to check' phrasing.

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

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

The description clearly states a specific verb ('Check'), the resource ('PTR and FCrDNS for a domain's MX hosts'), and the exact verification logic (MX -> IP -> PTR -> forward A). This distinguishes it from sibling tools like email_check_spf or dns_reverse by focusing specifically on MX host reverse DNS validation.

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

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

The description implies the use case by noting that missing PTR records and FCrDNS mismatches 'can cause mail delivery failures', giving clear context for when this tool is relevant. However, it does not explicitly name alternatives or provide exclusion criteria, so it stops short of a full 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds substantial detail: parses mechanisms/qualifiers, follows include chains, counts DNS lookups against RFC 7208 max 10, and flags specific misconfigurations. This goes beyond simply fetching a record, though it doesn't discuss error handling or exact return format.

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 each detail (mechanisms, include chains, DNS lookup counting, misconfiguration flags) is relevant and non-redundant. No filler words or repetition of the tool name.

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

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

Given the lack of an output schema and the tool's moderate complexity, the description explains the main capabilities well (parser, lookup counting, misconfiguration detection). It omits explicit return structure or edge-case behavior (e.g., no SPF record), but the description is sufficient for an agent to understand what the tool does and invoke it correctly.

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

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

Schema coverage is 100%: the only parameter 'domain' is described as 'The domain to check SPF records for (e.g. example.com)'. The description adds no new semantic information about the parameter 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 checks SPF records for a domain, with a specific verb ('Check') and resource ('SPF record'). It distinguishes from sibling email tools like email_check_dkim and email_check_dmarc by explicitly naming SPF and listing detailed analysis behaviors (parses mechanisms, follows include chains, counts DNS lookups).

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 context is clear: use this tool to check SPF configurations for a domain. However, it does not explicitly mention alternatives or exclusions, such as when to use email_spf_enumerate or other email check tools instead. Despite that, the operational details imply a focused use case, making it easy for an agent to select.

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

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

With no annotations provided, the description carries the full burden. It discloses what the tool does (runs multiple checks, calculates a spoofability score, groups results by severity) and gives a clear sense of its read-only audit nature, though it does not explicitly state safety/side-effect details such as network usage or non-mutating 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-loaded with the primary action, and every phrase adds value (scope, specific checks, output format). No wasted 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 tool's complexity (many checks) and the absence of an output schema, the description adequately explains the return format (single report grouped by severity). It covers the key aspects, though it could add caveats like time/resource usage, but it remains highly complete for practical use.

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

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

Schema description coverage is 100% for the single 'domain' parameter, which already explains its purpose and format. The description merely repeats 'for a domain' without adding new semantic details, so the baseline of 3 applies.

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

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

The description clearly states the tool runs a comprehensive email security audit for a domain, listing specific protocols checked (SPF, DKIM, DMARC, etc.) and the output report. This specific verb+resource clearly distinguishes it from sibling tools like email_check_spf or email_spoofability_score.

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

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

The description implies the tool is for a full, all-in-one audit versus individual checks, and mentions aggregation into a single report, which gives clear context. However, it does not explicitly mention alternatives or exclusions (e.g., when to use individual email_check_* tools), so it stops short of a 5.

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

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

The description discloses the recursive traversal behavior and the output content (IPs, CIDR ranges), which is valuable. However, with no annotations, it does not explicitly state that the tool is read-only or describe potential side effects like DNS query load, leaving the safety profile incomplete.

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 the main action front-loaded and the second sentence adding value about the tool's purpose and insights. No redundant words 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 no output schema, the description adequately conveys what the tool returns ('IP addresses and CIDR ranges') and the kind of infrastructure revealed. It does not cover edge cases, but for a simple two-parameter tool, this is sufficient.

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

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

Both parameters (domain and max_depth) are fully described in the input schema with 100% coverage. The description adds no additional parameter-level semantics, so it meets the baseline but does not exceed it.

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

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

The description uses a specific verb ('recursively walk') and resource ('SPF include chain'), clearly stating the tool's action: extract all authorized IP addresses and CIDR ranges. It distinguishes from sibling tools like email_check_spf by emphasizing deep enumeration, not just checking SPF presence.

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 it is 'useful for attack surface mapping and infrastructure reconnaissance', giving clear context for when to use it. It does not name alternative tools, but this use case helps an agent decide among the many DNS/email siblings.

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

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

With no annotations, the description carries the full burden. It discloses the output (score, verdict, per-check breakdown) but does not mention whether the tool performs live DNS lookups, whether it is read-only, or any potential side effects. For a 'calculate' tool, the output description adds some transparency, but key behavioral traits are unaddressed.

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 efficiently states the purpose, output format, and scope. Every word contributes value, with no redundancy or filler.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately covers the return values and scoring basis. The 'per-check breakdown' is slightly vague, but the SPF/DKIM/DMARC context makes it understandable. It is nearly complete for an agent to invoke and interpret 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?

The schema already provides 100% coverage for the single 'domain' parameter, including an example. The description merely repeats 'for a domain' but adds no new semantic detail beyond the schema. Baseline of 3 applies because the schema does the heavy lifting.

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

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

The description clearly states 'Calculate an email spoofability score (0-100) for a domain based on SPF, DKIM, and DMARC configuration.' This is a specific verb plus resource and scope, and it clearly distinguishes from sibling tools like email_check_spf, email_check_dkim, email_check_dmarc, which focus on individual record checks rather than a composite score.

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 a composite spoofability score is needed—but does not explicitly state when to prefer this tool over alternatives or when not to use it. No exclusions or alternative tool mentions are provided, so the guidance is only 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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It discloses that it queries an external DNS interface, which implies a network read operation, but it does not explicitly state that it is non-destructive, mention rate limits, or describe potential failure modes. This is adequate but lacks richer detail.

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 and around 40 words, front-loading the core purpose and method. Every sentence contributes meaningful information without redundancy or fluff.

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

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

For a simple one-parameter tool with no output schema, the description covers the tool's purpose, data source, and what it reports (ASN, prefix, owner, RPKI/ROA notes). It lacks explicit output format details, but the description is otherwise sufficient for an agent to understand what the tool does and roughly what it returns.

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

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

Schema description coverage is 100% for the single 'domain' parameter, and the schema already explains its meaning. The tool description adds little beyond restating the domain's role in BGP impact assessment, so it does not significantly exceed what structured data already provides.

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

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

The description uses a specific verb ('Assess') and resource ('BGP-level impact of domain hijacking') and names the data source (Team Cymru's DNS interface). It clearly distinguishes itself from sibling hijack tools, which focus on dangling records, NS delegation, or other aspects.

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

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

The description provides clear context: it is used for assessing BGP-level impact, focusing on ASN, prefix, and AS owner info. It does not explicitly mention when not to use it or list alternative tools, but the context is sufficiently distinct from the many 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?

With no annotations, the description carries the full burden of behavioral disclosure. It transparently explains the tool's stateful behavior: on first run it returns a JSON baseline, and on subsequent runs it diffs to detect added, removed, or changed records. This goes beyond basic purpose disclosure, though it does not address potential errors or edge cases like invalid baseline input.

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

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

The description is two concise sentences, front-loaded with the primary purpose and followed by the operational modes. Every clause adds value, with no filler or repetition of schema details.

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

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

The description is complete enough for a 2-parameter tool with no output schema. It explains the two distinct invocation scenarios and what output to expect (JSON baseline vs. diff). It could add more detail about error conditions or the exact diff format, but that is not essential for correct invocation.

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

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

Schema coverage is 100% with both parameters defined, but the description adds behavioral meaning beyond the schema. It clarifies that 'baseline' is a JSON string from a prior run and explains the consequence of omitting it (returns the current state as the initial baseline). This effectively compensates for any ambiguity in the raw schema.

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

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

The description clearly states the tool's purpose: 'Monitor DNS record changes by comparing current records against a stored baseline.' It uses specific verbs (monitor, compare) and identifies the resource (DNS records), distinguishing it from sibling tools like hijack_dangling_cname that focus on specific vulnerability 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 explains the two usage modes: first run (returns initial baseline) and subsequent runs (diffs against provided baseline). This provides clear context on how to invoke the tool correctly. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

No annotations are provided, so the description carries full behavioral disclosure burden. It describes the detection process (DNS resolution, NXDOMAIN/SERVFAIL check, HTTP confirmation) but omits potential side effects like network requests to third-party targets, rate limits, or safety implications. This is moderate transparency for a scanning tool.

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

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

The description is two sentences, with the first sentence stating the primary purpose and the second detailing the method. No redundant information, 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?

No output schema is present, and the description does not explain return format, result structure, or potential pitfalls. For a security scanning tool, this is a notable gap. However, the description provides a clear process overview, making it minimally adequate but not fully complete.

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

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

Schema description coverage is 100%, with both parameters (domain and subdomains) having clear descriptions. The tool description adds no new meaning beyond restating that it scans subdomains. Baseline 3 is appropriate since the schema already handles parameter documentation.

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 detects dangling CNAME records for subdomain takeover, using a specific verb ('Detect') and resource. This distinguishes it from siblings like hijack_dangling_ns and hijack_dangling_mx, which target other 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 implies usage for CNAME-specific takeover checks by mentioning 'Resolves CNAME for each subdomain.' While it doesn't explicitly mention alternatives, the context is clear and excludes other record types. No exclusions are stated, so it fits 'clear context, no 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the detection mechanism (NXDOMAIN check) and the consequence, which gives a transparent view of what the tool does internally. It doesn't cover return format or limitations, but the core behavior is well-described.

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

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

The description is two concise sentences that front-load the purpose and then provide context. Every word contributes value, with no redundancy or ambiguity.

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 a single parameter and no output schema, the description provides a clear understanding of the tool's purpose and detection logic. It lacks details about the output format or example results, but given the simplicity, it is reasonably complete and sufficient for an AI agent to select and invoke correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining what 'dangling' means in the context of MX records and how the domain parameter relates to the detection process. This supplements the schema's simple parameter description.

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 dangling MX records that could allow email hijacking, using the specific verb 'Detect' and identifying the resource (MX records). This distinguishes it from sibling tools like hijack_dangling_cname and hijack_dangling_ns.

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

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

The description explains the precise condition under which the tool is relevant: if an MX hostname resolves to NXDOMAIN, an attacker can register it. This gives clear context for when to use the tool, though it doesn't explicitly mention alternatives or exclusions. The condition implies the tool is for checking MX-specific dangling records.

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