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

Annotations declare destructiveHint=true, and the description earns that by spelling out exactly what is destroyed: 'New steps replace the whole old list, and the result carries the steps that were replaced.' It also discloses non-obvious side effects the annotations cannot convey — id retention, scheduled dates persisting, and the watch receiving the new version at its next sync.

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?

The behavioral summary is front-loaded in one dense sentence, and per-parameter notes follow a consistent pattern. The repeated 'Omit to keep the current one' phrasing across four args is slightly redundant but keeps each arg self-contained.

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?

An output schema exists and annotations cover the safety profile, so the description needn't explain the response shape — though it helpfully notes the replaced steps come back. The one real gap is 'steps: ... in the same shape as when creating a workout': the schema types steps only as an untyped object array (additionalProperties: true), so the agent must open create_workout to learn the step structure.

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 0%, but the Args block documents all six parameters, including the omit-to-keep defaulting behavior for null fields and the sport-only-with-steps dependency. 'Workout_id' being required is implicit but clear.

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 opening sentence gives a specific verb and resource ('Change an existing workout in place') plus the exact fields it can touch, which cleanly separates it from create_workout, delete_workout and get_workout. 'It keeps its id' further distinguishes in-place mutation from delete-and-recreate.

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 'Omit to keep' convention is explained and constrains each optional field, and 'sport: Only with steps, and only to change the sport' states a real coupling rule an agent could otherwise get wrong. What's missing is explicit routing to siblings such as schedule_workout/unschedule_workout for changing scheduled dates.

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