osint_dns_audit

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

No annotations are supplied, so the description carries the full behavioral burden and largely drops it. It never says whether the lookup is passive (resolver queries) or involves active probing, what happens on NXDOMAIN or invalid input, whether rate limits apply, or roughly how many record types come back. The output schema covers return shape, but the operational character of the call remains undisclosed.

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

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

Two compact lines with the capability front-loaded before the argument block. The 'Args:' docstring section is slightly redundant for a one-parameter tool, though it does carry the only format example available.

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

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

With one required parameter and an output schema present, the basic contract is covered. The real gap is contextual: in a dense OSINT sibling cluster, the description never positions this tool relative to the recon, IP-lookup and subdomain tools. That omission is what an agent most needs here.

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 0% — the single 'domain' property has only a type and title. The description partially compensates by naming it a domain name to audit and giving the example 'openai.com', which clarifies expected format. It still says nothing about whether bare domains are required versus full URLs, or about internationalized domains.

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?

States a specific verb and resource: lookup of IPv4, IPv6 and server infrastructure records for a domain. The purpose is legible without opening the schema. It does not, however, differentiate itself from close siblings such as osint_domain_recon, osint_ip_lookup, osint_subdomain_enumeration or osint_tech_stack, which all sound like they touch the same DNS/infrastructure surface.

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 only usage framing is 'for any domain', which is a scope statement, not guidance. There is no indication of when to prefer this over osint_domain_recon or osint_ip_lookup, no prerequisites, and no exclusions. An agent seeing eight OSINT siblings has to guess which one to call.

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