production.animation_analyze_control_mode

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the trailing 'no mutation' merely restates the structured safety profile rather than adding to it. The description says nothing about what the analysis reports, its scope relative to the rig, or cost/latency characteristics, so it contributes almost no behavioral value beyond annotations.

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?

It is a single compact clause with no filler, and the read-only constraint is placed at the end. Brevity here tips into under-specification: the density of undefined jargon ('M2', 'M3') means the short sentence conveys less than a longer clear one would.

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, so return values need not be narrated, but the tool takes a free-form options object with zero documentation and an unexplained object_name, and the M2/M3 terminology is undefined. For a diagnostic tool embedded in a large rig/animation tool family, the description is not sufficient to invoke it correctly.

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%: object_name has no description and options is a free-form object with default null and no documented shape. The description never references either parameter, so the meaning of 'options' (what control-mode settings can be passed?) is left entirely unexplained, which is the exact gap a description should fill at low coverage.

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 fragment identifies the subject as control-mode analysis covering per-limb modes, targets, switches and driver relationships, which is a real resource. However, the opaque tokens 'M2' and 'M3' are never defined, so an agent cannot tell what is actually being analyzed or how this differs from neighbors like rig_analyze_controls or rig_analyze_limbs.

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 reach for this tool versus rig_analyze_controls, rig_analyze_limbs, or animation_analyze. 'No mutation' implies a read-only diagnostic, but no preconditions, triggering scenarios, or alternatives are named.

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