Historical WHOIS / BGP for an Indicator

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

Description goes beyond annotations by detailing return shapes per indicator type, upstream failure behavior (available: false, retryAfter), and explicitly instructing not to loop on retry. No contradictions with annotations.

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 well-organized into logical sections (indicator types, return shapes, failure mode) with no wasted words. It is front-loaded with the core action and then expands with necessary detail.

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

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

Given the tool's complexity (multiple indicator types, varying return shapes, performance caveats, failure handling), the description covers all essential aspects. Output schema exists, so return values are documented.

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

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

Schema coverage is 100%, but the description adds extra meaning by giving examples, allowed characters, and explaining auto-detection. This compensates for any missing schema detail.

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

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

The description clearly states it retrieves historical WHOIS or BGP data for a single indicator, specifying auto-detection of indicator types (IPv4, IPv6, hostname, CIDR, ASN). This distinguishes it from sibling tools like explain_indicator or query.

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 usage context (e.g., ASN queries are slow) and examples of allowed indicators. However, it does not explicitly state when to use this tool vs alternatives, nor does it provide when-not-to-use guidance.

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