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

The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: it emphasizes that the tool uses a narrow list-based signal, includes the list date and attribution, and clarifies the IPv4-mapped IPv6 handling. This supplements the annotations with useful limitations and output details without contradicting them.

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 two sentences long, with the primary action and scope stated first. It efficiently communicates the essential purpose and caveats without any filler. The IPv4-mapped clarification is relevant and front-loaded, and the overall structure is clean and easy to scan.

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 check tool with one parameter, the description is largely complete. It mentions that the response includes the list date and attribution, giving a hint of the output content. It does not detail the exact response structure, but given the absence of an output schema, the description provides enough context for an agent to understand what to expect. The annotations cover the operational safety profile, so nothing critical is missing.

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 description coverage is 100% for the single 'ip' parameter, and the schema already explains the IPv4-mapped IPv6 behavior. The tool description repeats this and adds context about the list, but it does not introduce any new parameter semantics beyond what the schema provides. Since the schema fully covers the parameter, a baseline of 3 is appropriate.

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's function: it checks an IP address against a curated list of known hijacked or cyber-crime-controlled netblocks. It also specifies the IPv4-mapped IPv6 behavior, which distinguishes it from generic IP tools. The purpose is unambiguous and distinct from sibling tools like url_reputation (which handles URLs) and address_risk (likely broader risk assessment).

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 a caveat that a clean result is not a safety guarantee, which implies it should not be used as a sole safety check. However, it does not explicitly state when to use this tool versus alternatives or name any specific sibling tool for comprehensive checks. The usage context is implied but not explicitly directed.

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