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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, but the description adds real behavioral context: tents come back best-scored first, tent searches default to car camping unless backpacking is signaled, and absent budget data must be acknowledged rather than guessed. The presentation rules (lead with top pick by exact name; say 'rates'/'scores' not 'tested'; use only returned data) go well beyond annotations. Loses a point because it does not describe pagination or what the 'guides' payload actually looks like at a structural level.

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?

Front-loaded with the core search behavior, then operational rules. Every sentence carries a distinct instruction. It is dense and runs long, but each clause earns its place (branching logic, defaults, phrasing constraints, missing-data handling). Slightly heavy for a single tool description.

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 an open-ended, seven-parameter, zero-required search tool with no output schema, the description covers the full operational surface: domain split, query semantics, defaults, missing-data behavior, and result-presentation contract. Nothing an agent needs to call and present results correctly is missing.

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 coverage is 100% so baseline is 3, but the description adds genuinely non-obvious semantics the schema does not state: filler words like 'best' are ignored, plain-word queries are parsed for capacity/seasons, and the car-camping-vs-backpacking default. These are behavioral parameter rules that meaningfully improve invocation accuracy beyond the schema's own text.

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 specific verb (Search) and resource (Wilderness Times' gear recommendations), then splits the domain into two clearly-defined behaviors: tents scored out of 10, and everything else returned as buying guides. This is far more specific than any sibling (get_gear, build_checklist), so an agent can distinguish it without opening a schema.

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 names trigger conditions ('whenever someone asks what gear to buy, which tent suits a trip, or for a recommendation'), a no-arg fallback ('call with no query to see what is covered'), and a specific decision procedure ('if group size matters and the user has not given it, ask before recommending'). The tent vs. guide branching is stated as an operational rule, not left to inference.

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