dnsrecon DNS reconnaissance

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds some behavioral context by mentioning zone transfer attempts and DNSSEC zone walking, but much of this is already reflected in the scan_type enum descriptions, and no additional context such as network intensity or external service usage is disclosed.

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

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

The entire description is one dense, front-loaded sentence that packs the tool's purpose, target resource, and capability set without filler. Every clause contributes useful information, and the dependency on scan_type is clearly signaled.

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

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

For a tool with two parameters, one required, and rich enum documentation, the description is largely sufficient: it identifies the target, the operation family, and the scan-dependent output types. It lacks explicit return-value/pagination details, but no output schema exists and the core request shape is fully inferable from the schema and description.

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

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

Schema description coverage is 100%, with both domain and scan_type already documented, so the baseline is 3. The description mentions scan_type and lists scan-dependent outputs, but it does not add semantic detail beyond what the schema enum descriptions already provide.

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

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

The description clearly names the action ('DNS reconnaissance') and the resource ('a domain') and enumerates the specific record types and operations covered, such as SOA, NS, MX, zone transfer attempts, and certificate-log names. It does not explicitly distinguish itself from the sibling dns_lookup tool, but the broader scope is evident from the detailed capability list.

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

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

The description provides no guidance about when to choose this tool over alternatives such as dns_lookup, subfinder_subdomain_search, or whois_lookup. It only notes that execution depends on scan_type, which is a parameter detail rather than a selection criterion or exclusion.

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