audit_dns

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

The annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds behavioral details such as resolving IPv4 and IPv6 addresses and performing network routing verification, which are consistent with the annotations and do not contradict them, providing extra transparency beyond the metadata.

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

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

The description is concise, using three sentences to cover what the tool does, when to use it, and what not to use it for. It is well-structured with clear sections and contains no redundant or irrelevant information.

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

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

For a simple one-parameter, read-only tool, the description is complete. It covers the tool's purpose, usage scenario, and exclusions, and relies on the output schema for return value details, so an agent has all necessary context to invoke it correctly.

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

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

The schema covers the single parameter 'domain' with full description and format guidance, and the tool description reinforces its meaning by specifying what to exclude (http/https protocols, URL paths). This goes beyond the schema's baseline by adding practical context for correct parameter usage.

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

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

The description clearly states the tool performs forward DNS resolution and network routing verification, resolves IPv4 and IPv6, and specifies its purpose as verifying host reachability and guarding against SSRF. It also explicitly distinguishes itself from WHOIS and deep port scanning, making its function unambiguous and differentiating it from the sibling tools.

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

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

The description provides explicit guidance on when to use the tool ('Use to verify host reachability and guard autonomous agents against SSRF before making HTTP requests') and when not to use it ('Do not use for WHOIS domain registration lookups or deep port scanning'), giving clear conditions and exclusions.

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