Reanalyze an IP address with VirusTotal

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

Annotations already provide readOnly=false, destructiveHint=true, and idempotentHint=true, and the description adds material context on top: standard sharing applies, no per-call confirmation, current rights/quota are used, retries are prohibited, and 'completion is not a safety verdict.' These are behavioral facts the binary hints alone cannot convey.

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?

Although the description is comparatively long, it is front-loaded with purpose, and each subsequent clause carries a distinct operational rule—format, ID handling, sharing, quota, recovery, and result semantics. There is no filler; every sentence earns its place.

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?

It covers input constraints, ID management, quota/rights, recovery via sibling tools, and how to interpret the completion signal, which is nearly everything for a two-parameter endpoint. The only minor omission is an explicit statement of the immediate response envelope, though the recovery guidance partially compensates.

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%, so the description must compensate, and it does. It specifies the IP format (bare IPv4/IPv6, no port, brackets, zone, or CIDR) and the request_id format (new canonical lowercase UUIDv4), giving the agent concrete validation knowledge beyond the empty schema.

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 first sentence names the exact operation and resource: 'Request standard VirusTotal reanalysis of one IPv4 or IPv6 address.' This is specific enough to distinguish it from sibling tools like get_ip_report or reanalyze_domain without inspecting their schemas.

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?

It explicitly instructs when to invoke the tool (reanalysis of an IP) and routes recovery through get_submission(request_id) and get_analysis, never an automatic POST retry or replacement request ID. It also clarifies when a new ID is appropriate—a deliberate later reanalysis—which is exactly the decision guidance an agent needs.

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