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

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description explains that the tool interprets the request and routes to appropriate capabilities, which is a meaningful behavioral trait not captured in annotations. It also specifies that it preserves qualifiers like concerns, skin type, and medical context, adding context about how it processes input.

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 front-loaded with 'Start here for any shopping request' and uses concise, purposeful sentences. It provides necessary instructions and alternatives without redundancy, earning its length with concrete guidance and examples.

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 complex routing tool with no output schema, the description covers input expectations, routing capabilities, and guidance for follow-ups. It lacks details on return values or edge cases, but these are less critical for an entry-point tool. The overall guidance is sufficient for an agent to invoke it correctly.

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%, with each parameter already described as a 'secondary hint only' and the `request` field fully documented. The description reinforces the importance of passing the complete request, but adds no substantial new information beyond what the schema provides. Baseline 3 applies.

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 is an entry point for any shopping request, using a specific verb ('Start here') and explicitly distinguishes from sibling tools by listing the granular tools (search_products, get_product, compare_products, create_checkout) as precise follow-ups. It defines its scope as understanding and routing conversational requests.

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?

It gives explicit guidance: 'Prefer this tool whenever the request is conversational or carries any nuance' and states that granular tools remain available as follow-ups. This directly tells the agent when to use this tool versus alternatives.

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