dns-security-mcp

by badchars

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
The tool set uses clear category prefixes, but there are overlapping tools such as infra_open_resolver and dns_recursive_check (both test for open recursive resolvers), dns_server_fingerprint and infra_software_cve (both query version.bind), and hijack_subdomain_takeover/hijack_dangling_cname (CNAME takeover checks). Agents may struggle to pick the right tool among these near-duplicates.
Naming Consistency4/5
All 104 tools follow a consistent snake_case format with a category prefix (tunnel_, ct_, domain_, etc.), making it easy to identify the domain. Minor variation in verb choice (check, validate, audit, detect) exists, but the overall pattern is predictable and consistent.
Tool Count1/5
With 104 tools, this server is extremely over-scoped. The rule states that 50+ tools is an extreme mismatch, and this count would overwhelm any agent. The tools could be split into multiple focused servers by category (e.g., DNS, DNSSEC, email, typosquatting) to improve usability.
Completeness5/5
The tool set is remarkably comprehensive, covering DNS tunneling, CT logs, typosquatting, blocklists, infrastructure, privacy, threat intelligence, reporting, DNSSEC, email security, and hijacking. Full-scan and full-audit aggregators are present, leaving few obvious gaps for DNS security assessment.
Average 4/5 across 87 of 104 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, permissions, rate limits, or safety profile. It only describes the output format, which is behavioral but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with a clear structure: action, then format options. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the core function and output formats. However, given the many sibling report tools and lack of annotations, it could mention when to use it, but within its scope it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers both parameters, and the description adds meaning by explaining what each format yields (raw findings, severity headers, SARIF structure), exceeding the schema's minimal descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a full DNS security audit and produces output in specified formats, with a specific verb and resource. However, it does not distinguish from the sibling report_full_audit, so it's not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like report_full_audit or report_compare. The usage context is only implied by 'full DNS security audit'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states that the tool tests for unauthorized AXFR and explains the impact of a successful transfer, but it does not disclose key behavioral details: whether it sends an actual AXFR request, whether it only checks permissions, potential side effects, or any required permissions. The description is too shallow for a security tool that makes network requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, no redundant statement. Every word earns its place while conveying the critical risk. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two simple parameters and no output schema, the description is functional but leaves the expected return value unclear. An agent would not know if the tool returns a boolean, a summary, or a full zone transfer response. Given this is a security test, clarifying the output format is important. The description is adequate for basic invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described in the input schema (domain and nameserver). The description adds no additional parameter-level insights, which is acceptable given the high structural coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('Test if'), the resource ('DNS nameserver'), and the specific action ('allows unauthorized AXFR'). It distinguishes itself from siblings like dns_zone_transfer by emphasizing the security-testing angle of checking for unauthorized transfers. The consequence is also stated, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in a security assessment context but does not explicitly state when to use this tool over alternatives. No exclusions or alternative tool mentions are provided, leaving the decision to the agent based on the tool's name and the criticality narrative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 core behavior (DNS resolution and IP lookup) but omits safety aspects such as whether it is a read-only operation, potential network side effects, or limitations (e.g., unresolved domains). This is a minimal transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word contributes. It efficiently lists known operators without unnecessary fluff, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does state what is returned (whether sinkholed and which operator). However, it lacks details on the exact return format, behavior for unresolved domains, or error cases. For a simple one-parameter tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the 'domain' parameter with a clear description and example, achieving 100% coverage. The tool description does not add additional parameter nuances beyond stating the domain is what gets checked, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it resolves a domain and checks its IP against known sinkhole operators, then returns sinkhole status and operator. This specific verb+resource combination (resolve/check domain) distinguishes it from sibling threat detection tools like threat_c2_detect or threat_malicious_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a sinkhole check is needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. The context is clear but not directly compared to other threat-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose a key behavioral trait: 'Checks DNS registration for each variant,' implying a read-only network operation. However, it omits details such as output format, potential rate limits, or whether the tool returns resolved vs. available domains, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently conveys the core purpose and a key secondary action (DNS check), making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the generation method and DNS registration check, which is sufficient to understand the tool's role among many siblings. However, it lacks explicit detail about return values (e.g., does it return a list of registered domains or available ones?) and variant scope, which would make it fully complete for an agent without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'domain' parameter with 100% coverage, including an example. The description adds no extra parameter semantics beyond the implied 'domain variants' reference, so it does not exceed the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Generate' and clearly identifies the resource ('domain variants') with explicit techniques (confusable characters, Cyrillic lookalikes) and the DNS registration check. This distinguishes it from sibling tools like typo_soundsquat or typo_combosquat by naming the specific homoglyph method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus alternatives. The description is purely operational, stating what it does but not contrasting it with sibling homoglyph or typo tools (e.g., typo_idn_homograph, typo_keyboard_proximity). The agent must infer applicability from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must shoulder the burden. It discloses the specific checks performed and risk interpretation, but does not describe output format, whether it performs live DNS resolution, or any edge-case behavior, leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences: purpose, method, and risk meaning. Each sentence contributes essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 operation purpose and method, but omits any statement of what the tool returns (e.g., risk score, list of providers). This omission is significant because there is no output schema to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'domain', is already fully described in the schema with a placeholder example, achieving 100% coverage. The description adds no additional parameter-level semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Analyze nameserver diversity for a domain') and elaborates with three concrete checks (ASNs, /24 subnets, providers), which clearly distinguishes it from other infrastructure and DNS tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for assessing nameserver redundancy but does not explicitly state when to use it versus alternative tools, nor provide any exclusion criteria. The risk interpretation at the end offers context but not direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full responsibility. It discloses the method (querying third-party services) and the comparison logic, but it does not explicitly state that the tool is non-destructive or that it sends resolver IPs to external services, which is a notable privacy consideration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the tool's purpose, and contains no redundant words. Every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter, so the description covers the core functionality. However, without an output schema or annotations, it fails to explicitly describe the return format or what the output looks like (e.g., a list of resolvers, a boolean leak result). The hint about detecting leaks is present but not enough for a complete agent assessment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for 'expected_resolver', including a clear description, example, and behavior when omitted. The tool description adds no additional parameter semantics beyond referencing 'expected resolver' in the comparison context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: determining which DNS resolver(s) the system is using by querying services that reveal resolver IPs, then comparing against an expected resolver. This specific verb+resource structure distinguishes it from sibling tools like privacy_doh_test or privacy_dot_test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detecting DNS leaks or misconfigurations but does not explicitly mention when to use this vs. alternatives or when not to use it. Given the large number of privacy-related siblings, it would benefit from explicit guidance such as 'use this to verify VPN DNS routing' or 'for DoH-specific leaks, use privacy_doh_test'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It describes the multi-step process (resolve, PTR, CT search, flagging) which is transparent for a read-like analysis. However, it does not clarify whether any data is persisted (e.g., 'flags' might imply storage), nor does it address errors 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb 'Analyzes', no redundant details. Every clause adds meaningful information about the tool's process and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, the description should explain what the tool returns. It mentions 'Flags hosting with suspicious co-hosted domains' but does not specify the output format (e.g., list, score, boolean). The process is described well, but the return value is ambiguous, making it incomplete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for 'domain'. The tool description adds context by explaining how the domain is used (resolution, PTR, CT), but does not add new parameter-level information beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: analyzes domain co-hosting with specific techniques (IP resolution, PTR, CT logs) and flags suspicious co-hosted domains. This distinguishes it from siblings like dns_reverse or ct_search by combining these into a co-hosting analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for co-hosting investigation but does not explicitly state when to prefer this over alternatives like dns_reverse or threat_ip_to_domains. No exclusions or alternative tool mentions are provided, so 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only discloses the main algorithmic steps: bit-flipping, filtering to valid characters, and checking DNS registration. It omits behavioral details such as whether DNS checks are live, what the output format is, or any rate/network implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core operation, filtering, and DNS check. Every word earns its place, and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, this description is minimally adequate. However, it does not state what the returned value looks like (e.g., list of variants with registration status), nor does it explain the semantics of the DNS registration check in detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the domain parameter with 100% description coverage, so the tool description adds little beyond the schema. The description does not provide extra syntax, normalization rules, or edge-case handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation (generate single-bit-flip variants), the resource (domain name), and the distinguishing mechanism (bitsquat as opposed to homoglyph or combosquat sibling tools). This makes it easy for an agent to select it for bitsquat analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The mechanism is implied by the name and description, but sibling tools like typo_homoglyph or typo_combosquat are not mentioned, so an agent may not know when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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 checks performed but does not explicitly state read-only behavior, possible side effects (e.g., network requests), or error conditions. The absence of annotations makes this a partial disclosure, though the description gives meaningful detail about what is verified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that front-loads the main action and resource, then adds specific details about what is checked. Every word adds 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.
Completeness4/5
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, no output schema, and no annotations, the description is largely sufficient. It explains what the tool does, how it works (via RDAP), and what status codes it checks. It does not describe return values, but that is less critical given the simple scope and lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 well. The description adds no additional parameter semantics beyond what the schema provides (e.g., it does not explain domain formats or special cases). Baseline 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb+resource: 'Check domain registrar security posture via RDAP.' It explains exactly what it verifies (transfer locks, delete locks, registration expiry, EPP status codes) and distinguishes itself from sibling tools like hijack_dangling_cname and domain_whois by focusing on registrar-level protections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The implied usage is clear from the purpose—use it to assess registrar security—but there is no explicit guidance on when to choose this over alternatives from the many sibling tools. It does not mention exclusions or direct comparisons, so an agent lacks explicit decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal the query method (CHAOS version.bind TXT) and outcomes (identifies versions, maps to CVEs), but it does not disclose limitations such as failure when version.bind is disabled, output format, or potential rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action. Every word adds value, and there is no redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a clear schema and no output schema, the description covers purpose, method, and target software scope. It could be more complete by noting CHAOS query limitations or expected result shape, but it is sufficiently informative for an AI agent to invoke it appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 only restates the parameter's purpose ('DNS nameserver to fingerprint') without adding format details, constraints, or edge-case guidance beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Fingerprint DNS server software via CHAOS class version.bind TXT query and map to known CVEs.' It also lists the targeted software (BIND, PowerDNS, Unbound, NSD, Knot DNS), which clearly distinguishes it from the sibling tool dns_server_fingerprint by adding CVE mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. However, the description strongly implies usage for DNS software fingerprinting and CVE association. It does not mention the overlapping sibling tool dns_server_fingerprint or when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 return format ('Returns per-RFC pass/fail status') which is helpful, but it does not mention whether this performs DNS queries, potential side effects, or timeout behavior. The tool appears read-only, but that trait is not explicitly stated. The description adds moderate context beyond the schema but lacks richer behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose ('Tests domain DNS compliance') and efficiently lists RFCs and their checks. Every clause adds value, with no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description is thorough: it specifies which RFCs are tested and the return format. It does not explain how to interpret per-RFC results (e.g., severity), but for a tool of this simplicity the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the only parameter (domain) is 100%, with a clear description and example. The tool description does not add further parameter meaning beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Tests domain DNS compliance with key RFCs' and enumerates the specific RFCs and what each checks (RFC 1035, 4034, 6891, 7208, 7489). This goes beyond a generic verb and resource, providing a precise scope that distinguishes this aggregated compliance report from sibling tools like dnssec_validate or email_check_spf which target individual checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a multi-RFC compliance overview but does not explicitly state when to use this tool versus running individual checks like dnssec_validate or email_check_spf. No exclusions or alternative recommendations are given, so the guidance is inferred rather than direct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that DNS-based blocklists are checked via DNS lookups and HTTP-based feeds are checked over HTTP, and that the result includes feed hits and threat categories. However, it does not mention potential latency, network requirements, or that the operation is read-only. It is informative but leaves room for more transparency about side effects 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.
Conciseness5/5
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. It efficiently names the specific feeds and return type without unnecessary verbosity. The structure is clear and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple input (one domain) and lack of output schema, the description provides a high-level but sufficient account of what it does and returns ('feed hits and threat categories'). It could be more detailed about the format or absence of hits, but the combination of purpose, methods, and return value makes it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with a single parameter 'domain' that includes a description and example. The tool description does not add additional parameter semantics beyond restating that the tool checks a domain. Since the schema already fully documents the parameter, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Checks a domain against free threat intelligence feeds' and lists specific feeds (Spamhaus DBL, SURBL, URLhaus). The verb 'Checks' is specific, the resource 'domain' is explicit, and the scope is well-defined. This distinguishes it from sibling tools like bl_check_dnsbl or threat_passive_dns by describing an aggregated feed check rather than a single-feed check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the included feeds and methods, but it does not explicitly state when to prefer this tool over alternatives such as bl_check_dnsbl or threat_cohosting. There is no mention of exclusions or specific scenarios, leaving the agent to infer the value of a multi-feed check from the feed names. This is an implied usage context rather than a clear directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It adds a meaningful behavioral trait: 'Checks DNS registration.' However, it doesn't disclose whether the operation is read-only, what the output format looks like, potential rate limits, or any side effects. The described behavior is helpful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every clause adds value. The first sentence explains what it does, the second provides method details and the DNS-check behavior. There is no redundancy or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description gives enough information to understand the main functionality: generating combosquat domains and checking DNS registration. It could be more complete by hinting at the return structure (e.g., whether results include only registered domains or all variants with status), but the simplicity of the tool makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 contributes illustrative examples (domain-login, domain-secure) that clarify the combination pattern and mentions default/custom keywords, which aligns with the schema. However, it doesn't add substantial meaning beyond what the schema already documents, such as edge cases or keyword formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Generate') with a specific resource ('brand+keyword combination domains') and provides concrete examples. It distinguishes this tool from sibling typo tools like typo_homoglyph or typo_bitsquat by focusing on combosquatting rather than character substitution or bit errors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (generating combosquat variants) but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like typo_homoglyph or typo_full_scan, nor does it state exclusion criteria. The usage scenario is inferable but not clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It does disclose a key behavioral trait: 'Checks DNS registration', indicating the tool performs live DNS lookups. It also gives concrete substitution examples, which adds practical context. However, it does not mention return format, potential rate limits, or side effects, and there is no annotation to cover these. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action. The first sentence states the tool's core function and gives illustrative substitutions; the second adds the DNS registration check. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the essential behavior: generating phonetic variants and checking DNS registration. It does not explicitly state the return value structure, but the DNS check implies a list of variants with registration status. This is nearly complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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, already including an example ('facebook.com'). The description's examples of sound substitutions pertain to the algorithm, not to the parameter itself, so it adds little beyond the schema. Baseline 3 is appropriate for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Uses specific verb 'Generate' with a clear resource: 'phonetically similar domain variants'. The phrase 'using sound substitutions (e.g. ph/f, ck/k, ee/ea, oo/u)' precisely distinguishes it from sibling typo tools like typo_homoglyph or typo_bitsquat, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: you would use this when you need domain variants that sound alike. However, there is no explicit when-to-use guidance or comparison with alternatives such as typo_homoglyph or typo_combosquat, which are adjacent in the sibling list. This leaves a moderate gap for deciding between typo-focused tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavior. It explains the detection mechanism (NS hostname resolving to NXDOMAIN) and the security impact, but does not mention return format, edge cases, or whether it is read-only. It adds context but leaves some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the action front-loaded in the first sentence and the security context in the second. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains what the tool does and why it matters, but without an output schema it does not describe the return format or result structure. For a simple one-parameter detector, this is a notable omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single 'domain' parameter with an example. The description adds no extra parameter-level detail, so it earns the baseline 3 for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detecting dangling NS records that could lead to full domain takeover. It uses specific language ('Detect dangling NS records') and the vulnerability explanation distinguishes it from sibling tools like hijack_dangling_cname and hijack_dangling_mx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for detecting NS-specific dangling records. However, it does not explicitly mention alternatives or when not to use it (e.g., for CNAME records), so it stops short of a full when/when-not distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains the core behavior (repeated resolution, IP change and TTL checks) but does not mention potential side effects like active network queries, rate limits, or output format. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main purpose and supported by a brief technical explanation. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose and detection mechanism well, but since there is no output schema, it does not describe the return value or how to interpret results. The schema covers parameter semantics, but the tool would benefit from explaining what a 'candidate' looks like in the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with 100% coverage. The description adds only an implicit reference to 'multiple times' for samples and does not provide additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Detect' and identifies a unique resource 'DNS rebinding candidates', clearly distinguishing it from sibling DNS analysis tools. It also explains the method (resolving multiple times, checking IP changes and low TTL) which reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 DNS rebinding is suspected, and provides context about the attack. However, it does not explicitly mention alternatives or when not to use it, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 checks performed (lame delegation, glue, NS mismatch) which indicates a read-only verification behavior. However, it does not mention output format, permissions needed, or whether it performs live DNS queries. This is adequate but incomplete for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause adds specific value. It avoids fluff and repetition, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must convey return behavior. It lists the checks but does not state whether the tool returns a boolean, a list of issues, or a report. For a verification tool, this is a notable gap. However, the complexity is moderate (single parameter, specific checks), so the description is partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 is already clearly documented. The tool description adds no additional param semantics beyond restating that the domain is the focus. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Walk the DNS delegation chain and verify consistency.' It enumerates concrete checks (lame delegation, missing glue records, NS mismatch) that distinguish it from sibling tools like dns_zone_transfer or hijack_dangling_ns. The verb+resource+scope are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you need to verify DNS delegation integrity. However, it does not explicitly compare to alternatives or state when not to use it. With siblings like hijack_dangling_ns and dnssec_check_ds, some exclusion guidance would help, but the context is clear enough for an informed agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 method (PTR and CT log searches) and the output scope ('all domains/subdomains'), which adds useful context. However, it does not mention potential limitations, data freshness, rate limits, or whether the query is performed in real-time, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and 34 words, front-loaded with the main verb and purpose. Every sentence contributes meaning: the first explains the method, the second clarifies the output. There is no unnecessary fluff or repetition beyond a minor clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter lookup tool with no output schema, the description is complete. It states what the tool does, how it does it, and what it returns ('all domains/subdomains'). This is sufficient for an agent to understand the tool's functionality and expected output, especially given the minimal complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with the 'ip' parameter already described as 'The IP address to resolve to domains (e.g. '93.184.216.34')'. The description does not add extra meaning beyond the schema, such as IP format constraints or IPv4/IPv6 specifics, so it meets the baseline for schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves an IP address to all known domains and subdomains using reverse DNS (PTR records) and Certificate Transparency log searches. It uses a specific verb ('resolves') and resource ('IP address to domains'), and the combination of methods distinguishes it from siblings like dns_reverse and ct_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a comprehensive IP-to-domain lookup combining reverse DNS and CT logs, but it does not explicitly state when to use it over alternatives such as threat_passive_dns or dns_reverse. There is no mention of exclusions or preferred contexts, leaving usage guidance 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.
Behavior3/5
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 calculation methodology and decision threshold, which is helpful. However, it does not describe the exact output format (e.g., per-label entropy list, boolean detection flag, or aggregated risk score), nor does it disclose edge-case behavior such as how non-FQDN inputs or empty labels are handled. The description is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and followed by the threshold context. Every sentence contributes useful information, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple input (one array parameter at 100% schema coverage) and no annotations or output schema. The description explains the methodology well, but omits what the caller will receive back—whether it returns entropy scores per label, a verdict, or raw values. Without an output schema, the description should clarify the return semantics to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'queries' parameter as a list of DNS query names. The description adds meaning beyond the schema by clarifying that analysis is done 'per subdomain label' and by providing entropy thresholds that help interpret results. This enriches understanding of how the parameter is processed, though it does not specify exact formatting requirements beyond the schema's FQDN description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Calculates Shannon entropy per subdomain label') and the purpose ('to detect DNS tunneling'). It distinguishes itself from sibling tools like tunnel_query_length (which focuses on query length) and tunnel_txt_payload (which focuses on TXT payloads) by explicitly targeting entropy patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on typical entropy values (normal ~3.0-3.5, tunneling >4.0), implying when this tool is useful. However, it does not explicitly state when to use this tool over alternatives such as tunnel_query_length or tunnel_full_scan, nor does it mention any exclusions. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It states the tool analyzes and detects patterns, implying read-only analysis, but does not disclose return format, side effects, or external calls. It adds some context about specific record types but not enough to fully characterize behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. The first sentence front-loads the primary purpose, the second adds specific detection targets. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter analysis tool with no output schema, the description explains the core function and detection scope, but lacks details on the return value/format and any prerequisites or limitations. No annotations or output schema increase the need for explicit return behavior, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema fully describes the single 'queries' parameter, giving a 100% coverage baseline of 3. The description adds extra semantic value by specifying the exact DNS record types analyzed (NULL, TXT, CNAME, MX) and the tunneling context, so a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Analyzes' with clear resource 'DNS queries' and explicitly names record types (NULL, TXT, CNAME, MX) and pattern type (abuse/tunneling), distinguishing it from sibling tunnel_* tools that focus on length, payload, or signatures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to prefer this tool over siblings like tunnel_query_length or tunnel_txt_payload; usage is only implied by the tunnel_* naming family. 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 reveals that the tool optionally queries crt.sh, performs multiple checks (dangling CNAMEs, fingerprint matching), and includes 'HTTP confirmation' for verifying risks. This provides meaningful insight into the tool's operation, though it does not discuss potential side effects or rate limiting, which would be useful for a network-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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the tool's primary purpose. Every clause adds value: subdomain discovery, checks performed, and outcome reporting. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's multi-step complexity and lack of an output schema, the description provides a solid overview of inputs, process, and output ('reports takeover risk with HTTP confirmation'). It omits specific output structure or time expectations, but for an agent deciding whether to invoke the tool, the description is sufficiently complete to understand its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with clear descriptions, so the baseline is 3. The description adds context to 'use_ct' by mentioning 'Certificate Transparency (crt.sh)', but the schema already explains the default behavior for both parameters. The description does not significantly augment the schema's parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'full subdomain takeover scan' with a specific verb ('scan') and resource ('subdomain takeover'). It details the process: discover subdomains, check dangling CNAMEs, match against fingerprints, and report risk with HTTP confirmation. This distinguishes it from sibling tools like 'hijack_dangling_cname' which target individual checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a comprehensive takeover scan by calling it 'full', and the optional CT discovery is mentioned. However, it does not explicitly state when to use this tool versus the more specific hijack_* or ct_* siblings, nor does it provide exclusions or prerequisites. Usage context is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 mechanism: 'Sends a query with a client cookie and checks if the server returns a server cookie.' This gives a clear picture of the tool's behavior, though it does not mention any potential side effects or failure modes beyond server non-response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact with three sentences, each earning its place: purpose, background, and mechanism. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description is sufficiently complete: it explains what the tool tests, why it matters, and how the test is performed. It stops short of specifying the exact output format or result types, but for a boolean-like test this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a detailed schema description for 'nameserver' (IP address or hostname). The tool description adds no extra semantic detail about the parameter, so the schema already carries full weight. The baseline of 3 applies because the description does not compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Test DNS Cookie support (RFC 7873) on a nameserver.' It names the specific resource (nameserver) and the specific behavior (RFC 7873 cookie support), which distinguishes it from sibling tools like infra_edns_compliance or dns_server_fingerprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when testing DNS cookie support) but provides no explicit guidance on when not to use it or which alternative tools to consider. There is no mention of exclusions or comparisons with related tools, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 explains the core behavior (testing for recursive queries from any source and checking EDNS0 buffer size) and the security implication. However, it does not disclose potential side effects (e.g., sending network traffic), expected output format, or any prerequisites. The description adds meaningful context but lacks some behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, both front-loaded with the primary action and key details. No wasted words; every sentence contributes to understanding purpose and additional checks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 primary function, the security rationale, and an additional check (EDNS0). It is slightly incomplete because it does not describe the return value or result format, but given the tool's simplicity and the lack of complex nested objects, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description ('IP address or hostname of the DNS nameserver to test') is already self-explanatory. The tool description does not add additional semantic meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Test if a DNS nameserver is an open resolver' and provides a precise definition. The mention of 'DDoS amplification attacks' and 'EDNS0 buffer size from OPT record' adds specificity that distinguishes it from sibling tools like infra_amplification or dns_recursive_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 to determine if a DNS nameserver is open to recursive queries. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select this tool over similar infrastructure checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It explains the test mechanism: 'Sends a burst of identical queries and checks for REFUSED responses or dropped packets, indicating active rate limiting.' This goes beyond a simple restatement and discloses how the test is performed and what indicators are used. However, it does not mention potential side effects like network traffic generation or false positive possibilities, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two succinct sentences. The first states the purpose, the second explains the method and expected indicators. Every word earns its place, and there is no redundant information or rambling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with two parameters and no output schema, the description provides adequate context: the purpose, the method, and what indicates a positive result. It does not explain the exact return format, but the outcome is clearly implied ('indicating active rate limiting'). This is complete enough for an agent to understand what the tool does and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters: 'nameserver' (IP or hostname) and 'queries' (default 20). The description does not add extra semantic detail beyond the schema—it only mentions the burst behavior, which is already implied by the schema. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Test if a DNS nameserver has Response Rate Limiting (RRL) enabled.' This uses a specific verb ('Test') and resource ('DNS nameserver') with a precise subject (RRL), distinguishing it from sibling tools like infra_open_resolver or infra_amplification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 want to check for RRL on a nameserver—but it does not explicitly state when not to use it or compare it to alternatives. There is no mention of other detection methods or exclusions, so the usage context is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses the specific checks performed (TC flag, TCP connectivity) and the rationale (RFC 7766), which is meaningful behavior beyond a generic 'test' label. However, it does not mention side effects such as sending UDP/TCP network traffic, timeouts, or whether the operation is safe/non-destructive. Given the lack of annotations, this is a moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place: the first states the core test, and the second explains the standard that motivates it. It is front-loaded with the action and resource, with no wasted words or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter test with no output schema, the description adequately explains the procedure (UDP TC flag check and TCP connectivity) and the context (RFC 7766 requirement). It is sufficient for an agent to understand what the tool does, though it could be more complete by stating the interpretation of results (e.g., pass/fail semantics). Given the tool's simplicity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter 'nameserver' with a clear description (IP address or hostname). Since schema coverage is 100%, the description doesn't need to add parameter-level detail. The tool description reinforces the role of the nameserver but adds no extra semantic nuance 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Test' and clearly identifies the resource (DNS nameserver) and what is tested (TCP fallback for large responses). It distinguishes itself from siblings by detailing the exact mechanism: checking the TC flag on UDP responses and verifying TCP port 53 connectivity. This is both specific and differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: when investigating large DNS responses and potential truncation, referenced by RFC 7766. It implies use for compliance testing but does not explicitly state when not to use it or name alternative sibling tools that might suit edge cases. The context is strong, but explicit exclusions or alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It accurately discloses that the tool sends a DNS query with an ECS option, checks forwarding to authoritative servers, and notes the potential privacy consequence. It does not hide the network action, though it leaves out details like output format or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential. The first states the purpose, the second explains the mechanism and consequence. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is self-contained for a simple DNS test tool, explaining what, how, and why. However, since there is no output schema, it could briefly mention what the tool returns (e.g., a leak/no-leak verdict), which is implied but not stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the /24 subnet and ECS option but does not significantly enhance parameter-level understanding beyond what the schema already provides (e.g., resolver and test_domain descriptions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Test EDNS Client Subnet (ECS) leak') and resource ('DNS resolver'), and explains the mechanism (sends query with /24 subnet ECS option). It distinguishes itself from siblings like privacy_leak_test by focusing on ECS specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 concerned about ECS leaks) but does not explicitly mention alternatives or when not to use it. Sibling tools like privacy_resolver_audit or privacy_leak_test are not referenced, so no exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what is tested and that a score is produced, but does not explain scoring methodology, potential test failures, or whether the audit is non-intrusive. 'Audit' suggests read-only behavior, but this is implicit rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, and lists key capabilities without waste. Highly efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description adequately covers what the tool does and what it returns. It lacks details on failure handling or score interpretation, but the core is sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter description already specifies 'IP address or hostname of the DNS resolver.' The tool description adds no further detail about accepted formats or constraints, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a comprehensive privacy audit of a DNS resolver, listing specific tests (DoH, DoT, DNSSEC, DNS Cookie) and the output (score 0-100). This distinguishes it from sibling tools like privacy_doh_test or privacy_dot_test, which focus on individual tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a holistic privacy assessment by calling it 'comprehensive' and enumerating tested protocols. However, it does not explicitly name alternatives or give when-not-to-use scenarios, though the context of sibling tools makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that it runs a current audit, implies network activity, and describes output categories. Yet it lacks details on side effects, permissions, or error handling for invalid baselines.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no redundant text. The first sentence states the function, the second adds context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description compensates by summarizing return categories (new, resolved, unchanged). Given low parameter complexity and clear schema descriptions, this is sufficiently complete for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with detailed descriptions (e.g., baseline is noted as the findings array from previous runs). The description adds little beyond that, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Runs a current DNS security audit and compares it against a baseline.' This distinguishes it from sibling report tools (e.g., report_full_audit) by focusing on comparison over time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear use case: 'useful for tracking DNS security posture over time.' However, it does not explicitly mention when not to use it or name alternative tools, so it stops 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It states the audit runs and returns an executive summary and per-category findings, but it does not disclose side effects, required permissions, or operational traits beyond the high-level action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and purpose, and enumerates categories compactly without filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately conveys scope and return format via 'executive summary and per-category findings'. It could be more explicit about the detailed structure of findings, but it is complete enough for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single 'domain' parameter with a clear description, so the baseline applies. The description adds no additional meaning about parameter usage or format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Runs' and clearly identifies a unique resource: a comprehensive DNS security audit across all named categories. It enumerates the categories, which distinguishes it from category-specific sibling tools like dnssec_full_audit and email_full_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: use when a whole-domain security audit across resolution, DNSSEC, email, hijack, CT, blocklists, and infrastructure is needed. It does not explicitly name alternatives or state when not to use it, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states the analysis methods and the output (per-domain probability score 0-100). However, it could add context about rate limits, batch size constraints, or the heuristic nature of the score, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and resource, and efficiently enumerates indicators and output. Every word contributes value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without an output schema, the description adequately explains the input and output format (per-domain score). It covers the key indicators and return value, making the tool self-contained. A small gap is the lack of any caveats (e.g., dependencies or thresholds), but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already fully documented. The description's mention of 'batch of domains' aligns with the schema but adds no new semantic detail beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyzes') with a clear resource ('batch of domains') and details the exact indicators (DGA score, fast-flux, TTL, DNSBL). This distinguishes it from sibling tools that target individual indicators, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for C2 detection by listing its composite indicators, but it does not explicitly state when to use this tool over alternatives like domain_dga_detect or bl_fast_flux_detect. No exclusions or alternative suggestions are provided, leaving the 'when vs. siblings' guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the dual data sources, the conditional fallback logic, and the returned data types (historical IPs, first/last seen timestamps). It omits potential rate limits or error behavior, but for a read-only query tool this is a solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each earning its place: first defines the operation, second explains the backend selection, third states output. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers the core behavior, data source selection, and return values. It could add note on result format or time bounds, but it is sufficiently complete for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'domain' parameter already fully described in the schema. The description adds no further parameter-specific semantics, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Query passive DNS data for a domain,' a specific verb-resource pair that clearly states the tool's function. It also distinguishes this tool from CT-focused siblings by explaining the fallback from SecurityTrails to crt.sh and the multi-resolver comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the query type and return values, and it discloses the API-key-based fallback behavior. However, it does not explicitly tell when to use this versus sibling tools like ct_search or threat_ip_to_domains, leaving alternatives unmentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 transparently explains the sequence (runs checks, aggregates findings, returns a 0-100 score), but does not disclose potential side effects, prerequisites beyond the schema, or rate limiting. The description is adequate but not richly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and lists specific checks and the output score. Every phrase adds value, and there's no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex scan tool with no output schema, the description covers the main behavioral scope (six checks, aggregation, probability score). It leaves out details about the exact return structure or error cases, but the given information is sufficient for selecting the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters have descriptions. The description adds no additional parameter semantics beyond what's already in 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Comprehensive DNS tunneling detection' with a specific verb ('runs'), the resource (DNS tunneling), and a full enumeration of the six checks. It distinguishes itself from individual tunnel tools by mentioning aggregation and a probability score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is a comprehensive scan covering all checks, which implies using it when a full assessment is needed rather than individual checks. However, it doesn't explicitly state 'when not to use' or list alternate tools by name, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 process (resolve TXT records, detect payloads) and specifies the detection heuristics (base64, hex, binary markers, high-entropy). While it does not mention side effects or output format, it clearly indicates a read-only analysis behavior, which is more transparent than typical tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core action and scope. It does not waste words and covers all key aspects: resolving records, subdomains, and detection types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a full understanding of what the tool does and what types of detections to expect. It covers all parameters and the overall process. The lack of an output schema is not a major gap because the purpose is clear, though explicitly describing the return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter names and descriptions. The tool description adds no additional parameter semantics beyond what the schema already provides; it merely repeats 'domain' and 'optional subdomains' without offering syntax or edge-case details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolves') with a clear object ('TXT records') and a distinct purpose ('detects encoded payloads commonly used in DNS tunneling'). It explicitly enumerates detection types (base64, hex, binary markers, high-entropy content), which distinguishes it from sibling tools like tunnel_query_length or tunnel_entropy_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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 investigating DNS tunneling via TXT records—but it does not explicitly state alternatives or exclusion conditions. There is no comparison with sibling tunnel analysis tools, so an agent must infer the context from the domain-specific wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It goes beyond just 'generates variants' by disclosing a secondary action: 'Checks DNS registration.' This alerts the agent to expected network behavior and additional side effects. While it doesn't detail rate limits or output specifics, this is a good disclosure for a one-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and uses a clean colon list to enumerate mutation types. The final sentence about DNS registration is a useful supplement. Every word contributes value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 annotations or output schema, the description is quite complete: it specifies the exact operation, the variant types, and a secondary behavior. The only gaps are the lack of output format details (e.g., whether it returns only registered domains or a status list) and any cautions about volume/performance. These are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description and example for the 'domain' parameter. The tool description adds useful context about the types of variants generated but doesn't add any new syntax, format details, or constraints beyond what the schema provides. Therefore, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('QWERTY keyboard proximity typosquat variants'), enumerates four distinct mutation types, and is easily differentiated from sibling typo tools like typo_homoglyph or typo_soundsquat. It clearly and concisely states the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for generating keyboard-proximity typosquats, and the name further reinforces this. However, it does not explicitly state when to use this tool over alternatives, nor does it provide exclusions or mention that other typo_* tools cover different mutation categories. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 checks are performed and that it returns pass/fail per check plus a score. It lacks explicit statements about being read-only or side-effect-free, but the report nature is clear. No annotation contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, moderately long sentence that packs in the tool's purpose, specific checks, and output format. It is efficient and front-loaded, though slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain return values; it does by stating pass/fail per check and an overall score. It lists example checks but not an exhaustive list, and lacks details on error handling or edge cases. Still, for a single-parameter report tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a clear description for the 'domain' parameter. The tool description adds little 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: performing CIS DNS Benchmark-style best practice checks, and enumerates specific areas (DNSSEC, email auth, NS diversity, etc.). This distinguishes it from sibling tools that focus on single checks (e.g., dnssec_validate) or other report types (e.g., report_rfc_compliance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a comprehensive best-practice audit report, which provides clear context. However, it does not explicitly mention when to use this tool versus alternatives or state any 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, leaving the description to carry the burden. It discloses the analysis techniques and the dependency on timestamps for beaconing detection, but does not mention return formats, limitations, false positives, or whether the tool is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool's core function and then adds specific detail about the two analysis modes. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with multiple methods, and while the schema covers parameters, there is no output schema and the description does not indicate what results look like (e.g., boolean, risk score) or any prerequisites or limitations. This is enough for a basic understanding but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions (100% coverage), so baseline is 3. The description adds meaning by explaining the role of timestamps (beaconing detection) and queries (label pattern analysis), which enhances the schema's basic type and purpose information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detects') and resource ('covert DNS channels') and clearly states the two detection methods (timing analysis and label pattern analysis). This differentiates it from sibling tools like tunnel_query_length or tunnel_entropy_analysis, which focus on different patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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, explicitly noting that beaconing detection requires timestamps. However, it does not mention alternatives or when not to use it, so it falls short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It discloses the measurement logic and thresholds but does not describe the output format, return type, or any side effects. Since this is a detection tool, the agent is left uncertain whether it returns a score, boolean, or structured metrics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler, and the core action is front-loaded. Each sentence earns its place: it states what it measures, provides normal baselines, and explains anomalous thresholds. This is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple interface (one required array param, no output schema), and the description covers the detection logic well. However, it does not describe what the tool returns or how to interpret the results operationally, which leaves a gap for an agent needing to act on the outcome. It also doesn't mention any relationship to the many sibling tunnel detection tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the single parameter 'queries' with a clear description, so the baseline is 3. The tool description adds interpretive value by explaining what length patterns will be considered abnormal, directly enriching the meaning of the parameter beyond the schema's generic 'analyze for abnormal length patterns.' This justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Measures') and identifies the exact resource ('subdomain label lengths and total query length') with a clear purpose ('to detect DNS tunneling'). This distinguishes it from sibling tools like tunnel_entropy_analysis or tunnel_txt_payload, which focus on other DNS tunneling indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete detection criteria (normal browsing rarely exceeds 3 labels or 60 total characters; tunneling often uses labels >40 chars and totals >200 chars), giving the agent clear context on when results are suspicious. However, it does not explicitly mention alternative tools or when not to use this tool, so it stops short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 mechanism (sends a small query, measures response size ratio) and the interpretation (>10x indicates DDoS risk). It does not detail output format or error handling, but for a single-parameter tool, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding necessary information: purpose, method, and threshold significance. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 mostly complete. It explains what it does, how it works, and what the results imply. It doesn't specify the exact return format, but this is a minor gap given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single parameter 'nameserver' with a clear description. The tool description does not add much beyond the schema, but it reinforces the parameter's role as the target nameserver. Baseline 3 is appropriate since the schema already handles the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool measures DNS amplification factor of a nameserver, using a specific verb and resource. It distinguishes itself from sibling tools like infra_open_resolver and infra_rate_limiting by focusing specifically on amplification factor and DDoS risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for measuring DNS amplification factor to assess DDoS risk. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it appropriately among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 details what the tool checks and what issues it flags, offering insight into its testing logic. However, it doesn't describe output format or potential side effects like sending queries, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: first states the core purpose, second lists checks and flagged issues. No redundant words, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description covers the tool's purpose, testing scope, and issue detection. It lacks detail on results structure or preconditions, but for such a focused tool, it's sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter 'nameserver' with 100% coverage. The description adds no additional parameter-level information 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as testing EDNS0 compliance of a DNS nameserver, enumerating specific checked aspects (EDNS version, UDP buffer size, DO flag, NSID). It distinguishes from sibling infra_* tools by focusing on EDNS0 compliance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for EDNS0 compliance testing with a clear context, but does not explicitly state when to use it versus alternatives like dns_server_fingerprint or dnssec_validate. It provides no exclusions but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides the core behavioral detail: it sends a JSON API query and checks response format, status, and DNSSEC AD bit. This conveys a read-only probing action without prior annotation support, but it omits potential network latency, error behavior, or response structure. It's 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tightly written sentences: purpose, method, and supported inputs. No redundant text, front-loaded with the core action, and every sentence contributes distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single simple parameter, no output schema, and no annotations, the description covers the essential context: what the tool does, how it works, and which inputs are valid. It doesn't explicitly state return values, but for a straightforward test tool this is a minor gap; the description is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for 'server' is already thorough (100% coverage), but the tool description adds value by listing supported providers (Cloudflare, Google, Quad9) and clarifying that custom URLs are allowed. This enriches parameter understanding beyond the schema's examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as testing DNS-over-HTTPS endpoints, with a specific verb ('Test') and resource ('DNS-over-HTTPS (DoH) endpoint connectivity and response'). It details what it does (sends a JSON API query, checks response format, status, and DNSSEC AD bit), and implicitly distinguishes itself from sibling tools like privacy_dot_test and privacy_doq_test by specifying the protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on usage: testing DoH endpoints, with support for Cloudflare, Google, Quad9, and custom servers. It doesn't explicitly state when not to use it or name alternatives, but the protocol-specific wording makes the intended use case unambiguous relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 tool's key behaviors: testing connectivity, reporting TLS details, cert validity, and DNS response. This indicates a network-read operation. However, it doesn't mention potential side effects, error behavior, or whether the operation is read-only, which are minor gaps for a network-testing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main verb and resource. Every sentence adds value: the first defines the tool's scope, the second lists outputs and validation purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diagnostic tool with no output schema, the description adequately summarizes the return contents (TLS version, cipher suite, certificate validity, DNS response) and the validation goal. It could be more complete by describing output format or success/failure indicators, but the provided information is sufficient for an agent to select and invoke the tool correctly in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters ('server', 'port') with 100% coverage. The description adds no additional parameter semantics, which is acceptable given the schema clarity. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Test' and clearly identifies the resource: 'DNS-over-TLS (DoT) endpoint'. It reports concrete outputs (TLS version, cipher suite, certificate validity, DNS response), distinguishing it from sibling tools like privacy_doh_test and privacy_doq_test by explicitly naming DoT.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use it ('Validates that encrypted DNS transport is properly configured'), providing clear context. It doesn't explicitly mention alternatives (e.g., DoH/DoQ tools), but the DoT-specific language implies the appropriate use case. Slight deduction for lacking explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It transparently states the external sources (Team Cymru, RDAP) and the correlation logic (shared nameservers, mail servers, IPs). It does not mention any side effects or limitations, but for a read-only intelligence tool, this level of detail is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, directly front-loaded with the core purpose and supporting detail. Every word earns its place, no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's key capabilities: infrastructure data collection (NS, MX, IP, ASN, registrar) and cross-referencing for related domains. Given the simple schema and absence of an output schema, this is adequately complete, though it could mention whether results are returned as a list or include confidence scoring.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has full coverage for the single parameter `domain` with a clear description. The tool description does not add new parameter details beyond the schema, but it reinforces the domain's role as the starting point for infrastructure mapping. This aligns with 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Maps') and resource ('domain infrastructure fingerprint'), enumerating the specific data types (NS, MX, IP, ASN via Team Cymru, registrar via RDAP). It also highlights the cross-referencing capability to discover related domains, which distinguishes it from sibling tools like `domain_whois` or `threat_passive_dns`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear usage context: mapping a domain's infrastructure and cross-referencing shared infrastructure to identify related domains. It does not explicitly name alternatives or provide when-not-to-use guidance, but the purpose is specific enough to infer appropriate use cases. Lacks explicit exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clearly states it matches patterns and returns matched tools with descriptions and indicators, which is meaningful. It does not mention data sources or side effects, but for a read-only detection tool, the disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action, provides a list of examples, and states the return value. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, no annotations. The description covers purpose, usage context, and return values. It could mention behavior when no matches are found, but the overall completeness is sufficient for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'queries' parameter as 'List of DNS query names (FQDNs) to match against tunneling tool signatures.' The description adds the list of known tools and return behavior but does not add meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'matches' with a clear resource: DNS query patterns against known tunneling tool signatures. It lists concrete examples (iodine, dns2tcp, dnscat2, Cobalt Strike, etc.), distinguishing it from sibling tools like tunnel_query_length or tunnel_entropy_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when DNS tunneling from known signature-based tools is suspected. It provides no explicit exclusions or alternative tool recommendations, but the context is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full transparency burden. It states the tool 'Generates' and 'Reports', implying read-only analysis, and lists three output types. It doesn't explicitly mention network calls or side effects, but for a variant-generation tool, the behavior is fairly clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and includes no redundancy. Every word contributes to understanding purpose and outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 lists the reported items (visual rendering, punycode, DNS status) sufficiently. It doesn't detail the exact return format, but the tool is simple enough that this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description and example for the 'domain' parameter. The tool description adds no parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate IDN homograph attack variants' using specific alphabets (Cyrillic, Greek, Armenian), which distinguishes it from sibling tools like typo_homoglyph. It also specifies the outputs: visual rendering, punycode, and DNS registration status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it's for IDN homograph generation with specific character sets, implying when to use it. However, it doesn't explicitly mention alternatives or exclusion cases (e.g., when to use typo_homoglyph instead), so it stops 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for behavioral disclosure. It states that the tool resolves each TLD variation and reports registered ones with IPs, which adequately conveys the read-only nature and output focus. It could be more detailed about volume or rate implications but is transparent enough for the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no fluff. The first sentence states the core purpose, and the second explains the behavior and output. It is efficiently front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 explains what it tests, what it resolves, and what it reports. It lacks minor context (e.g., exact list of TLDs or runtime) but satisfies the core need for a simple lookup tool. A score of 4 reflects that it goes beyond minimal viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the 'domain' parameter is described in the schema with a clear example. The tool description adds little beyond the schema, merely illustrating TLD patterns. Since the schema documentation is complete, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Test') and resource ('common TLD confusions for a domain'), and provides concrete examples like .com to .co. It distinguishes itself from sibling typo tools (homoglyph, bitsquat, etc.) by focusing exclusively on TLD variations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (when assessing TLD confusion attacks on a domain). However, it does not explicitly mention alternative tools or exclusions (e.g., 'for other typosquatting types use typo_homoglyph'), so it misses the higher bar of explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that Node.js QUIC is experimental, that the tool performs a connectivity probe via DNS query to port 853/UDP, and checks for any response. It also states the output is availability status. This adds meaningful behavioral context beyond just the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, followed by methodology and expected output. Every sentence contributes value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter probe tool with no output schema and no annotations, the description is fully self-contained. It explains the experimental nature, the exact network operation, and what result to expect (availability status). No critical information is missing for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'server' parameter, so the baseline is 3. The description does not add extra meaning beyond the schema's parameter description; it only mentions 'server' in the context of the test target, but the schema already provides examples and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Test') and resource ('DNS-over-QUIC support on a server'), clearly distinguishing it from sibling tools like privacy_doh_test and privacy_dot_test. The title is null, but the description fully clarifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool (to test DoQ support) and explains its probe methodology, but it does not explicitly mention alternatives or exclusions. Sibling tool names imply the distinction, yet no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It goes beyond a generic 'scan' by explicitly disclosing deduplication across techniques and the optional DNS resolution to filter to registered domains, adding useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and structured clearly. Every sentence adds value: the first lists the techniques, the second covers deduplication and the optional registration filter. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description effectively conveys the core behavior, techniques, dedup, and optional resolution. However, it does not specify output format or potential scale/performance implications; since there is no output schema, this would be useful for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters (100% coverage), giving a baseline of 3. The description adds extra meaning by explaining the purpose of check_registered: 'to report only registered domains', which clarifies the parameter's impact on output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Run'), the exact resource ('all 7 typosquatting detection techniques'), and lists each technique. It distinguishes itself from sibling tools like typo_homoglyph by emphasizing the full combined scan and deduplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a comprehensive scan across all techniques and highlights deduplication as a benefit over running individual typo_* tools. However, it does not explicitly mention when to prefer this over specific single-technique tools or provide conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![dns-security-mcp MCP server](https://glama.ai/mcp/servers/badchars/dns-security-mcp/badges/card.svg)](https://glama.ai/mcp/servers/badchars/dns-security-mcp)

Score Badge

Copy to your README.md:

[![dns-security-mcp MCP server](https://glama.ai/mcp/servers/badchars/dns-security-mcp/badges/score.svg)](https://glama.ai/mcp/servers/badchars/dns-security-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/badchars/dns-security-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server