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

There are no annotations, so the description carries the full behavioral burden. 'Check' and 'Is the IP a known Tor exit node' imply a read-only membership lookup, which is the core behavior. However, it does not mention data source, invalid-IP handling, or what an empty q means.

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 a single, front-loaded sentence that immediately states the tool's purpose with no wasted words. It is concise and scannable, which is appropriate for a simple lookup with one parameter.

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 one-parameter tool with an output schema present, the description covers the essential purpose and identifies the input object. It remains minimally sufficient, though it lacks sibling differentiation and default-parameter clarification.

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 only parameter, q, has no schema description and a default of '', so the description must compensate. 'The IP' indicates that q represents an IP address, but the expected format and the meaning of an empty or default value are not explained. It adds some meaning but leaves notable gaps.

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 states a clear operation: checking whether an IP is a known Tor exit node, and identifies the specific resource being queried. It is not tautological, but it does not differentiate from the sibling tool 'isexitnode', which may cover the same check.

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?

No guidance is given for when to use this tool versus alternatives like 'isexitnode' or other IP-intelligence tools. The large sibling list makes this gap noticeable, but the description provides no context or exclusions.

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