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

With no annotations, the description carries the full burden and partially meets it: it discloses the coordinate space, per-item defaults (parent=root, rotation=0, length=0), and the key semantic that existing art is untouched. It omits any statement about permissions, failure behavior, or idempotency, so gaps remain for a mutation tool.

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?

Two tight sentences with the coordinate scope front-loaded and the item contract spelled out compactly. No filler, though the inline JSON-ish field list is dense and slightly cryptic without a described top-level parameter.

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?

No output schema exists, so the description need not explain returns, but for an unannotated mutation tool it should say more about the 'project' parameter and what happens to the existing rig state. The bone-item contract is complete, the surrounding context is not.

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% and the schema only declares an untyped array of free-form objects, so the description is doing real work: it enumerates the per-bone fields (name, parent, x, y, rotation, length) and their defaults. It does not explain the required 'project' parameter, which keeps it short of a 5.

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+resource ('Add bones') and pins down the coordinate convention (WORLD, y up), which is essential context for a rigging tool. It doesn't explicitly differentiate itself from nearby siblings like add_chain, but the purpose is unmistakable.

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 guidance on when to use this versus alternatives such as add_chain, reparent_slot, or the rig_* family. The 'Art never moves' note is a behavioral fact, not a use-condition, so the agent is left to infer when this tool is appropriate.

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

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

With no annotations, the description carries the full burden. It usefully discloses the structural behavior (n points produce n-1 bones, each reaching the next), but says nothing about side effects, permissions, whether an existing rig is modified, or what is returned. Adequate but incomplete for a mutation tool with zero annotation coverage.

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?

Two sentences, front-loaded with the defining mechanic and followed by usage examples. Every clause earns its place with no redundancy.

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?

For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description conveys the core concept but omits parameter meanings and behavioral side effects. It is minimally sufficient to understand intent but not to invoke confidently.

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% across 4 parameters, so the description must compensate. It clarifies that 'points' are world-space polyline coordinates, which is a genuine semantic addition, but leaves 'name', 'parent' (including its default of root), and 'project' entirely undocumented.

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 states a specific verb and resource ('Bones along a polyline of world points') and explains the mechanics (n points → n-1 bones, each reaching the next point). This implicitly distinguishes it from the sibling add_bones, but it never names that alternative explicitly, so it falls short of full sibling differentiation.

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?

'Use for limbs, spines, tails, tentacles' gives clear positive use-case context. However, it offers no exclusions or named alternatives (e.g. when to prefer add_bones or rig_serpent over a manual chain), so it stays at clear-context-without-exclusions.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing beyond the fact that it mutates an animation. It does not say whether the call persists immediately, whether it is undoable, what permissions or project state are required, or what happens if the event name is unknown. The event-type examples are the only added context.

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 front-loaded sentence with no filler; the parenthetical examples are the one detail worth keeping. It is efficient, though the brevity comes at the cost of coverage captured in other dimensions.

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?

For a 7-parameter mutation tool with no annotations, no output schema, and no parameter documentation, the description is well short of what an agent needs to call it correctly. The payload parameters and the required Spine/event-name preconditions are entirely undocumented.

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% across 7 parameters, so the description must compensate and does not. Nothing explains the required name/time/project/animation, nor the meaning or default behavior of string, int_value, and float_value payload fields, which are entirely opaque despite being the mechanism for passing event data.

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 ('Fire a Spine event') plus the resource and scope ('in an animation'), and the parenthetical examples (SFX cue, rollup start/stop, particle trigger) concretely illustrate what an event is. It is clearly distinguishable from sibling rigging/mesh tools, though it does not explicitly contrast with the nearest neighbors like add_keys or clip_set.

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 guidance on when to use this versus alternatives such as add_keys or other animation-authoring tools, nor any prerequisites (e.g. whether the animation/clip must already exist, or whether the event name must be predefined in Spine). 'In an animation' is the only implied context.

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

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

With no annotations, the description carries the full burden and does disclose some behavior: Spine easing curves are auto-written, and values are offsets from the setup pose (Spine semantics). It does not say whether existing keys are overwritten or merged, what replace_animation does, or what permissions/failure modes apply to this mutation.

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?

Dense but almost every clause carries information: purpose first, then per-type key formats, then easing vocabulary. The format is list-like and scannable rather than terse prose, so it earns its length despite being long.

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?

For an 8-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is substantively helpful but has real gaps: replace_animation semantics, ease default (sine_in_out), whether bone and slot are mutually exclusive, and whether the target animation must pre-exist are all unaddressed.

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 compensate and it largely does, giving per-timeline-type key formats (rotate [t, deg], translate [t, x, y], rgba [t, "RRGGBBAA"], etc.) and the full list of valid easing names. It leaves project, animation, bone, slot, ease defaults and replace_animation undocumented, but the hard part of the input is covered.

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 concrete verb+resource ('Key one timeline') and immediately qualifies the operation with named easing and Spine curve generation. It is distinguishable from siblings like add_bones or add_event, though it never explicitly names those alternatives or clarifies what a 'timeline' is to a non-expert.

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 statement of prerequisites (must the project/animation already exist?), and no routing to alternatives such as add_bones or add_event. The only conditional instruction is about appending an easing name to a key, which is parameter mechanics rather than usage context.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the headless aerender path over the work area that never touches the open project, the mode/blend behavior, trimming of empty frames, output location (images/ae/<name>_NN.png), and the ae_<name> event fired at the start. Side effects are explicit.

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 prose is dense and front-loaded, organized loosely by Source/mode/Timing/seq_mode, and largely free of filler. It is long, but the length is justified by 28 parameters; a few clauses are compressed to the point of terseness.

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?

For a complex mutation tool with no annotations and no output schema, the description covers behavior, inputs, and outputs (files and events) thoroughly. The remaining gap is the handful of undocumented placement/frame-range parameters, which an agent would have to infer.

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% and there are 28 params, so the description must compensate, which it does for the non-obvious timing params (start, hit_ae/hit_at, fit_duration, until, seq_mode, max_frames/max_size, scale, fade). However, several params (x, y, color, parent, front_of, behind, start_frame, end_frame, keep_frames) are left entirely undocumented, so the compensation is substantial but incomplete.

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 states a specific verb and resource: render an AE comp and play it in Spine as a frame sequence with timing matched. This clearly distinguishes it from sibling render/asset tools like ae_template, fx_generate, and fx_recipe without needing to open a schema.

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 two mutually-exclusive source paths and the condition for each (aep+comp vs frames_dir+fps), plus mode/blend and seq_mode alternatives. It stops short of naming sibling tools to route against, but the when-to-use context is clear.

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

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

With no annotations present, the description carries the full burden and does so well: it discloses that nothing is rendered, that the actual comp creation happens inside a different MCP (ae_fx_templates folder of the OPEN project), what that call returns (name, size, fps, frames), that save_as writes the .aep needed by aerender, and that AE caches by comp name so each tuning attempt needs a fresh name.

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 scoping statement and template catalog are front-loaded, and the 'Then:' workflow is easy to follow. It is information-dense and every sentence adds something, though the long template list and inline parentheticals make it slightly run-on rather than tightly structured.

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?

Given no annotations, no output schema, and only 3 mostly-undocumented parameters, the description supplies what an agent needs: purpose, template options, parameter behavior, the returned value's shape, and the follow-up calls. Nothing essential for correct invocation is missing except the unexplained out_dir.

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 compensate. It explains name (empty lists templates; otherwise one of the enumerated templates) and the structure of params (overrides template defaults; comp= names the comp; save_as= persists the .aep). Only out_dir is never explained, leaving a minor gap in an otherwise strong 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+resource+deliverable: 'Build an After Effects FX comp from a template: returns a script to run in AE (nothing is rendered here).' It enumerates the concrete templates and distinguishes itself from sibling FX tools (fx_generate, fx_recipe) by making clear it only authors a comp/script rather than rendering.

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 an explicit end-to-end workflow: call with name="" to list templates, then run the returned `run_with` via ae_run_script, save the project, and pass the comp to ae_fx_to_spine with mode="additive" when indicated. It names the alternative tools to use downstream and the condition that selects each step.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses concrete behavioral traits: clips MERGE by name into the host's clips, same name = same animation, timelines added, host clip keeps its length, loops refit and one-shots retime. It also describes physics/reactivity per kind (physics strands, IK feet, idle reactions). It stops short of stating permission requirements, reversibility, or persistence guarantees.

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 description is long but front-loaded: the core merge semantics appear in the first sentence before the kind enumeration. Given 0% schema coverage and no annotations, the kind-by-kind detail is functionally necessary rather than padding, and each line conveys distinct information. Some tightening is possible but there is little waste.

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?

For a complex tool with 5 undocumented parameters, no annotations, and no output schema, the description supplies substantial context: merge behavior, all nine kinds with default bones, options, and host-reaction behavior. It omits the project parameter's meaning and any return/validation information, so it is thorough but not fully complete.

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 compensate, and it largely does: kind values are exhaustively enumerated with default bones and per-kind options (options.sound, options.tail_mood, options.wing_type, options.slots, options.clips), and name is explained as prefixing the new bones. The project and general bone parameters remain undescribed, leaving a gap.

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 states a specific verb and resource: 'Plug a sub-rig into a named bone of ANY rig.' This distinguishes it from siblings that build whole characters (rig_biped, rig_quadruped, rig_creature). The purpose is clear, though the differentiation from siblings is implicit rather than stated.

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 description explains that kind="" lists available kinds and then enumerates each kind with its default bones and options, which gives de facto guidance on which kind to pick. However, it never states when to use this tool instead of alternatives like rig_biped or secondary, nor any prerequisites or when-not-to-use conditions.

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

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

With no annotations the description carries the full burden and delivers substantial behavior: loops close exactly, one-shots end on the setup pose, the setup is preserved, missing-bone clips are skipped and reported, and a full event set (sfx_step, sfx_jump, attack_hit, etc.) is emitted. It stops short of disclosing write/overwrite semantics (does it replace existing clips?) or permissions, which are the main residual gaps.

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 core concept is front-loaded in the first sentence, but the body is a dense wall of physics exposition (inverted pendulum, spring-mass, gravity-parabola flight, wind v^2) that informs what clips look like more than how to invoke the tool. The clip/event inventories earn their place; the physics prose is verbose relative to invocation 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?

For a complex 9-parameter tool with no annotations and no output schema, the description covers clip identity, events, physics, and rig/bone-mapping behavior well. It is still incomplete on the required project parameter, the facing and attack_hand selectors, the wind flag, and overwrite semantics, leaving an agent to guess at invocation details.

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 compensate, and it does for several parameters: bone_map (with a concrete rename example), intensity (0.5 subtle … 1 standard … 1.6 cartoon), durations ({clip: seconds}), and blow_from (front|back). It leaves project (the only required param), clips, facing, attack_hand, and wind unexplained, so coverage is partial rather than complete.

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 line frames the tool as the standard animation-clip contract, and the enumerated clip list (idle, walk, run, jump, land, hit, attack, win, lose, talk) makes the resource concrete and distinguishes it from narrower siblings like gait, face_clip, and lipsync. The action verb is implied rather than stated (it never says 'creates/generates clips'), so an agent infers the operation from context.

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 an applicability condition ('works on any rig that has the bones a clip needs') and states that clips with missing bones are skipped, which is useful context. However, it never says when to reach for clip_set versus alternatives such as gait, add_keys, face_clip, or lipsync, and no prerequisites or sequencing are given.

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

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

With no annotations, the description carries the full behavioral burden. It adds useful context about what each dependency is for (Node as official spine-core runtime for validation and previews, CLI for editable .spine export), but does not disclose whether it executes commands, what output format to expect, how failures are reported, or whether it is safe to run repeatedly.

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 sentence front-loads the verb and object, with parentheticals that add meaningful context about each checked component. No filler or redundant phrasing.

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?

For a simple 0-parameter diagnostic tool with no output schema, the description identifies what is checked but says nothing about the expected result (e.g., pass/fail per dependency, report format, or next steps). An agent lacks a sense of what a successful or failed invocation returns.

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?

The tool takes zero parameters, so the baseline is 4. There are no parameter meanings to clarify, and the empty schema leaves nothing unaddressed.

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 ('Check') and resource ('toolchain'), then enumerates the components checked (Python deps, Node, Spine editor CLI). None of the sibling tools perform environment or dependency diagnostics, so the purpose is unambiguous and well differentiated.

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?

Usage is only implied: the tool diagnoses the environment before running pipeline tools. There are no explicit when-to-use conditions, prerequisites, or alternatives named. An agent can infer the context but gets no guidance on when this check is required versus optional.

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

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

With no annotations, the description carries the full burden. It notes the export runs via the Spine CLI and lists format options, but says nothing about whether out_dir must pre-exist, whether existing files are overwritten, error behavior, or what artifacts are produced.

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 front-loaded sentence with the parenthetical enumerating format values placed at the end. No waste, though the nested 'or a path to' phrasing is slightly dense.

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?

For a 3-parameter file-writing tool with no annotations and no output schema, the description covers purpose and format selection but omits side effects and the nature of the produced output. Adequate but with clear gaps.

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 compensate. It usefully clarifies that fmt accepts 'json', 'binary', or a path to an export-settings JSON — a non-obvious detail — but leaves spine_project and out_dir entirely unelaborated.

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 and resource: exporting a .spine project to runtime data. This is distinguishable from siblings like pack_atlas or preview, though it doesn't explicitly name what it is not.

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?

No indication of when to use this tool versus alternatives such as pack_atlas or validate, and no prerequisites or sequencing context. Usage is only inferable from the name.

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

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

With zero annotations the description carries the full burden, and it delivers substantial behavioral detail: default durations per clip type, what intensity scales, what seed drives (Poisson saccades/blinks), and that text/phonemes/wpm only affect 'talk'. It does not state what happens to an existing clip on rebuild, nor permission/return behavior, leaving some gaps for a mutation tool.

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?

Four tightly packed lines, front-loaded with purpose followed by parameter semantics, with essentially no filler. Jargon like 'Poisson saccades' is terse but still informative, keeping it efficient 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?

For a 10-parameter tool with no annotations and no output schema, the description covers the semantically rich parameters but omits project and spine entirely and does not describe overwrite/rebuild consequences. Adequate to invoke the core use case but incomplete for the full parameter surface.

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 compensate, and it explains most parameters well: duration (with per-clip defaults), intensity, seed, text/phonemes/wpm, and name's rename effect. Only project and spine are left undocumented, so the compensation is strong but not total.

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+resource ('(Re)build one face clip on a rigged face') and enumerates the valid clip values (idle | happy | sad | angry | surprised | talk), which acts as an implicit enum. It does not explicitly contrast itself with neighbors like clip_set or lipsync, so it stops short of full sibling differentiation.

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 explicit when-to-use or when-not-to-use guidance, and no routing to alternatives such as clip_set (multi-clip) or lipsync (speech). Usage is only inferable from the phrase 'on a rigged face' and the clip-type list.

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

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

No annotations are present, so the description carries the full behavioral burden. It does disclose a genuine side effect ('Each preset fires an event fx_<preset>') and a texture/atlas implication, which is useful. However, it says nothing about permissions, reversibility, whether existing animation content is affected, or what the call returns.

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 purpose is front-loaded in the first sentence, and the preset/parameter notes that follow are dense but each adds real information. The parenthetical preset catalog is somewhat run-on, but nothing is pure filler.

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 15 parameters, no annotations, and no output schema, the description should explain more of the calling surface and expected results. It covers the preset selection and a couple of parameters but leaves the majority of inputs and the outcome of the call undocumented, so an agent cannot confidently invoke it with non-default 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 description coverage is 0% across 15 parameters, so the description must compensate, and it only covers about three: it enumerates valid preset values (valuable since the schema has no enum), explains 'into', and flags that shine_sweep requires 'slot'. The remaining twelve params (x, y, size, color, count, start, behind, parent, project, duration, front_of, intensity) receive no meaning, so most of the surface stays opaque.

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 opens with a specific verb+resource ('Add an FX preset') and clarifies it is built from Spine primitives with procedural textures. This is far more informative than a bare name. However, it does not differentiate itself from related siblings like fx_recipe, juice_apply, or ae_fx_to_spine, which an agent would plausibly confuse it with.

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 description supplies usage-relevant detail for specific parameters ('into: merge into an existing animation', 'shine_sweep needs slot='), which implies when certain options apply. But it offers no explicit guidance on when to choose this tool over the sibling FX tools (fx_recipe, juice_apply, ae_fx_to_spine), leaving the primary routing decision to inference.

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

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

With no annotations, the description carries the full burden and discloses important behavioral traits: procedural, additive only (one draw call), one group bone per recipe, and that it merges into animations via into=. It also notes that recipes moving bones use inserted carrier bones, never the user's keys. It does not cover side effects like project modification or reversibility, but the core behavior is well‑explained.

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 description is extremely long, sprawling, and list-heavy, reading like a reference manual rather than a focused tool description. It is not front-loaded beyond the first clause and lacks clear structural breaks (e.g., sections), making it hard to scan. Many sentences could be trimmed or moved to external docs.

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?

Given 19 parameters, no schema descriptions, and no output schema, the description provides substantial coverage but is incomplete. It omits semantics for multiple parameters and does not explain return values or side effects in full. It is adequate for basic use but leaves an agent exposed on edge cases.

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 compensate. It defines most key parameters (x, y, scale, start, duration, color, intensity, count, recipe, options, tier, art, into, parent) with useful semantics like coordinate space, time units, and option syntax. Several parameters (name, seed, project, behind, front_of) remain undocumented, keeping it from a 5.

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 clearly identifies the tool as a generator of authored FX layers from recipes, listing the available families and key behaviors. It distinguishes itself from siblings like ae_fx_to_spine by explaining that hybrids return a ring_hint for that tool, but it does not explicitly contrast with fx_generate, leaving some ambiguity about when to choose this over others.

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 explicit operational guidance: recipe='' lists all recipes, recipe='guide' returns the guide, and it details parameter usage and bundle options. However, it lacks a direct comparison to alternatives (e.g., fx_generate) and does not state when not to use this tool, which prevents a perfect score.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the key mutation effect, sfx_step events at touch-down, exact loop closure, speed/frequency/stride coupling, override behavior, and reporting of over-stretched legs. This is richly transparent for a complex rigging tool.

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?

Long but dense and front-loaded: it begins with the core action, then labels parameter groups. For an 18-parameter rigging tool, each sentence contributes eligibility rules, parameter meaning, or behavioral detail without padding.

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?

Given high complexity, no annotations, and no output schema, the description is largely complete. It lacks explicit return or error behavior for the keying mode, only implying the listing behavior when no project is supplied, which is a minor gap for a mutation tool without an output schema.

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% across 18 parameters, so the description must compensate. It explains gait values by leg count, leg target structure and name parsing, body role, speed defaults and formulas, override semantics for frequency/duty/clearance/bob/pitch/roll, exaggerate, facing, name, start, and cycles. It meaningfully covers nearly all parameters.

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 and resource: 'Key a gait' on any rig with foot IK targets and a body bone. It also explains the no-project listing mode. It does not explicitly differentiate from siblings such as add_keys or rig_quadruped, so sibling differentiation is absent.

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 clear prerequisites ('ANY rig that has foot IK targets and a body bone') and a special usage mode: 'Call with no project to list the gaits.' However, it does not say when not to use it or name alternative tools, so exclusions are missing.

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

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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: one slot per visible layer, exact canvas placement, PNGs cropped to content, blend modes mapped, hidden layers excluded. It omits what out_dir does, whether existing files are overwritten, scale effects, and error/permission behavior, so it is partial.

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?

Two tight sentences with the core transformation front-loaded and zero filler. Dense jargon ('PNGs cropped to content', 'blend modes mapped') but every clause carries information.

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?

For a 7-parameter mutation-style tool with no annotations, no output schema, and 0% schema coverage, the description leaves most parameters and all return/behavioral details unexplained. It is enough to understand the concept but not enough to invoke it correctly across its 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 description coverage is 0%, so the description must compensate for all 7 params, but it only clarifies one (origin: 'center' for symbols, 'bottom' for characters). psd, name, scale, out_dir, include_hidden, and groups_as_bones are left completely undefined.

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?

It states a concrete verb+resource transformation ('PSD → project: one slot per visible layer') and specifics the output structure, so an agent can tell it imports/converts a PSD rather than inspecting one. It does not explicitly differentiate itself from inspect_psd, the obvious sibling, 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?

There is no when-to-use / when-not-to-use guidance and no mention of the alternative tools (e.g. inspect_psd for inspection). The only usage hint is embedded in the origin parameter ('for symbols', 'for characters'), which is parameter-level, not tool-level routing.

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

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

With no annotations, the description carries the full burden. It clearly discloses read-only behavior ('without writing anything') and lists the exact output fields, which is valuable. It lacks details on permissions, failure modes, or whether the PSD must already be loaded, preventing a 5.

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?

Two short sentences, front-loaded with the core action and return fields, followed by the key usage instruction. Every part earns its place with no redundancy.

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?

For a simple inspection tool with no annotations or output schema, the description covers purpose, safety, usage context, and return fields. The only gap is parameter details, but overall it provides enough for an agent to call 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 description coverage is 0% for the single 'psd' parameter. The description only mentions 'a PSD's' and adds no information about what the parameter expects (file path, identifier, format) or any constraints, so it fails to compensate for the missing schema documentation.

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 'List' and resource 'a PSD's layers', and enumerates the returned fields (names, groups, visibility, blend, bounds, [tags]). It also distinguishes itself from the sibling import_psd by stating it does not write and should be run before import_psd.

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?

Explicitly says 'Run before import_psd', giving clear context for when to use it. It doesn't state when not to use it or name alternative inspection tools, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden and discloses key behaviors: only two inserted bones are animated so the artist's keys are untouched, one-shots end on the setup pose, loops are seamless, and SFX events fire. It also gives intensity range and fx layering behavior, though it omits permissions, reversibility, and return information.

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 description is dense but front-loads the clip contract and then moves through behavioral details without obvious filler. It could be better structured with bullets, but every sentence conveys domain-specific information.

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?

For an 8-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is materially incomplete. It omits when to use the tool, never defines project, merge, or durations, and gives no sense of return values or overwrite behavior.

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 compensate. It explains clips, intensity, fx, shine_slot, and the options mappings (back, rows, to, darkness), but leaves project, merge, and durations completely undocumented, which is a significant gap for 8 parameters.

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 opens with 'Slot-symbol juice' and then enumerates the exact clip set and the two inserted bones, making the resource and effect scope concrete. It does not explicitly distinguish itself from sibling tools like fx_generate or secondary, 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?

The description never states when to use this tool versus alternatives, nor does it offer prerequisites or exclusions. It lists clips and options but gives no routing guidance among the many rig/fx siblings.

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

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

With no annotations, the description carries the full burden and does well: it discloses the rig prerequisites, the timing model (60/wpm per word, vowels 1.6x), that visemes are stepped keys placed 'lead' ahead of the sound, jaw easing values, nearest-shape fallback for missing visemes, that it ends on rest, and the events emitted (sfx_talk, talk_word, talk_end). It omits what happens to pre-existing keys and whether the operation is destructive, which are relevant for a key-generating mutation.

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 core purpose is front-loaded in the first sentence and the remaining detail is dense and largely non-redundant for a complex 12-parameter tool. It reads as a run-on with many parentheticals, which slightly hurts scannability, but little of it is filler.

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?

For a 12-parameter tool with no annotations and no output schema, the description supplies substantial behavioral and parameter context, including fallback behavior and events. The remaining shortfall is the unexplained 'start' and 'replace' semantics and the absence of any mutation/reversibility note.

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 supply parameter meaning, and it largely does: text vs phonemes (ARPAbet or viseme letters or [phoneme, seconds]), wpm timing, lead offset, durations defaults, mouth_slot, jaw_bone, events, and animation. The gaps are 'start' and 'replace', neither of which is explained (notably whether replace overwrites existing keys), leaving a few of the twelve parameters undocumented.

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 states a specific verb+resource+output: generating viseme and jaw keys from text or phonemes into an animation. It is immediately distinguishable from siblings like face_clip, rig_face, or gait, which do different face/animation work. An agent knows exactly what artifact this produces.

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 description states the rig prerequisite ('any rig with a mouth slot whose attachments are named A E I O U M F L [rest], and/or a jaw bone'), which implies when the tool is applicable. However, it never says when to prefer this over alternatives such as face_clip or add_keys, nor any exclusion. Usage is inferred from constraints rather than routed explicitly.

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

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

With no annotations, the description carries the full burden and rises to it: saccades are instant, counter=True produces a vestibulo-ocular jump-and-roll-back, loop=True solves periodically, and a carrier bone is inserted 'so the artist's keys stay.' This discloses real side effects and default dynamics. It stops short of stating permissions, whether existing keys can be overwritten, or undo 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?

The purpose is front-loaded and nearly every clause carries real information, so there is little pure padding. But the prose is a dense run-on of nested parentheticals that is hard to parse in one pass, hurting structure even though the information density is warranted for a tool this complex.

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?

For an 11-parameter tool with no annotations and no output schema, the description covers the operation, the default rig chain, the interaction between gaze/target and levels, and key side effects. Gaps remain on fps and duration (default 0, which is meaningful and unexplained), so it is close to but not fully complete.

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 compensate, and it does substantially: it documents the gaze tuple format with unit conventions, target and target_range semantics, the full levels object fields (bone, channel, range, weight, lag, hz, zeta, limit, role), plus spine, counter, and loop. It leaves fps, duration, project, and animation unexplained.

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: 'Bake a lagged look chain into an animation: eyes -> head -> spine.' An agent can tell this is a gaze/look-rig baking tool. However, it never names or distinguishes itself from likely siblings like rig_face, face_clip, or secondary, so the differentiation is left implicit.

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 description hints at context ('works for bodies', 'Default on a face rig') and explains two input modes (gaze array vs target bone), which implies when each is used. But there is no explicit statement of when to choose this over rig_face, face_clip, or secondary, and no prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full behavioral burden and does well: it describes the generated layer hierarchy, how split_limbs changes limb layers, and the implied origin='bottom' setup. It still omits side-effect details such as output file behavior, permissions, or error conditions.

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 purpose is front-loaded and the layer enumeration is dense but purposeful. It is one long sentence plus a workflow sentence, which is acceptable, though it could be structured into clearer parameter and output sections.

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?

For a procedural sample generator with 4 parameters and no output schema, the description gives useful layer structure and workflow context. However, it leaves out important parameter meanings, especially out_dir, and does not clarify output artifacts or side effects, so it is only partially complete.

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 compensate. It explains split_limbs=true and the resulting layer changes, but it does not explain the required out_dir parameter at all, nor the name or facing parameters, leaving most parameter semantics undocumented.

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 states a specific verb and resource: create a procedural biped, with a chibi adventurer, side view. It names the exact layer structure and distinguishes the tool from other make_* sample siblings by focusing on the biped character type.

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 provides a concrete downstream workflow: 'Try rig_biped → clip_set → qa_character on it.' This tells the agent what to do after creation, but it does not explicitly state when to choose this tool over make_quadruped_sample, make_face_sample, or other sample generators.

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

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

With no annotations, the description carries the full burden and does well: it discloses that output is PIL-drawn, one image per layer, named exactly to match the import_psd convention, and explicitly that the result is unrigged. It omits details like overwrite behavior for out_dir or error conditions, keeping it short of a 5.

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?

Two front-loaded sentences that put the tool's identity and the kind list first, then the non-rigging caveat. Dense and largely waste-free, though the import_psd naming clause is slightly buried and lengthy.

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?

For a sample-generation tool with no output schema and no annotations, the description covers the essentials: output format (layered PIL images), naming convention, and the required follow-up (rig_creature). Only the handling of out_dir and any failure modes are left implicit.

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 compensate. It effectively documents the 'kind' parameter by enumerating all eight valid values (slime | golem | ghost | tentacle | dragon | insect | plant | mimic), but says nothing about 'out_dir' beyond its self-evident name, leaving half the parameters unaddressed.

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+resource ('procedural sample for rig_creature') and names the exact consumer it feeds. The enumerated kinds and the 'run rig_creature on it' clause clearly separate it from siblings like make_sample, make_face_sample, and make_biped_sample.

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 clear downstream context ('Not rigged: run rig_creature on it'), which tells the agent what this tool is for and what follows it. It does not, however, explicitly say when to choose it over the other make_*_sample siblings, so it stops short of the 5-level routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that a licensed Spine editor CLI is required and that the importer may make repairs it then reports, which is real behavioral context beyond the schema. However, it omits whether existing files are overwritten, what happens to unsupported features, and any failure/auth mode.

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?

Two tight sentences with zero filler, and the core action is front-loaded ahead of the secondary reporting behavior. Every clause earns its place.

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?

For a two-parameter tool with no output schema and no annotations, the description covers the high-level action and the repair-reporting behavior but leaves both parameters and any return details unaddressed. Adequate at a minimum, with clear gaps an agent would benefit from closing.

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 compensate, but it adds no information about either parameter. It doesn't clarify what form `project` takes (a directory, a .spine path, a project name) or what `out_spine` controls, leaving both inputs undocumented.

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 (import) and a specific output artifact (an editable .spine file via the licensed Spine editor CLI), which is enough to distinguish it from siblings like export_runtime or validate. It stops short of explicitly naming which sibling to prefer in ambiguous cases, but the verb+resource pairing is clear.

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 description never says when to use this tool versus alternatives such as import_psd, make_sample, or export_runtime, nor does it state any prerequisites beyond an implied CLI license. Nothing tells the agent under what conditions make_editable is the right call.

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

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

With no annotations, the description carries the full burden. It discloses rich output structure (layer names, all on root) and a follow-up rig_face step, but it omits mutation behavior such as whether out_dir is overwritten, required scene state, or permissions.

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 purpose is front-loaded, and the dense parenthetical layer list earns its place by defining the exact naming convention. It is long and could be better formatted as a list, but it is not padded.

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 description adequately covers the output layer structure for a sample-generation tool, and no output schema means return values need not be explained. However, the required out_dir parameter and side-effect behavior are completely unaddressed, leaving invocation details incomplete.

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?

There is one required parameter, out_dir, with 0% schema description coverage, and the description never mentions it. An agent receives no guidance on what out_dir means, its format, or whether it must already exist.

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?

Starts with a specific verb and resource: 'Create the procedural sample face: a mascot head drawn as separate layers.' It distinguishes itself from other make_*_sample siblings by specifying a face, and it names the exact layer convention and the follow-up rig_face step.

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 description implies usage by saying to 'Run rig_face on it,' which gives a next-step workflow, but it never states when to use this tool versus alternatives like import_psd or make_sample, nor does it provide exclusions.

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

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

No annotations, so the description carries the burden. It usefully discloses that generation is procedural and deterministic in naming (wing_<side>_feather1..N, wing_l/_r), which tells an agent the structure it will get. It does not say whether files are written to out_dir, whether existing output is overwritten, or what happens if the rig already exists.

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 dense sentence with the purpose and generated structure front-loaded; essentially no filler. The trailing component list is informative rather than wasteful, though it reads a bit like a terse spec dump.

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 no annotations, no output schema, and 0% param coverage, the description should explain output location and parameter behavior. It describes the generated asset's components but leaves the write behavior, return value, and both parameters largely unexplained.

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% and neither parameter is documented in the schema. The '1..N' notation hints that the feathers param controls feather count, but out_dir is never mentioned and the value range/format of feathers is unstated, so the description only partially compensates for the coverage gap.

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 action (procedurally generate a front-view bird sample) and ties it to the sibling rig_flier, distinguishing it from make_biped_sample/make_quadruped_sample/make_creature_sample. The generated component list (tail, wing_l/_r, body, head, beak, eyes) makes the output concrete.

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 phrase 'for rig_flier' implies this is the sample asset to feed into rig_flier, giving implied usage. However, it never states when to choose this vs. other make_*_sample tools or any prerequisites/ordering.

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

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

With no annotations, the description carries the full burden, and it does substantial work: it discloses the bone hierarchy (root > hips > chest > head, legs, arms), the exact clip set with durations and loop types (idle 2.4s loop, walk 1.0s loop, win 1.2s one-shot), and the add-on layers produced. It omits filesystem behavior such as whether out_dir is overwritten or what file format is emitted.

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 dense sentence that front-loads the core purpose ('Procedural minimal biped host for attach_rig') before the supporting detail. The nested parentheticals for clips and parts are information-dense but make the sentence heavy; still, no filler sentences.

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?

For a 2-param procedural generator with no annotations, no output schema, and 0% schema coverage, the description supplies a rich picture of what is generated (bones, clips, parts). The main gap is the semantics of the required out_dir output location and any file-writing behavior, which nothing else in the definition covers.

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 compensate. It fully documents the `parts` parameter by enumerating all accepted values (ears, tail, wings, horns, snake_hair, mermaid, fur, glow, digitigrade) and the default (ears, tail, wings), which is strong. The required `out_dir` parameter receives no explanation at all, leaving half the parameters undocumented.

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 states a specific verb+resource: a procedural minimal biped host for attach_rig, and enumerates its concrete contents (bone chain, clips, part layers). It is distinguishable from generic sample makers, though it never explicitly names or contrasts with the very similar make_biped_sample sibling.

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 phrase 'for attach_rig' implies this sample is meant as a host to be followed by attach_rig, which is useful implied context. However, there is no explicit when-to-use guidance and no indication of when to prefer make_biped_sample, make_sample, or other sibling generators instead.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose real side effects — rig=True additionally runs rig_quadruped over all clips, and with_mid=False drops the metapodial layers so the rig splits the lower legs — but it says nothing about what files land in out_dir, overwrite behavior, or any prerequisites/permissions for a generation tool.

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, front-loaded with what the tool produces before covering the two flag behaviors. Dense but every clause carries information; no filler or repetition.

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?

For a five-parameter code-generation tool with no annotations and no output schema, the description covers the two non-obvious boolean behaviors but omits what the generated output actually is on disk and how out_dir/leg_type shape the result. Adequate for a knowledgeable agent, but there are clear gaps for correct invocation.

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 document all five parameters. It explains only two (rig and with_mid); out_dir, name, and leg_type are left entirely undefined, and leg_type's default 'digitigrade' has no documented value set despite being a meaningful anatomical choice.

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 names a concrete artifact (a procedural dog-like side view that faces right and stands on y=0), its structure (one layer per part following the QUADRUPED_LAYERS convention), and its intended use (to try rig_quadruped and gait on). That is a specific verb+resource, and 'dog-like/quadruped' implicitly separates it from make_biped_sample, make_serpent_sample, and make_creature_sample, though it never names those alternatives outright.

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 states the purpose of the sample ('to try rig_quadruped and gait on'), which implies when to reach for it, and it ties rig=True to running rig_quadruped. However, it gives no explicit when-to-use/when-not guidance against the sibling sample generators or rig tools, leaving the agent to infer the routing.

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

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

With no annotations, the description carries the full behavioral burden for what is clearly a write operation. It says nothing about writing files to disk, whether out_dir is created or must pre-exist, whether existing content is overwritten, or what the resulting project layout is.

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?

Two short sentences, front-loaded with the purpose and then the parameter enumeration. Tight and free of filler, though the second sentence reads as a schema footnote rather than an integrated constraint.

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?

No annotations and no output schema, for a tool that creates artifacts on disk and sits among a dozen similar sample generators. Missing the output location semantics, overwrite behavior, and sibling differentiation that an agent would need to call this confidently.

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 compensate. It documents `kind` well, listing both allowed values and describing their sub-parts, which materially exceeds the bare schema. It says nothing about `out_dir` beyond the self-evident name, leaving half the parameters undocumented.

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 names a specific verb and resource ("Create a procedural sample project") and enumerates the two `kind` values with helpful parenthetical detail about what each contains. However, it never distinguishes this tool from the many sibling sample generators (make_biped_sample, make_creature_sample, make_face_sample, make_serpent_sample, make_flier_sample, make_host_sample, make_quadruped_sample), so an agent cannot tell which sample maker to pick.

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?

"to try the tools on" weakly implies a scratch/test scenario, but there is no explicit when-to-use statement, no exclusions, and no guidance pointing to the more specific *_sample siblings. The agent must infer selection from tool names alone.

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

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

No annotations exist, so the description carries full burden. It usefully discloses what the generated asset contains (body parts, orientation, tapered tentacle base), but says nothing about file output, format, or whether files in out_dir are overwritten.

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?

Two sentences, purpose front-loaded, with per-kind detail appended. Tight and mostly waste-free, though the parenthetical part list is dense.

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 no annotations and no output schema, the description should carry the full contract for a file-writing generator. It covers content well but omits destination semantics and output form, leaving gaps for an agent to call 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% and the schema provides no enum, so the description is the only source of valid kind values — it documents both 'fish' and 'tentacle' with content detail, which is real added value. However out_dir is never explained, leaving one of two 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?

States a specific action (generate a procedural sample) tied to a named consumer (rig_serpent), and enumerates the parts each kind yields. This lets an agent place it against the swarm of make_*_sample siblings, though it never names them explicitly.

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?

Usage is only implied via the pairing with rig_serpent; there is no explicit statement of when to generate this sample versus make_sample or make_creature_sample, nor any prerequisites. Adequate but leaves routing to inference.

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

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

With no annotations, the description carries the full burden. It usefully discloses side effects beyond the name: it packs sequence frames, and it copies the skeleton JSON next to the atlas so out_dir becomes a runtime folder. However, it omits overwrite behavior, required input state, and failure modes.

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?

Two tight sentences, front-loaded with the core action and artifact. The parenthetical about sequence frames earns its place by clarifying scope; nothing is padding.

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 description adequately explains the operation and its output structure, which is the main thing an agent needs. But with 7 undocumented parameters, no annotations, and no output schema, the parameter-level completeness is weak for a tool this configurable.

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% across 7 parameters, so the description must compensate. It only alludes to out_dir ('out_dir is a ready runtime folder') and leaves pma, name, scale, max_size, strip_whitespace entirely unexplained. Most parameters remain opaque.

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 (pack) and resource (every image the skeleton references) plus the output artifact (Spine 4.x .atlas + pages). It does not explicitly distinguish itself from siblings like export_runtime, but the purpose is unambiguous.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The mention of 'ready runtime folder' implies a packaging stage, but the agent must infer when this step belongs in a workflow versus export_runtime.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the rendering engine and that IK, physics, and clipping are solved, and names the output artifacts. But it omits whether files are overwritten, where output lands by default, runtime cost, or any auth/version requirements.

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 front-loaded sentence that packs the engine, solved systems, and all three output artifact types with no filler. The parenthetical about IK/physics/clipping is dense but informative.

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?

For a six-parameter tool with no annotations and no output schema, the description covers outputs reasonably well but leaves all input semantics and operational caveats unexplained. An agent could not confidently set fps, size, or out_dir from this.

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% for six parameters, so the description must compensate and largely does not. It implies animation rendering (the 'animations' param) and arguably wireframe mode ('wire'), but fps, size, out_dir, and project are never explained or tied to their effects.

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 (render) and resource (animations) and enumerates the outputs: GIFs, contact sheets, and a setup-pose PNG, plus the rendering engine (spine-core runtime). However, it does not explicitly distinguish itself from sibling render/export tools like export_runtime, validate, or qa_budget.

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 description gives no when-to-use guidance, no prerequisites, and no alternatives. An agent must infer from the name 'preview' that this is a visual-verification step rather than a final export, with no text confirming that.

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

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

With no annotations, the description carries the full behavioral burden. It usefully reveals the shape of the returned data, but never states that this is a read-only, non-mutating query, what happens if the project name is unknown, or whether any permissions/setup are required.

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?

One compact sentence with no filler, front-loading the most important content (the data returned). It is a fragment rather than a full explanatory sentence, but nothing is wasted.

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?

For a one-parameter read tool with no output schema and no annotations, the description does the most important job of enumerating the return payload, which partly substitutes for a missing output schema. It is still incomplete on parameter format and the read-only guarantee.

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% and the single 'project' parameter is undocumented in the schema. The description says only 'of a project', giving no hint whether the value is a name, path, UUID, or handle, so it fails to compensate for the coverage gap.

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 enumerates what the tool surfaces (bones with world head positions, slots, constraints, animations of a project), so an agent can infer this is a project-inspection/read tool, but there is no verb and no mention of what the tool does with that data. It also fails to distinguish itself from inspection siblings such as doctor, inspect_psd, preview, or validate.

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 call this tool, what prerequisites exist (project must already be loaded/imported), or which siblings to use instead for similar inspection needs. The agent must infer usage entirely from the noun list.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose that it estimates draw calls via batch-break logic and that it returns over-budget items plus remediation, implying a non-mutating analysis. It does not state read-only status, required files/permissions, or cost, leaving meaningful gaps.

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?

Front-loaded with the core purpose in sentence one, followed by profile values and metric enumeration. Dense but each clause adds information; the parenthetical about blend-mode/page changes is useful rather than padding.

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?

For a 3-parameter, no-annotation, no-output-schema tool, the description covers the return value well (over-budget items and fixes) and enumerates the profile options. But it leaves 'project' and 'atlas' undocumented and gives no prerequisites, so an agent still lacks what it needs to call it correctly in edge cases.

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 schema documents nothing. The description compensates for one of three parameters by listing valid profile values (mobile_symbol, mobile_banner, mobile_character, desktop) that appear nowhere in the schema. It says nothing about 'project' or the 'atlas' parameter.

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 and resource: it's the performance-budget QA check for mobile web, and it enumerates exactly which metrics it counts (bones, slots, vertices, draw calls). That is far more than a tautology. It stops short of naming how it differs from the sibling 'qa_character', so it isn't fully differentiated.

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 description says what the tool is but never states when to reach for it versus alternatives like qa_character or validate, nor whether it should run before export_runtime or after packing. Usage is only implied by the 'mobile web' framing, with no explicit conditions or exclusions.

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

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

With no annotations, the description carries the full burden. It does disclose the checks performed, the auto-detection of rig type, and the shape of the result ('Returns fix: what to change, joint by joint and clip by clip'), but never states whether the tool mutates anything, permissions needed, or cost/runtime behavior for a diagnostic over potentially many clips.

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?

Purpose is front-loaded, but the single run-on sentence packs parenthetical definitions and the cryptic fragment 'plus mobile_character' that adds noise rather than clarity. Readable but not tight.

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?

A 5-parameter tool with zero schema coverage, no annotations, and no output schema needs a fuller description. It explains the return field but omits fps/crack_threshold semantics, scope of the scan, and any safety or side-effect information an agent needs 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 description coverage is 0%, so the description must compensate, and it only partially does. It clarifies rig_type (listing biped/quadruped/flier/serpent/face and 'auto detects') and implies animations ('clip by clip'), but says nothing about fps or crack_threshold, leaving two of five parameters undocumented.

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 (QA) and resource (character) and enumerates the concrete checks: joint cracks, foot slide, and mobile bone budget. However, it never distinguishes itself from the sibling qa_budget, which appears to overlap with the bone-budget portion of this tool, leaving ambiguity about which QA tool to pick.

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 run this versus alternatives like qa_budget or validate, nor any prerequisite context (does it require a completed rig? a spine-core project?). The inline definitions explain what it detects, not when an agent should choose it.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral trait: art position is preserved during the reparent. However, it says nothing about reversibility, required project state, error conditions, or whether the slot's draw order changes.

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 front-loaded sentence with zero filler; the core action comes first and the important caveat follows immediately.

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?

For a 3-required-parameter mutation tool with no annotations, no output schema, and no parameter descriptions, the one-sentence description leaves too much unspecified — particularly the project parameter and failure behavior.

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 all three parameters are undocumented in structured data. The description names 'slot' and 'bone' conceptually but gives no format (slot name vs. path, bone path vs. identifier) and never accounts for the required 'project' parameter at all.

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 and resource ('Move a slot to another bone') plus the key constraint ('without moving its art'), so the operation is unambiguous. No sibling tool performs slot reparenting, so differentiation is implicit rather than stated.

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 guidance on when to reparent versus other rigging operations, no prerequisites (does the project need to be open? must the bone already exist?), and no mention of alternatives such as rig_transform or add_bones.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the built bone hierarchy, floor-pinned foot IK vs chest-riding arm IK, the single weighted mesh per joint, error behavior for missing layers ('a clear error listing them'), and the concrete effects of breathing, look_at, and secondary_motion. It omits whether an existing rig is overwritten and any permission/side-effect caveats, so not quite a 5.

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?

Front-loaded with purpose and prerequisite in the first sentence, then layer recognition, then the build structure, then the option effects. It is long and dense, but nearly every clause carries actionable information (layer names, IK placement, error behavior), with little filler.

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?

For a high-complexity, 9-parameter, 0%-schema-coverage tool with no output schema, the description supplies the layer contract, build topology, and option semantics an agent needs to call it correctly. Gaps remain around the 'detail' parameter and overwrite/return behavior, but the core is well covered.

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% across 9 params, so the description is the only source of meaning and it explains most of them: facing (auto/right/left), breathing (4s loop), look_at, look_lag_frames (head lag at 30fps), spine_twist, and secondary_motion. It leaves 'detail' and 'meshes' effectively unexplained, so it compensates well but not completely.

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 and resource ('Rig a biped from its PSD layers') and immediately names the prerequisite (import_psd origin="bottom" first) plus the 'in one call' convenience framing. An agent can tell it apart from rig_quadruped, rig_serpent, rig_flier, and rig_creature without opening any schema.

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 clear operating context: the required import_psd prerequisite, the accepted layer naming conventions, and which layers are required vs optional. It does not, however, name an alternative tool or state when-not to use it (e.g., vs rig_creature or make_biped_sample), which keeps it short of a 5.

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

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

With no annotations, the description carries the full burden and does disclose meaningful traits: loops close exactly, one-shots end on the setup pose, the artist's setup never moves, and the result reports bones/slots/constraints plus qa.budget(mobile_character). It omits what project/file state is mutated, whether seed makes runs deterministic/reproducible, and any idempotency guarantees.

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?

Front-loads the core action and layer convention, then organizes per-kind behavior into an indented, scannable list. It is long and duplicates detail that kind="" would return at runtime, but nearly every line carries decision-relevant physics/gait/event information rather than filler.

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?

For a complex 8-kind generator with no output schema, the description is largely self-sufficient: it details clips, physics, events, loop/one-shot end states, and what the result reports. Gaps remain around prerequisites, which assets/skeleton it writes to, and the meaning of seed/project/exaggerate.

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% across 6 params, so the description must compensate and only partly does: it explains kind (with a '' enumeration shortcut), clips (per-kind listings) and some options keys (options.law="area"). It says nothing about seed, project, or exaggerate, leaving a third of the parameters undocumented for a tool with no schema-level help.

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+resource+scope: 'Rig a non-humanoid creature from its layers and build its clip set', immediately distinguishing it from the humanoid rig_biped and naming the sibling rigs it composes (rig_quadruped, rig_serpent, rig_flier). An agent can identify exactly what this tool produces without opening the schema.

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 clear operating context: kind="" enumerates every kind with its layer convention, clips and options, which is a concrete entry point, and the 'non-humanoid creature' framing implicitly separates it from rig_biped. However it never explicitly says when to call it instead of using the composed rigs (rig_quadruped/rig_serpent/rig_flier) directly, nor states prerequisites such as an imported PSD.

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

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

With no annotations, the description carries the full burden and delivers unusually rich behavioral detail: it enumerates what gets constructed (turn, eyes, brows, mouth/jaw, cheeks, hair, clips, events) and the mechanics behind each. However, for a mutation tool it never says whether an existing rig is overwritten or duplicated, nor what the call returns or whether it is safe to re-run, which are meaningful gaps.

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?

Purpose is front-loaded correctly, and the layer-name list, clip list, and event names earn their place. But the build/clip paragraphs descend into implementation minutiae (Poisson micro-saccades, scaleX = scaleY^-1/2, 80 ms down / 160 ms up) that add bulk without helping an agent decide or call the tool, making it denser than needed.

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?

For a 12-parameter, no-output-schema, no-annotation tool of high complexity, the description is largely sufficient: it covers layer recognition, constructed parts, clips, events, and the most consequential parameters. It falls short on undocumented parameters and on the absence of any statement about return values or overwrite behavior.

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% across 12 parameters, so the description must compensate. It explains project (convention query), clips (default all), parent (default juice_core or root), spine (joins look_at two frames after the head), talk_text (lipsync source), and turn_range (turn range scale). It leaves seed, pitch, intensity, features, hair_physics, and idle_duration entirely undocumented, so compensation is only partial.

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 states a specific verb (rig), resource (a whole face), and scope (from named layers in one call, then build its clips). It is clearly distinguishable from siblings like rig_mesh, rig_ik, rig_turn, and rig_biped, which each target a narrower or different resource.

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 makes the trigger condition concrete: you need layers following the documented naming convention, and face/head is REQUIRED while missing parts are skipped and reported. It also documents a query mode (project="" returns FACE_LAYERS without changing anything) and notes it internally builds rig_turn as the base layer, implying it supersedes that sibling. It never states explicit when-not-to-use or prerequisites such as an open project.

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

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

With no annotations, the description carries the full burden and does unusually well: it discloses layer naming, physics on strands and primaries, the flap phase model, per-clip behavior, and a seamless land -> perch guarantee. It still omits destructiveness/reversibility, permission or project prerequisites, and return/error 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?

The content is dense and mostly substantive, but it opens with a near-title restatement and the long run-on 'flap' paragraph buries the tool's primary action. Information is present but not cleanly front-loaded.

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?

There is no output schema and no annotations, so the description must be self-sufficient; it richly covers rig anatomy and clip behavior but leaves key inputs (project, parent, cycles, flap_hz defaults) unexplained and never states what the tool returns or whether it overwrites an existing rig. Adequate but with clear gaps for an 11-parameter construction tool.

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% across 11 parameters, so the description must compensate; it does meaningfully for amp ('[shoulder, elbow, hand] degrees (default 40, 15, 20)'), lag (phase degrees behind), downstroke (58% of the beat) and clips (named list). It leaves project, parent, name, cycles and flap_hz without semantic explanation, so the coverage gap is only partly filled.

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 begins 'Bird / flier (front view, wings to the sides)' and details the resulting rig structure and animation clips, so it is clear the tool builds a flier rig. However, it never states the action explicitly (e.g. 'creates a rig') and does not differentiate itself from siblings like rig_biped, rig_quadruped or rig_creature beyond the name.

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 text describes what the rig contains and how clips behave, but gives no when-to-use guidance, no prerequisites (e.g. whether a project/skeleton must exist first), and no routing to alternatives such as make_flier_sample or rig_creature. Usage is only implied by context.

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

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

With no annotations, the description carries the full burden and does disclose meaningful side effects: a target bone is created at the chain tip unless `target` names one, the default bend follows the setup pose, and target parenting depends on whether juice bones exist. It omits idempotency (what happens on re-run), failure modes, and permission requirements.

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 compact sentences, front-loaded with the core identity before the conditional behavior. Nearly every clause earns its place, with no padding.

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 8-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage requires far more than this. Several tunable parameters are left entirely unexplained, and there is no guidance on project scoping or re-invocation.

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% across 8 parameters, so the description must compensate and only partially does: it gives an example for `bones`, explains `target`, and implies `bend_positive` and `target_parent` behavior. `mix`, `stretch`, `softness`, and `project` are undocumented everywhere.

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 operation on a specific resource: '1- or 2-bone IK' with the bones chain as the operand and an example. It clearly establishes the rigging-domain purpose, though it never names a sibling it contrasts with (e.g. add_chain, rig_transform).

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?

No statement of when to choose IK over alternative rigging tools like add_chain or rig_transform, nor any prerequisites or constraints. Use is only implied by the tool name and the IK-domain content.

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

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

With no annotations the description carries the full burden and delivers real behavioral detail: outline traced from alpha, simplified without clipping art, denser vertices at joints, conforming Delaunay valid for Spine's importer, and weights diffusing from bone *segments* so they don't leak across gaps. It does not disclose side effects such as whether an existing mesh is overwritten, permission requirements, or failure modes for an 11-parameter mutation.

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 core purpose is front-loaded in the first sentence and the parameter notes are compactly formatted. The algorithm paragraph is slightly verbose but every clause conveys usable behavior rather than filler.

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?

For a no-annotation, no-output-schema, 11-parameter mutation tool, the definition explains the mesh-generation behavior well but leaves most parameters undocumented and never states whether existing meshes/weights are replaced or what the tool returns on success. It is adequate but has clear gaps for correct invocation.

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% across 11 parameters, so the description must compensate, and it documents only bones, detail, and smooth (plus auto_bones via the bones note). Key tuning parameters such as pad, attachment, min_weight, max_vertices, and max_influences are left entirely unexplained in both schema and description, so an agent cannot reason about cost/quality tradeoffs.

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 line gives a specific verb+resource+output: turn a slot's region into a clean contour mesh (or re-mesh one) with bone-heat weights. It is clearly distinguishable from skeleton-focused siblings like rig_biped/rig_ik/add_bones. It stops short of naming which sibling to prefer for related tasks.

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?

Usage is only implied: creating a mesh from a slot's artwork, or re-meshing an existing mesh. There is no explicit when-to-use vs when-not, no prerequisites, and no named alternative among the many rig_* siblings. The parenthetical '(or re-mesh a mesh)' is the only usage distinction offered.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result is runtime secondary motion with no baked keys, and explains the taper effect down a chain. However, it omits mutation semantics, such as whether existing constraints are overwritten, permission requirements, reversibility, or side effects.

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 description is compact and front-loads the core concept before listing presets and overrides. Every sentence carries information, though the phrasing is slightly cryptic and could be clearer without adding length.

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?

For a 5-parameter mutation tool with 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It omits explanations for required parameters 'bones' and 'project,' provides no usage conditions relative to siblings, and leaves behavioral safety aspects unaddressed.

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 compensate. It explains the preset options, the behavioral effect of taper, and the overridable physics fields, adding genuine meaning beyond the schema. It does not, however, describe the 'bones' array or the 'project' parameter, leaving two of five parameters undocumented.

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 names a specific resource ('Spine 4.2 physics constraints') and a key behavior ('runtime secondary motion, no baked keys'), so the domain is clear. However, it lacks an explicit verb such as 'apply' or 'create,' making the exact action slightly ambiguous. It also does not distinguish this tool from the sibling 'secondary' or other rigging tools.

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 guidance on when to use this tool versus alternatives like 'secondary' or 'squash_stretch.' It lists preset values and override fields, but these are configuration details rather than usage conditions. An agent receives no when-to-use or when-not-to-use criteria.

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

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

With no annotations, the description carries the full behavioral burden and does so extensively: it explains required vs optional layers, case-insensitive naming conventions, missing-part handling, leg_type construction differences, generated bone structures, physics strand behavior, exact loops vs one-shot poses, event emissions, and what seed/exaggerate control.

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 description is long but front-loaded with the core action and structured into layers, leg_type, and clips sections. Given the complexity of quadruped rigging, most detail earns its place, though the density and length could make rapid scanning harder for an agent.

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?

For a high-complexity rigging tool with no output schema and no annotations, the description is highly complete regarding layer requirements, leg types, generated clips, events, and parameter effects. The main omission is any explanation of the required project input, leaving a gap in the call contract.

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 compensate for all seven parameters. It documents clips, speeds, seed, leg_type values, exaggerate, and implies physics through the physics-strands note, but it never explains the required 'project' parameter or clarifies the exact effect of the physics boolean.

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 states a specific verb and resource: 'Rig a four-legged animal from its layers and build its clips in one call.' It clearly distinguishes this tool from sibling rigging tools for bipeds, serpents, fliers, and generic creatures by specifying the quadruped layer set and leg types.

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 clear context for when the tool applies (four-legged animal from existing layers, with required and optional part lists) and describes default clip generation. However, it does not explicitly name alternatives such as rig_creature or make_quadruped_sample or state when not to use this tool.

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

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

With no annotations, the description carries the full burden and does so well: it discloses generated clips (swim, idle_float, turn, reach), emitted events (sfx_swim/sfx_turn/sfx_reach), the exact-loop/cycles behavior, and that clips merge by name into existing ones. Remaining gaps (permissions, what project objects are created, reversibility) are not addressed but the mutation surface is unusually well described.

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 front-loaded with the correct one-line classification, but the body leans heavily on physics exposition (the y(s,t) formula, Strouhal number, thrust surge) that is only marginally relevant to tool selection. Information density is high, but the text is a wall of unbroken prose with no parameter listing or structure.

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?

For a complex rig tool with no annotations, no output schema, and 17 mostly-undocumented parameters, the description covers modes, clips, events, layer naming, and key physics controls adequately. It does omit the meaning of side/slot/parent and does not state what it returns or where the rig lands in the project.

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% across 17 params, so the description must compensate, and it explains a large fraction: amp (fraction of length), cycles (beats), speed (body lengths/s), head_amp, root_end (auto for tentacle), exaggerate, wavelength, mode, clips, and reach ([x,y] in the tentacle frame). It leaves side, slot, parent, n_bones, turn_angle, name, and project unexplained, so it is thorough but not complete for a 17-parameter tool.

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 line states a concrete resource and scope: 'ONE long chain along the body layer with a travelling wave' for fish/eel/snake/dragon/tentacle bodies. It clearly positions itself against the strand-based fin constructs it mentions. It stops short of naming competing siblings (rig_strand, rig_creature) to route the agent explicitly.

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?

Usage is implied through required layer naming ('body (required...)'), the mode switch, and clip names, but there is no explicit when-to-use/when-not guidance or comparison to sibling rigging tools like rig_strand or rig_creature. The agent must infer that this is the tool for a single continuous body chain.

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

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

No annotations are provided, so the description carries the full burden. It reveals that the chain follows the part's centre line and that the mesh is heat-weighted, which is useful. However, it doesn't state permissions, whether it modifies the part or creates new objects, what happens on re-run, or the interaction between physics preset and existing rig data. Given the lack of annotations and no output schema, this leaves substantial behavioral gaps.

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?

Very compact: one sentence plus a clipped shorthand line for defaults. Information is front-loaded and terse. The shorthand line is somewhat cryptic ('root_end: auto(top)|top|bottom|left|right.'), but not wasteful.

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?

A 7-parameter rigging tool with no annotations, no output schema, and 0% schema description coverage should explain much more: defaults for slot/project, effect of n_bones and detail, what 'parent' does, and the lifecycle/side effects of running the rig. As written, an agent would have to guess on several parameters.

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 compensate. It partially explains root_end (values: auto, top, bottom, left, right) and physics (preset name or 'none'), which mitigates the two most ambiguous params. But slot, project, detail, n_bones, and parent are left entirely undocumented. With 5 of 7 params unexplained at 0% schema coverage, this is inadequate.

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+resource: building a bone chain, heat-weighted mesh, and physics for a strand-like part (hair lock/cape/ribbon/tail). It distinguishes itself from siblings like add_chain, rig_mesh, and rig_physics by declaring it does all three in one call, which is useful differentiation. It names concrete target parts, so the agent knows the domain.

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 description implies when to use it (strand-like parts) but gives no explicit when/when-not or pointers to alternatives. It slightly nods to alternatives by emphasizing 'in one call', hinting that add_chain/rig_mesh/rig_physics exist separately, but doesn't state the tradeoff. Adequate but thin.

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

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

With no annotations, the description carries the full behavioral burden, yet it does not state whether this mutates existing constraints, whether it is reversible, what permissions it needs, or how conflicts/errors are handled. It discloses some transform-constraint semantics ('bones copy target's transform by the mixes'), which is useful, but this is far short of what an unannotated mutation tool requires.

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?

Two short sentences, front-loaded with the core transform-constraint behavior, so it is not padded. But the extreme compression produces jargon-heavy text ('the mixes') that is underspecified rather than genuinely concise for a 12-parameter tool.

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?

For a 12-parameter mutation tool with 0% schema description coverage, no annotations, and no output schema, the description is too sparse. Critical details such as what the mixes control individually, what offsets accepts, and side effects on existing constraints are absent, leaving the agent under-informed to call 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% across 12 parameters, so the description must compensate. It surfaces the key concepts (bones, target, mixes, local, relative), implicitly covering several params, but leaves offsets, mix_shear_y, mix_scale_x/y and the null-default behavior of the y-mixes undocumented. It explains roughly half the surface and omits the rest.

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 names a specific action ('bones copy target's transform') and identifies the construct being created (a transform constraint), so the agent can infer this is a constraint-setup tool. However, the dense jargon and lack of contrast with the many sibling rig_* tools (rig_ik, rig_mesh, rig_physics) leaves it only partially distinguishing. Adequate but with clear ambiguity for selection.

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 use this tool versus rig_ik, rig_mesh, or other rig_* siblings, nor any prerequisites. The second sentence clarifies a behavior (local+relative adds the target's local offset) but describes how the tool works, not when to reach for it. No exclusions or alternatives are given.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: face_slot is converted to a mesh, a `turn_test` animation is added as a side effect, and feature depth sign conventions are explained. It stops short of stating whether existing mesh/animation data is destroyed or what permissions/project state are required.

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?

Front-loaded with the core concept, then a compact behavioral note and a dense but useful feature-depth table. Some sentence fragments ('features {slot: depth}: nose 1.25...') trade grammar for density, but nearly every token carries information.

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?

For a 7-parameter, nested-object tool with zero schema coverage and no output schema, the description explains the conceptual model and the features map well but leaves half the parameters (turn_range, swap_pairs, pitch, head_bone) undefined. An agent could call it, but would be guessing on several arguments.

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 compensate, and it does strong work on the hardest parameter: `features {slot: depth}` with concrete example values and the negative-depth convention for parts behind the head. But face_slot is only incidentally explained, and head_bone, project, pitch, turn_range, and swap_pairs get no semantics at all.

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 and resource: rigging a 2.5D head turn driven by one control bone (turn_ctrl). The mesh-behavior sentence ('middle travels with the control while its outline stays pinned') pins down exactly what the tool produces, distinguishing it from siblings like rig_face or rig_mesh.

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 final sentence gives post-rig usage ('Animate turn_ctrl's translate to turn') and the features list implies the slot-to-depth input convention. However, there is no explicit when-to-use vs alternatives routing (e.g. versus rig_face or rig_biped head handling), so usage is only implied.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that chains follow each layer's centre line, that the chain starts at the body-overlapping end and hangs from the nearest body bone, and that presets override defaults with n_bones 0 meaning 'use the preset'. It omits preconditions and whether existing chains are overwritten, but the mechanical behavior is unusually well specified for a mutation tool.

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 front-loaded with the core purpose and the routing table is substantive rather than filler, so little is wasted. But the telegraphic slash-lists, arrow notation and run-on sentences make it hard to parse, and the preset wording ('presets {slot: ...} overrides; n_bones 0 = the preset's') is compressed to the point of ambiguity.

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?

For a complex multi-step rigging operation with 7 parameters at 0% schema coverage and no output schema, the description is far richer than typical but still leaves gaps: two parameters (detail, exclude) are unexplained, preconditions are unstated, and the expected result of the call is not summarized.

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 compensate and partially does: it explains n_bones (0 = preset's), presets ({slot: preset} overrides) and by_shape (catch-all for any elongated layer, and the slot routing makes 'slots' inferable). But 'detail', 'exclude' and 'project' are never mentioned, leaving three of seven parameters entirely undocumented.

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 states a specific composite action: find strand-like layers and give each a chain along its centre line, a weighted mesh and Spine physics. The phrase 'in one call' implicitly distinguishes it from the granular siblings (add_chain, rig_mesh, rig_physics, rig_strand), though it never names them explicitly, and the bare name 'secondary' carries no meaning on its own.

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?

Usage is conveyed indirectly through the layer-name routing table (hair/lock → hair, cape/cloak → cloth, etc.) and the note that by_shape catches any other elongated layer. However there is no explicit statement of when to choose this over add_chain/rig_mesh/rig_physics, no preconditions (project must already have a rig), and no when-not guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses that keys land on an inserted carrier bone `ss_<chain[0]>` at the chain base, that the artist's bones and keys are never touched (a strong non-destructiveness guarantee), and that repeated calls multiply. What it doesn't cover: any permission/side-effect or failure behavior is left implicit.

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 core purpose is front-loaded in the first clause, and the following sentences lay out the spring profile, volume math, and carrier-bone behavior without padding. It is dense and jargon-heavy, but every sentence carries information.

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?

For a complex 11-parameter animation tool with no annotations and no output schema, the description explains the mechanism and key-value semantics well but omits usage context, several parameter meanings, and any return/behavioral expectations. Adequate but with clear gaps.

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% across 11 parameters, so the description must compensate and only partly does. It gives real semantics for `squash` (<1 vs >1), `overshoot`, `volume` (3d vs area transverse formulas), and constrains `chain`/`clip`/`start`, but says nothing about `hz`, `intensity`, `duration`, `event`, or `project`, which remain undocumented in both schema and prose.

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 states a specific verb and resource: volume-preserving squash & stretch applied to any bone chain, keyed into `clip` from `start`. An agent can grasp the operation immediately. It does not, however, distinguish this from plausible siblings like `secondary`, `juice_apply`, or `add_keys`, so it stops 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?

There is no explicit statement of when to choose this tool versus alternatives such as `secondary` (also a procedural secondary-motion tool) or `add_keys`. Mechanics are described in depth, but routing guidance is absent, leaving the agent to infer from the mechanism alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses what is checked and that the runtime check is conditional on Node availability, but does not say whether validation is read-only or mutating, whether it fails fast or returns a report, what constitutes pass/fail, or what happens when Node is absent (skipped vs. failed). For a validator this omission leaves real uncertainty.

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?

One dense sentence that front-loads the structural checks and then the runtime check. Every clause carries real information; the only minor cost is the parenthetical field lists, which are slightly crammed but still readable.

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 no annotations, no output schema, and 0% parameter coverage, the description must do more work. It covers scope well but omits parameter meaning, result semantics, and the behavior when Node is unavailable, leaving gaps an agent would need to resolve before invoking confidently.

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 both parameters are undocumented in the schema. The description explains the underlying runtime-check behavior conceptually but never mentions the 'runtime_check' parameter or its default (true), nor what 'project' should reference. Two undocumented params with no compensating description merits a 2.

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 states a clear verb (validate) and enumerates the specific structural dimensions checked (references, weights, triangulations, UV range, curves, events), then adds the runtime loading check. This is far more informative than the bare tool name and distinguishes it from quality-oriented siblings like qa_budget and qa_character. It falls short of 5 only because it doesn't explicitly contrast itself with those siblings.

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?

No guidance on when to use this tool versus the qa_budget, qa_character, or doctor siblings, nor any prerequisites. The agent is left to infer that this is a validation step, not e.g. a runtime export or performance budget check.

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