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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false; the description reinforces the closed-world trait with 'No external lookup is performed' and adds the non-obvious interpretive caveat that a match is only evidence and absence is not safety. It stops short of describing the result shape or how the time window affects results.

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?

Four short, front-loaded sentences, each carrying distinct meaning: purpose, match interpretation, no-match interpretation, and scope of the lookup. No filler and no repetition.

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 five parameters at 0% schema description coverage and no output schema, the description should explain the time window, pagination, and the operator-tests flag, plus what a result contains. Instead it spends its budget entirely on interpretation caveats, leaving the agent unable to set parameters confidently.

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% for five parameters, and the description says nothing about any of them. The bare phrase 'for an IP' hints at the required ip field, but the hours window, limit, before cursor for pagination, and include_operator_tests toggle are left entirely unexplained, forcing the agent to guess at their meaning.

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: 'Look up observed behavior for an IP.' An agent can tell this is an IP-centric lookup versus the aggregate views offered by get_activity_summary or get_sensor_coverage, though no sibling is named explicitly.

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 frames how to interpret results (evidence, not proof; no match is not safe), which is genuinely useful framing, but it never says when to choose this tool over search_observations or get_observation_evidence. No prerequisites, exclusions, or alternatives are stated.

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