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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world); the description adds substantial behavior beyond that: a hard 25-entries-per-call cap with guidance to narrow filters, the ranked partial-word fallback for `query`, the body-region word matching rule, and the equipment-matching rule where body weight always counts and [] means no equipment. It also flags `safety` as something to respect when prescribing, which is real operational context.

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 purpose, then the filters, then the return shape – a sensible order with little waste. It is dense and long, and the field-by-field enumeration of return values partially duplicates what the output schema already provides, but with 0% parameter documentation the length is largely earned.

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 search tool with an output schema, the description covers the search semantics and result shape well enough to call it correctly, and the output schema handles return typing. Minor incompleteness remains around `limit` bounds and how `locale` interacts with `query` matching.

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 0%, so the description carries the full burden, and it does well: `muscle` gets concrete values, `equipment` gets a precise matching rule and an explicit meaning for the empty list, `query` gets multilingual and ranking semantics, and `movement_pattern`/`category` are named as filters. The gaps are `limit` (only implied by the 25 cap) and `locale` (only implied by 'localized name'), neither of which is defined.

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 and resource ('Search the curated global exercise pool') and immediately scopes it as the catalog programs/workouts are built from, which separates it from user-catalog tools. The added detail that `in_user_catalog` merely marks prior training reinforces that this searches the global pool, not the user's own list.

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?

Usage is implied rather than stated: it is clearly for finding exercises by attribute, and the closing line 'a narrower filter finds the rest' is a genuine usage tip for the 25-result cap. However, it never says when to prefer this over list_exercises or show_exercise, nor when not to use it, so the agent must infer routing.

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