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

With annotations already declaring readOnlyHint=true and idempotentHint=true, the description still adds valuable behavioral context: it is a 'live' search (results are real-time, not cached) and it does not persist the result ('without storing a search snapshot'). It also discloses the exact return format (Markdown table). This goes beyond simple safety annotations and aligns with 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 efficient sentences. It front-loads the core action and scope, immediately states a key negative behavior ('without storing a search snapshot'), and then gives the return format. Every clause adds value with no repetition or fluff.

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?

Given the tool's moderate complexity, the rich schema (all param docs), annotations (read-only, idempotent), and output budget schema, the description covers everything essential: the stores, the live/non-persisting behavior, and exact output format. Nothing critical is missing for an agent to decide whether and how to invoke it.

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 100%, and each parameter is clearly documented with names, types, constraints, and examples. The description adds minimal extra parameter detail beyond the schema (only human-readable store names), so baseline 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 specifies the exact action ('Run a live ranked search'), the resource (app store results across iOS App Store, macOS App Store, Google Play, or Microsoft Store), and the key distinguishing trait ('without storing a search snapshot'). This clearly separates it from store-specific history or overview tools among the siblings, even without naming them.

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 clear context that this tool is for live, current-ranked searches and explicitly notes it does not store a snapshot, which implies when to use it over snapshot-based sibling tools like get_keyword_history. However, it does not explicitly name alternatives or state 'when not to use', so it falls just short of a perfect score.

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