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

Annotations already carry readOnlyHint=true and openWorldHint=false, and the description adds substantial behavior beyond those: equipment filtering semantics ('only exercises fully covered by it are returned'), the instruction to reuse the canonical slug verbatim as exercise_id, the meaning of in_user_catalog, and the returned data shape (localized names, technique cues, muscle tiers, rep/rest defaults). Nothing here contradicts the annotations; the open-world hint is consistent with 'curated global exercise pool.'

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?

Four sentences, each earning its place: core purpose and when to use it, filter semantics, return-content and slug contract, and the fallback boundary. The most decision-relevant information is front-loaded in the first sentence, with no filler.

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 7-parameter, all-optional, no-enum search tool, the description covers the important semantics and an output schema exists to document return values. Remaining gaps are the conjunction behavior of multiple filters (AND vs OR), the effect of `limit`, and the role of `locale` — minor but nonzero for fully correct invocation.

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?

With 0% schema description coverage, the description carries the burden and compensates well: `muscle` gets concrete examples ('lats', 'side_delts'), `equipment` gets coverage semantics, and `query` gets 'a name in any supported language.' However, `limit` and `locale` are left undocumented in both the schema and the description, so the compensation is strong but incomplete.

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 opens with a specific verb+resource — 'Search the curated global exercise pool' — and frames it as 'THE place to pick exercises from when building a program or a workout,' which sets it apart from sibling list/upsert tools. The scope ('curated global') and the distinction between the pool and user-catalog entries ('in_user_catalog marks the ones this user has trained before') make its role unmistakable.

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 a clear when-to-use context ('when building a program or a workout') and a when-not boundary ('Invent your own exercise only when nothing here fits'), which effectively routes the agent to a creation path when search fails. However, no sibling tool is explicitly named as an alternative, and the closely related `list_exercises` sibling is never addressed, leaving some routing to inference.

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