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

Annotations already cover the safety profile (readOnlyHint, destructiveHint false, openWorld false), yet the description adds real behavioral detail: it returns at most five library movements, each with a demo link, and it discloses the fallback behavior of offering the nearest kind when no exact match exists. The read-only claim is also scoped concretely ('changes nothing, including any saved plan').

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?

Three sentences, front-loaded with the usage trigger, then return behavior, then the safety and exclusion clauses. No sentence is redundant and the most decision-relevant content (when to call, when not to) comes first.

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?

Despite an output schema existing, the description still summarizes the return shape (up to five movements, demo links, nearest-kind fallback), and covers triggers, safety, and the injury exclusion. Nothing an agent needs to invoke this 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 description coverage is 100%, so the schema already documents all three parameters, including the 'as the user wrote it' phrasing and the ["none"] equipment example. The description reinforces how available_equipment drives the result set but adds no syntax, format, or handling detail beyond the schema, and never mentions the 'reason' enum. Baseline 3.

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 ('find a replacement for one exercise') plus the three concrete triggers (no equipment, station taken, wants a different option). This is unmistakably distinct from every sibling (get_*, save_*, preview_*, search_*), none of which substitutes an exercise.

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?

Explicit when-to-use conditions are given with a worked example ('no cable machine for cable rows'), and an explicit when-not is provided ('Do not use it to work around pain or injury'). No sibling tool offers an alternative path here, so the absence of a named alternative is not a gap.

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