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

Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior: returns only applicable suggestions, each flagged 'offered' true/false, and the agent should tell the shopper what each would change and let them decide. It also reinforces the unprompted-call prohibition.

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 call condition is front-loaded, and the long enumeration largely earns its place as routing logic absent from the schema. There are typos and duplicated words ('when when', 'shopper_as_about_other_costs', 'stainles_steel') that slightly hurt readability but not structure.

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?

An output schema exists, so return-shape explanation is optional and the brief 'offered' true/false note suffices. Combined with the annotations and the exhaustive situation routing, an agent has what it needs to decide when to call and what to send; only the design/appliance object contents rely solely on the schema.

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 only 33%, and the schema's situation enum has no per-value descriptions, so the description carries real weight by defining the trigger meaning of each enum value. It also specifies what payload to send for 'fill_space' (design) and 'lower_cost' (grill brand/size/msrp), compensating for the coverage gap, though design/appliance field-level detail is left to the schema.

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 opening sentence, 'Suggestions for the shopper's outdoor kitchen', is close to a restatement of the title, but the enumerated situations immediately make concrete what kind of suggestions this returns (cost, fill-space, materials, ROI, DIY, etc.). An agent can distinguish it from siblings like outdoor_kitchen_price_design or outdoor_kitchen_list_cabinets, though the single-sentence purpose statement itself is thin.

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?

Explicitly states 'Call ONLY in one of these situations' and then maps each of the 15 situation values to a concrete shopper utterance, plus 'Never call it unprompted.' This is about as strong a when-to-use / when-not-to-use routing spec as a description can carry.

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