Prepare restaurant menu resolution

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, openWorld=false. The description adds useful context that the lookup is 'bounded' (consistent with openWorld=false) and the important caveat that results aren't nutrition evidence. However it never explains what 'stage' produces operationally (a pending action to confirm/cancel) or any auth/rate constraints, so added value is partial.

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?

A single, front-loaded sentence with the purpose leading and the caveat trailing after a semicolon. Nothing is wasted, though a more granular breakdown of the staged result would have earned a higher mark without hurting brevity.

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, no-output-schema lookup tool the description covers purpose and a caveat. It omits what the staged artifact is and how it is consumed (e.g., via confirm_action/cancel_action in the sibling set), which an agent needs to complete the flow.

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?

Only one parameter (query) with 0% schema description coverage, so the schema gives no semantic help. The description implies what the lookup targets but never characterizes the query string (e.g., restaurant name, dish, location) or its 2-200 length bounds. With a single self-evident param, this is adequate but not compensating.

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 clear verb+resource: 'Stage a bounded lookup for official restaurant menu sources and visual references.' An agent knows this resolves restaurant menu material, which is distinct from the many meal/grocery siblings. It does not, however, differentiate itself from an adjacent resolution tool like resolve_barcode or resolve_amazon_products.

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 a boundary note ('results are not nutrition evidence by themselves'), which hints at when the output should not be relied on. But it never states when to call this versus alternatives, nor any prerequisite such as needing a restaurant/query first. Usage is left to inference.

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