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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds genuine behavioral value by disclosing the shape of the returned payload (nested exercises with sets, reps, rest, cues), which matters because there is no output schema. It does not mention behavior on an unknown slug.

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 essential scope, then return contents, then input source, then example — a sensible order with no filler. The conversational opener 'Show me that workout in full' is slightly informal but does double duty as a scope statement.

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 one param, no output schema, and full annotation coverage, the description supplies exactly the missing pieces: what is returned and how to obtain the slug. Only a note on missing/invalid slug behavior is absent.

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% — the single 'slug' parameter is bare in the schema. The description compensates well by stating the slug's provenance ('from search_workouts') and giving a concrete example value, making the expected format unambiguous.

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 ('Show me that workout in full') and immediately enumerates what 'full' means: author, discipline, duration, warm-up, coach note, every exercise. This distinguishes it from the sibling search_workouts (which returns matches, not full detail) without naming that sibling explicitly.

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?

The phrase 'Input: slug from search_workouts' establishes the workflow: search first, then fetch full detail by slug. It does not state when NOT to use it (e.g., to browse multiple workouts, use search_workouts/list), but the implied sequencing is clear and actionable.

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