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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds real value beyond them by disclosing the ownership constraint (team-owned only, stock read-only) and the minimum-payload rule. It does not say whether omitted fields are left untouched or cleared, which matters given destructiveHint=true on a metadata patch.

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, no filler: purpose and field list first, trigger second, hard constraints last. Every sentence carries distinct information an agent needs.

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 an output schema present, return values need not be described, and the description covers ownership, minimum payload, and field scope. The remaining gap is the undocumented team_id parameter and the merge-vs-replace behavior on a destructiveHint mutation.

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%, so the description must carry the load; it explains five of seven fields in plain language (name, muscle groups, categories, equipment, skill level) but says nothing about team_id, and gives no guidance on the ID-array fields beyond their names or on whether partial updates replace or merge. Helpful but incomplete compensation.

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 (updates) and resource (exercise metadata) and enumerates the mutable fields (name, muscle groups, categories, equipment, skill level), which an agent can map to the exercise domain immediately. It does not explicitly distinguish itself from near siblings like update_exercise_group or update_workout, so it falls short of a 5.

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?

Gives a concrete trigger ('user wants to fix or improve exercise tagging'), an explicit exclusion ('stock exercises are read-only'), and a precondition ('provide at least one field to update besides exercise_id'). It stops short of naming the alternative tool to use when the exercise is stock (e.g., cloning a stock exercise into a team one).

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