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

readOnlyHint=true already establishes the safety profile, so the description's marginal contribution is the field list, which is useful but is really return-value content. It does not disclose what happens when the lookup misses, whether a name lookup is exact or fuzzy, whether an ambiguous name returns one item or many, or any auth/scope requirement.

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?

A single tight sentence fragment with no filler; the field enumeration is front-loaded and every token carries information. It loses a point for being a fragment that never anchors the action, leaving the reader to reconstruct the verb from the tool name.

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?

With no output schema, the description correctly takes on the job of summarizing return fields, which is the right instinct for a read-only detail lookup. It remains incomplete on lookup semantics — mutual exclusivity of id vs name, empty-result behavior, and multi-match handling — which are exactly the ambiguities a two-optional-parameter resolver tool creates.

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% and neither of the two parameters is documented, so the description must carry the burden. '(by catalog id or name)' does hint that exerciseId and name are alternative addressing modes, which is genuinely valuable, but it never states they are mutually exclusive, which takes precedence if both are passed, the id format, or what happens when both are omitted (required count is 0).

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 enumerates the exercise attributes returned (description, steps, muscles, equipment, difficulty, images, video) and implies retrieval by 'catalog id or name', so an agent can infer the resource and payload. But it is a bare noun phrase with no verb, and among siblings like search_exercises, get_exercise_alternatives, get_exercise_history and get_exercise_stats it offers no differentiation of what makes this 'detail' versus those.

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?

There is no statement of when to use this tool, no prerequisite, and no mention of the obvious alternatives (search_exercises for discovery, get_exercise_alternatives for substitutions). The only usage hint is the parenthetical '(by catalog id or name)', which is about addressing, not selection.

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