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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only adds 'Free.' as a cost hint and implies a read operation via 'Get', but it does not disclose error handling, return format, or any limitations. Given the lack of annotation support, this is insufficient transparency for a tool that could behave in unexpected ways.

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 extremely concise: two short sentences that state the purpose and a key behavioral note ('Free'). It is front-loaded and every word earns its place, with no filler or redundancy.

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 one-parameter get-by-ID tool with no output schema and no annotations, the description provides the core information needed to invoke it (need a previous radar search ID). However, it lacks context about what 'results' entails, how to find previous searches, or what the response structure looks like, leaving the agent partially in the dark.

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 already documents search_id as 'Search UUID', and the description adds the contextual note that the ID must refer to a previous radar search. This adds some semantic value beyond the schema, but it does not explain how to obtain the ID or what its format/constraints are, so the 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 action ('Get results') and its target resource ('a previous radar search'), which is specific and unambiguous. The inclusion of 'previous' distinguishes it from initiating a new search, and the tool name 'get_radar_results' further differentiates it from siblings like search_content or radar_history.

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?

There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites beyond the implicit need for a previous radar search. The description does not mention radar_history for finding search IDs or search_content for initiating searches, so the agent lacks contextual decision support.

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