production.facial_integrate_with_body

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

Beyond annotations it discloses meaningful behavior: apply defaults to false (dry-run plan), facial is an immutable plan.json reference, candidates are new Actions on NLA tracks, and the body Action is never modified. It also names a concrete failure mode (TIMING_INPUT_REQUIRED). It stops short of saying what a plan output contains or what 'technical QA and artistic review stay separate' actually implies operationally.

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 compact and information-dense, but it opens by restating the tool name and the opaque 'M7 facial unit' label, and the semicolon-chained telegraphic style makes it harder to parse than a front-loaded verb-first sentence would be.

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?

The tool is high-complexity (7 params, mutation-capable, output schema present, output values need not be explained). The description covers the safety/plan-vs-apply model and the speech timing constraint well, but with 0% schema coverage the missing documentation of five parameters leaves an agent guessing what to pass for brief, intent, object_name, operation_id and options.

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%, so the description must carry parameter meaning, and it only explains two: facial (immutable plan.json reference) and apply (default false). brief, intent, object_name, operation_id and options are never mentioned, leaving five of seven parameters undocumented anywhere.

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 name conveys 'integrate facial with body', and the description adds that candidates are new Actions evaluated through NLA tracks, so the resource is inferable. But 'M7 facial unit' and 'evidence-based semantic mapping (never names only)' are internal jargon that do not plainly state what the tool produces, and no sibling (e.g. facial_generate, facial_prepare_speech, animation_* ) is named for contrast.

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?

It gives the key workflow rule: plan first, apply=false by default, and that speech requires explicit timed phonemes/visemes or TIMING_INPUT_REQUIRED fires. That is real usage context, but there is no statement of when to choose this over facial_prepare_speech or the animation generation tools, and no prerequisites/ordering beyond 'plan first'.

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