production.animation_detect_limb_stretch

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

Annotations already declare idempotent, non-destructive, closed-world behavior, so the description needn't explain safety. It does add one genuinely useful behavioral fact: intentional stretch is reported separately from unintentional stretch, which affects how results should be read. It does not disclose scope (single limb vs entire rig), tolerance thresholds, or whether 'options' changes behavior.

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 short sentence with no filler, and the key differentiator (reporting configured intentional stretch separately) is placed at the end where it reads naturally. It is under-specified rather than bloated.

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-value explanation is not required, but for a detection tool with a fully undocumented 'options' parameter the description leaves critical gaps: what scope is analyzed, what thresholds or configuration options exist, and what constitutes a reported issue.

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% for 2 parameters, so the description carries the full burden and fails it: object_name is never mentioned and the open-ended 'options' blob is completely unexplained (no supported keys, thresholds, or filters). Only the object_name title hints at intent.

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 conveys the mechanism (comparing evaluated bone lengths to rest lengths) and that intentional/configured stretch is reported separately, which is specific to limb-stretch detection. However, the fragmentary passive phrasing ('Evaluated lengths versus rest lengths') never states the verb/resource cleanly and gives no hint of how it differs from near-siblings like animation_detect_limb_pops or animation_analyze_balance.

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 when-to-use guidance, no prerequisites, and no mention of alternatives or what to do with the result. The agent must infer that this is a validation pass run before/after retargeting or animation fixes.

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