spine-mcp

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

Substantial value beyond the annotations: it discloses the validate-first workflow, automatic backup, re-export, post-import verification, and rollback on mismatch, plus the 4.3 version constraint. This is exactly the safety and side-effect context an agent needs for a mutating operation.

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 front-loaded: the core action comes first, then workflow, then naming rule, then payload conventions. The final clause is telegraphic, but every sentence contributes 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 10-parameter mutating tool with a nested object, no output schema, and sparse schema descriptions, key gaps remain: what dry-run returns, what the editor enum options mean, and what stagingPath/loopAnimations do. The workflow and payload conventions it does cover are strong, but the definition is not fully self-sufficient.

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 only 20% across 10 parameters, so the description carries a heavy burden. It supplies real semantics for the animation payload (times in seconds, rotate uses `value`, bezier curve is absolute per channel) and touches on `replace`, but leaves `editor` modes, `stagingPath`, `loopAnimations`, `skeleton`, and `allowUpgrade` 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 description opens with a specific verb and resource: adds one Spine 4.3 JSON animation to a .spine project, including the version constraint. It implicitly separates itself from bulk importers like spine_import_layers by saying 'imports only this animation', but never names a sibling alternative directly.

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 clearly delineates the dry-run path (validate against skeleton) from the apply path (back up, import, re-export, verify, roll back), which is the key usage decision. It also gives a naming rule: existing names require replace, and a new name is preferred. No explicit comparison to spine_transfer_animation or spine_derive_animation.

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?

readOnlyHint=true already establishes the safety profile, and the description correctly stays consistent with a read-only audit. Beyond that it discloses two useful traits: per-skeleton granularity of results and that strict mode escalates validation warnings to failures. It says nothing about runtime cost on large folders, file-count/scan-depth limits, or how errors like unreadable files are reported.

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 dense sentences, front-loaded with what is audited and what the output looks like, with the strict-mode caveat parenthesized and the usage context last. Every clause carries information; the telegraphic phrasing ('Validate, rig QA and budget') is compact rather than 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?

With no output schema, the description rightly specifies the result shape (one ok/fail row per skeleton) and covers the strict flag, which is the highest-risk behavioral nuance. For a five-parameter, nested-schema audit tool it still leaves the page-size parameter, the filtering parameter, and the budget-limit fields 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 only 20% and there are five parameters including a nested limits object, so the description must carry more weight. It does explain 'strict' (validation warnings fail too) and implies the 'folder' scope and the existence of budget limits, but 'max' (1-500) and 'onlyFailed' are never mentioned and the seven nested budget fields are undocumented beyond the schema's 'Device budget for pass/fail'.

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 specific verbs (validate, rig QA, budget), a precise resource scope (every .spine and skeleton .json under a folder), and the result shape (one ok/fail row per skeleton). The folder-level batch scope implicitly separates it from single-file siblings like spine_validate, spine_rig_qa and spine_budget, though none are named.

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?

"For release checks and CI" gives a clear usage context, so an agent knows the intended scenario. However, it never states when to use a single-file sibling instead (spine_validate, spine_rig_qa, spine_budget) or any exclusions, leaving the choice among near-duplicate siblings 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?

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds the substantive behavior: dry-run verification before any write, post-write validation plus rig QA and test-pose renders, and the explicit guarantee 'Never overwrites.' Those details materially change how an agent would sequence the call. It omits prerequisites (e.g., whether a Spine editor project must be open) and what the dry-run report contains.

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 and compressed to a few dense clauses with no filler sentences, and the mode-based structure is a sensible skeleton. But the telegraphic style (e.g. 'hidden lids rigged shut-collapsed', 'nothing written; riders: ...') crams unrelated ideas into semicolon chains, making it harder to parse than a slightly longer explicit form would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 17-parameter, write-capable pipeline tool with no output schema and 12% schema coverage, the description covers workflow but not the parameter surface, the shape of the dry-run/QA results, or runtime prerequisites. The agent can grasp the intended flow but cannot confidently supply most arguments without trial and error.

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 only 12% across 17 parameters, so the description is required to compensate and largely does not. It explains the semantics of roughly five knobs (bones with joints/tips, mesh tracing, weights, two-bone ik, riders = one character sitting on another, rigFrom = an approved rig's joints) but leaves psd, parts, layout, skeleton, output, scale, origin, density, blend, targetHeight, and the apply flag undocumented. With two-thirds of the surface area undefined, an agent is left guessing on numerics and file inputs.

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 — rigging a starting skeleton/project from a layered PSD or parts+layout — and enumerates concrete outputs (bones at joints, traced meshes, weights, optional two-bone IK). It cleanly splits the tool's two operating modes (no bones vs. with bones), which lets an agent tell the sub-behaviors apart. It never names the closest sibling (spine_rig_edit) for editing an existing rig, so sibling differentiation is implied 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 mode split is explicit guidance: with no bones supplied it only *suggests* a skeleton and writes nothing, and the result is meant to be passed back as bones; with bones supplied it dry-runs with checks first and only writes when apply is set. That is clear when-to-use framing for the tool internally. It gives no explicit exclusions relative to alternatives such as spine_rig_edit or spine_import_layers, so an agent must infer which tool to pick.

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 readOnlyHint already declaring this a safe read, the description earns credit for disclosing what is actually returned (worst values annotated as animation@time), and for the performance caveat that draw-call estimation requires an atlas or pack and costs roughly 4 seconds. That cost note is exactly the kind of trait annotations cannot express. It stops short of saying how limits produce pass/fail results or whether failures are errors or flags.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is compact and front-loads the metric inventory, but it is written as a semicolon-chained run-on mixing output fields, limit semantics, and a timing caveat. The density costs readability, and 'constraint costs' and 'animation@time' are jargon that would benefit from one clarifying clause.

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 tool with a nested limits object and no output schema, the description covers the measured metrics and the pass/fail intent but leaves the result structure and the non-obvious parameters (fps, skin, skeleton) unexplained. An agent could call it, but would be guessing about how limits are reported.

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 43%, so the description must compensate and only partly does: it signals the role of 'limits' (pass/fail thresholds) and the atlas/pack interplay for draw calls. The fps, skin, and skeleton parameters receive no explanation anywhere in narrative form, and the required 'input' format list lives only in the schema.

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 metrics over setup pose and every frame) and enumerates the measured quantities, plus the distinguishing 'limits for pass/fail' capability. It never names the sibling spine_measure or spine_audit, so the boundary with those tools rests on the reader inferring that 'budget' means threshold-checking.

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: run it to obtain frame-by-frame metrics and evaluate them against limits. The only explicit conditional guidance is 'draw calls need atlas or pack (~4 s)', which is a prerequisite rather than a when-to-use statement. Nothing tells an agent when to prefer this over spines_measure, spine_inspect, or spine_timing.

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?

readOnlyHint=true already tells the agent this is a safe analysis operation. The description adds genuine value by disclosing the result contents and sort order ('biggest first') and by flagging that contact sheets are optional, but it says nothing about cost, limits, or failure modes when the two clips are incompatible (different skeletons, mismatched lengths).

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 telegraphic sentence, front-loaded with the operation and then the reported fields; nothing is redundant. The colon-and-semicolon listing style is dense but readable and well ordered.

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 output schema, the description usefully enumerates return contents, which is the right call for an 8-parameter tool. However, half the parameters remain unexplained and there is no note on the ~8s render cost beyond the schema's own hint, so an agent still has to inspect the schema 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 only 50%: b, fps, bones, and limit are undocumented in the schema, and the description does not explain any of them — one can guess b is the second clip from 'A/B', but bones/limit/fps semantics and their interaction are entirely unstated. The description's mentions of per-bone changes and contact sheets loosely map to bones and render but add no parameter guidance.

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 concrete operation — an A/B comparison of two animations of one skeleton — and enumerates what the comparison reports (duration, motion ratio, per-bone deltas, timing structure). That distinguishes it from neighbors like spine_measure or spine_timing, though it never names those siblings 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 by 'A/B of two animations of one skeleton'; an agent can infer this is the diff tool, but there is no explicit when-to-use versus spine_measure, spine_timing, spine_mix_check or spine_motion_visual, and no stated preconditions (e.g. both animations must live in the same skeleton/file).

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?

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description earns credit for adding that the write is validated, backed up and verified, and that it is a dry-run unless `apply` is set. That safety/dry-run disclosure is real value beyond the structured fields, though it doesn't say what happens if `name` collides with an existing animation or how the backup can be restored.

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 core behavior front-loaded and no filler; the parenthetical keeps the safety details compact. The trailing doc-link fragment is terse but arguably wastes space since it points to content not included.

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?

This is a complex mutation tool: 11 parameters, an 18-way oneOf op vocabulary, no output schema, and 18% schema description coverage. Deferring all op semantics to an external anchor leaves the definition incomplete for correct invocation, and it also omits what the tool returns and how failures/validation errors 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?

Wrong scale: schema description coverage is 18% across 11 parameters, so the description must compensate. It only clarifies `apply` (dry-run semantics) and the ordering of `ops`; `project`, `source`, `name`, `skeleton`, `editor`, `stagingPath`, `replace`, `allowUpgrade` and `loopAnimations` are left entirely to an undocumented schema, and the 18 operation variants are delegated to an external 'docs/USAGE.md#derive-operations' anchor the agent may not be able to read. A 2 reflects that the description adds almost no parameter meaning.

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: 'Builds a new animation from an existing one' with ops applied in order. It also positions itself relative to a sibling by saying the result is added 'like spine_add_animation', which helps an agent distinguish derivation from plain creation, though it never names the sibling it should be preferred over (e.g. spine_generate_animation, spine_transfer_animation) 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?

Gives the operating context ('ops applied in order on the server', 'dry-run unless apply') but never states when to choose this over spine_add_animation or spine_generate_animation, nor any prerequisite such as the source animation existing or the project being open. Usage is implied through the sibling reference rather than spelled out.

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?

The readOnlyHint annotation establishes that the operation is non-mutating, while the enumerated checks add useful detail about what is inspected. The description does not explain what happens when a check fails or whether results include remediation guidance.

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-load the inspected components and then state the usage trigger. There is no redundant, promotional, or unnecessary wording.

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 zero-parameter, read-only diagnostic, the stated scope and troubleshooting trigger are nearly sufficient for correct selection and invocation. With no output schema, a brief note about the diagnostic result or next steps, plus disambiguation from related status tools, would make it more 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?

The tool has no parameters, so there is no argument syntax or semantics requiring clarification. The zero-parameter baseline applies, and the description appropriately presents it as a standalone check.

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 gives a concrete diagnostic scope: the Spine CLI, editor version and license, spine-core version, and work folder. It does not explicitly distinguish this setup check from related siblings such as spine_status or spine_editor_status.

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?

"Run first when something fails" provides an explicit troubleshooting trigger and ordering guidance. It offers no when-not guidance or alternatives for routine status checks versus deeper validation or auditing.

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 readOnlyHint=true already declaring safety, the description adds real context that writes go to a verified staging copy while the editor is open — a behavioral constraint not in the annotations. However, it never says what the check actually reports (boolean, list of pending items?) and the 'animations confirms each one' clause is too compressed to convey the verification behavior reliably.

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 short, but the telegraphic 'With project: ...' construction and run-on second sentence trade clarity for brevity. The lead question is front-loaded effectively; the rest reads as notes rather than a structured explanation.

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?

Four optional parameters, no output schema, and only 25% schema coverage demand more than this. Neither the return value nor the role of 'skeleton' and 'staged' is explained, so an agent cannot confidently decide how to call it or interpret the result.

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 only 25%, so the description needs to carry parameter meaning, and it largely fails. 'project', 'animations' and implicitly 'staged' are gestured at in one ambiguous clause, while 'skeleton' is never mentioned anywhere, and the phrasing 'With project: what still waits in the staging copy' does not make clear which parameter controls which behavior.

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 frames the tool as a question ('Is a Spine editor window open (and likely on this project)?') and adds two vague modes ('With project: what still waits in the staging copy', 'animations confirms each one after Import Project and a save'). The gist — an editor/import status check — is inferable, but it never states cleanly what the tool returns or reports, and it is not sharply distinguished from siblings like spine_status, spine_doctor or spine_reimport_diff.

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: 'animations confirms each one after Import Project and a save' suggests it is called post-import to check what remains staged. There is no explicit when-to-use, no when-not-to-use, and no named alternative among the many spine_* status/validation 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?

Adds substantial behavior beyond the annotations: temp-folder verification with spine-core, no overwrite unless flagged, project left untouched, expected ~3-5 s runtime, and the report contents (page fill, texture memory). This is consistent with destructiveHint=false since the project is untouched and output is opt-in. It does not say what happens to partially written output on failure.

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 tight sentences, front-loaded with the verb and artifact types, then safety behavior, then the sweep alternative. Dense but every clause carries information; no 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 20-parameter mutation tool with no output schema, it covers the core flow, safety, and the headline return fields (page fill, texture memory), which is more than most. Still, the majority of atlas/quality knobs are unexplained, so an agent cannot reason about them without opening the 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?

With 30% schema coverage across 20 parameters, the description must carry a lot, and it only clarifies format, scales, atlas, outputDir/overwrite, and that sweep relates to atlas settings. High-impact parameters (pot, maxSize, padding, packing, preset, atlasPerSkin, nonessential, editorVersion, premultipliedAlpha) get no added meaning beyond their schema names, so compensation is 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?

States a specific verb (exports) and concrete resources (JSON/.skel runtime files plus packed atlas) with the key side effect (verification before copy). It distinguishes itself from spine_export_json only implicitly through the 'JSON and/or .skel plus a packed atlas' phrasing rather than by naming the 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 sweep mode is given clear usage semantics ('ranks atlas settings by texture memory and pages, writing nothing'), and overwrite behavior is stated. However, there is no explicit guidance on when to choose this over spine_export_json or the preset-based workflow, so an agent must infer the routing itself.

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?

Annotations only declare readOnlyHint=true, and the description usefully adds the crucial side-effect location ('in the cache folder, never next to the project') plus the conditional re-export rule. That is genuine behavioral context beyond the annotation, though it does not say what files are produced or what the response contains.

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 key constraint (cache folder, not next to project) in parentheses; every clause carries information and nothing is redundant.

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 output schema and no annotation detail, the description covers destination and caching but leaves the return value, produced file naming, and the 'refresh' parameter's effect unspecified — enough to attempt a call, not enough to predict results.

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 two parameters. The description never explains the required 'project' argument (path? name?) or the 'refresh' boolean; the 're-exports only when the project changed' phrase loosely implies refresh semantics but does not state what setting refresh=true does.

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 ('Exports a .spine project's skeletons to JSON') and specifies the output location, which clearly separates it from generic siblings like spine_export. It does not, however, explicitly contrast itself with spine_export or spine_showcase, so an agent must infer which export variant applies.

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?

'Re-exports only when the project changed' implies cached/conditional behavior and hints at when a re-run is unnecessary, but there is no explicit when-to-use guidance or named alternative (e.g., spine_export) for non-JSON needs.

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?

Goes well past the annotations: it discloses the pipeline (validated, backed up, verified), the safe default ("dry-run unless apply"), and failure behavior ("Missing bones/slots: suggestions by name, nothing written"). Residual gaps are what happens on a name collision and the role of the `replace`/`allowUpgrade` flags.

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, safety pipeline, and error behavior, then a compact one-clause-per-type catalog; almost nothing is wasted. It is telegraphic to the point of opacity in places ("followers later; restStart"), which costs a little readability but not much 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 21-parameter tool with twelve nested option objects, 10% schema coverage and no output schema, the description covers the dispatch dimension but not the per-type option vocabulary an agent needs to populate configs. The docs pointer mitigates this but does not close the gap.

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 only 10%, so the description must carry meaning, and it does partially: it maps type values onto intent (breathe path line vs figure8, gaze brow lift/arch/dip, blink eye swaps vs lid bones, onPoses). But the numerous nested numeric options (dart, drift, decay, lag, inertia, hold, gate) are left entirely to the schema, with only a pointer to docs/USAGE.md#generate-options.

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 ("A new animation of one type") and scopes it ("fill only that type's object"), and positions it against spine_add_animation. It does not explicitly say how it differs from spine_derive_animation or spine_transfer_animation, so sibling differentiation is only partial.

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 twelve type fragments act as genuine selection guidance — e.g. "settle: decay after a gesture", "walk: in-place cycle", "lipSync: mouth/jaw from audio" — telling an agent which type fits which situation. What is missing is guidance on when to choose this tool over the generate-adjacent siblings, and no explicit when-not 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?

Beyond the annotations it discloses that the run is a dry-run by default, that it never overwrites, that masks are baked and unsupported effects are reported, and that results are verified by re-export and a render against the source. That is substantial non-destructive-mutation context. It does not say what happens if the output .spine already exists other than 'never overwrites', nor whether permissions or a running editor 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?

Every clause carries information, but the single telegraphic block cramming three input modes, a nested layout format, and verification into one paragraph is hard to parse. The mode list and the embedded {parts:[...]} spec would read far better as separate sentences or bullets.

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 mutation tool, it covers the important parts: input modes, safety defaults, and verification. It still leaves defaults for bones/origin/scale and the distinction between apply and dry-run outcomes unspecified, which an agent would need before a confident call.

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 only 25% across 12 parameters, so the description carries much of the burden. It does explain the three input modes, the bones='groups' behavior and the detailed layout/parts JSON shape, which genuinely compensates for the undocumented parts/layout fields. However origin, scale, includeHidden, skeleton, and the exact apply semantics are left entirely to the bare schema.

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 and action: a new Spine project built from a layered PSD, with a region per layer, draw order from layer order, and bones from groups. The closing 'Places art only' cleanly scopes it away from rigging/animation siblings like spine_auto_rig, though it never names an alternative tool 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?

It gives explicit input-mode selection: 'Or json' for PhotoshopToSpine output and 'Or parts' for a layout JSON, plus the dry-run-by-default rule that tells the agent when to set apply. It stops short of stating when to prefer this over spine_update_images or spine_import plus rigging, or what prerequisites (existing project, image paths) are needed.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower; the description adds real value by disclosing that section views return raw JSON while animation returns every timeline with exact keys. It says nothing about file-loading failures, output size for large skeletons, or whether filters apply across views.

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?

Extremely compact and front-loaded, with zero filler sentences. The semicolon-DSL style ('bones|slots|skins|constraints: raw section JSON') is dense but parseable, though the opening fragment 'Skeleton structure.' is clipped rather than a full statement.

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 tool with no output schema, the description partially compensates by describing what each view returns instead of a return schema. Gaps remain on error behavior for unsupported files and on how large raw section/animation output can get, which matters for an agent deciding between summary and raw views.

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 schema enum lists six view values with no per-value descriptions, and the description supplies exactly that semantics by explaining what each view yields and which is the default. With 71% schema coverage the remaining parameters (kind, owner, filter, skeleton) are largely explained in the schema itself, so this is adequate-to-good.

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 the resource (skeleton structure) and enumerates the exact information each view returns (counts, bone tree, constraints, timelines), so an agent can tell what it gets. It does not, however, differentiate from overlapping siblings such as spine_project_info or spine_skins.

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 that summary is the default and maps each non-default view to its output, which implicitly guides view selection. There is no explicit when-to-use/when-not guidance and no mention of the neighboring tools that overlap (project_info, skins, audit).

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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuine context beyond that: backups are created automatically before writes and results come back newest first, which tells the agent both provenance and ordering. It stops short of describing pagination, truncation, or what an empty result means.

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 clause with zero filler, and the ordering hint and cross-tool linkage are front-loaded. The telegraphic comma splice makes it slightly harder to parse than a full sentence would, 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 single-parameter read-only tool with no output schema, the description covers the essential return shape (ids, newest first) and the downstream consumer. Only edge-case behavior, such as no backups existing or result caps, is 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?

There is a single required 'project' parameter with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about the project identifier format or resolution, which is the baseline-3 case.

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 the resource (backups made before writes) and the return payload (ids), which is more specific than the title alone. It is distinguishable from the sibling spine_restore_backup, which consumes these ids. The verb 'list' is only implied by the title rather than stated in the description text.

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 'ids for spine_restore_backup' implies the intended workflow: call this first, then restore. There is no explicit when-not-to-use guidance, no note on when backups exist or how many are typically returned, leaving the agent to infer prerequisites.

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?

readOnlyHint=true already tells the agent this is a safe read. The description does add real value beyond the annotation by disclosing that constraints are solved and physics are warmed up before sampling, which affects result fidelity. It says nothing about cost, runtime, or limits on large animations, so the behavioral picture 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?

Three tightly packed sentences, results front-loaded by output category, with no filler. The telegraphic semicolon style is dense but every clause carries information, so the compression is justified.

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 a nested object and no output schema, the description outlines the returned measurement categories well, which is valuable. However, with no output schema and many undocumented parameters, an agent still lacks the detail needed to pick fps, bones, warmupLoops, or interpret the result structure precisely.

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 only 45% with 11 parameters, so the description needs to compensate, but it does not explain fps, bones, skin, animation, warmupLoops, or the top-level rootMotion object. Its 'rootMotion:' and 'parts:' clauses read as output-section labels rather than parameter guidance, and the closest thing to parameter meaning (rootMotionBoneName) is already in the schema.

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 ('samples an animation in spine-core') and enumerates the measurements produced: rotation range, path, peak speeds, pops, holds, loop seam, rootMotion travel and foot sliding. This clearly separates it from sibling analysis tools like spine_compare_animations or spine_motion_visual, though it never names those siblings 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?

There is no when-to-use or when-not-to-use guidance, and no routing to alternatives such as spine_compare_animations, spine_motion_visual, or spine_timing. The agent must infer from the output list that this is a diagnostic measurement tool, which is only implied usage.

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?

readOnlyHint=true is consistent with a simulation-only check, so the safety profile is already covered by annotations. The description does add real behavioral context beyond that: it simulates playback with mixes and an optional base track, switches at several points, and reports pops, late-keyed timelines, and events lost inside the mix. However, the mecanim clause introduces 'setupKeys', which is not a parameter or documented output field, leaving the response shape only loosely characterized.

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 dense sentences with the core action front-loaded and no filler. The second sentence is jargon-heavy and its parenthetical '(setupKeys)' refers to nothing in the schema, slightly muddying an otherwise tight definition.

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 the description does partially compensate by enumerating what the report contains (pops with phase and cause, late first keys, lost events). Still, for a 15-parameter diagnostic tool, the majority of inputs and the exact result structure are underspecified.

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?

With 15 parameters and only 40% schema description coverage, the description must carry weight, and it explains the intent behind a few: switch points ('at'), the optional base track, transition mixes, and the two runtime modes. It says nothing about fps, limit, bones, trace, track, skeleton, autoReset, defaultMix, mecanimMode, or eventThreshold, so most of the surface remains 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 states a concrete verb and resource: it plays animation transitions through spine-core's AnimationState and reports pops with phase and likely cause. That is far more specific than the title alone and clearly separates it from export/inspect siblings, though it never names which sibling (spine_validate, spine_compare_animations, spine_unity_check) covers adjacent ground.

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: an agent can infer this is the tool for diagnosing transition pops before shipping, and the mecanim clause hints at a Unity-parity use case. There is no explicit when-to-use/when-not guidance and no named alternative among the many spine_* check tools.

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?

Annotations only declare readOnlyHint=true, and the description adds genuine behavioral detail beyond that: the output is both an image and numeric data, arcs are sampled one dot per frame, and bones default to the 3 that travel furthest when not specified. It stops short of explaining how mode/size/fps/ghosts shape the result.

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 that front-load the three visual modes and append the important default behavior. Minor awkwardness in 'plus the numbers' and the compressed title-like opening, but 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?

For a rendering tool with 8 parameters, no output schema and zero schema descriptions, the description covers only the default bone selection. An agent still cannot tell what 'ghosts', 'size', 'fps', or the difference between 'onion', 'arcs', 'graph' and 'all' actually do.

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 8 parameters, so the description must compensate. It only explains the 'bones' default (the 3 that travel furthest) and implicitly gestures at the mode enum through prose; fps, size, ghosts, skeleton, project and animation are left with no meaning beyond their names and bare type constraints.

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 the resource (one animation) and the concrete outputs: an onion-skin/bone-arc/value-curve image plus the underlying numbers, with 'one dot per frame' for arcs. It is clear what the tool produces, though it never uses an explicit verb like 'visualize' and does not name a sibling such as spine_render_frames to draw the boundary.

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 or when-not-to-use guidance, and no mention of alternatives among the many rendering/measurement siblings (spine_render_frames, spine_measure, spine_compare_animations). The scope phrase 'of one animation' hints at usage but the agent must infer the selection criteria itself.

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?

Annotations already declare readOnlyHint=true, so safety is covered. The description earns credit for disclosing a behavioral trait annotations cannot express: a ~3 s CLI startup cost per call and the resulting batching advice, plus the 'fast'/summary framing relative to heavier tools. It does not cover failure behavior on bad paths.

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 compact sentences, front-loaded with what the tool returns and followed by the cost/batching note. Every clause carries information; 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?

With no output schema, the description effectively stands in for it by listing the returned fields, and it flags the latency cost. For a single-parameter read-only tool this is nearly sufficient; only error handling for invalid or missing paths is left unstated.

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 reported at 0% for the parameter, although the items field does enumerate accepted formats (.spine, .json, .skel/.bytes). The description compensates partly by explaining that multiple paths per call are supported and why (shared CLI startup), which is genuine meaning beyond the schema's minItems array.

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 gives a concrete verb and resource ('Fast CLI summary'), then enumerates the returned contents: editor version, FPS, skeletons, bone/slot/constraint/animation lists. That is specific enough to distinguish it from heavier siblings like spine_inspect or spine_validate, though no sibling is explicitly named.

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 named alternative, so the agent must infer that this is the lightweight orientation call. It does add one useful operational guideline: pass several paths in a single call to amortize the ~3 s CLI start.

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?

Annotations only declare readOnlyHint=true, so the bar is low, and the description does add useful context: the analysis produces four signal types across three output forms and an optional crop region. It says nothing about processing cost on long videos, whether the sheet/graph are written to disk, or how comparison results are reported, which matters for a readOnly tool that appears to emit artifacts.

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 dense sentences, front-loaded with the core purpose and the optional crop caveat before the compare mode. Some output nouns are listed in a compressed run ('frame table, graph and sheet') but nothing 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?

Given 7 parameters, nested objects and no output schema, the description does partially compensate by describing what the tool returns (frame table, graph, sheet, peaks/holds/cuts/period). However, it omits parameter semantics for most inputs and offers no routing guidance in a crowded sibling set, leaving real gaps for a moderately complex 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 description coverage is 0% across 7 parameters including two nested objects, so the description must carry the burden. It only clarifies two of them ('optional crop', and that compare involves a Spine animation with speed ratio, offset, per-peak frames), and even those are ambiguous because speed ratio/offset/per-peak frames read as outputs rather than the project/animation/skeleton/scale inputs. fps, start, end, video and the sheet flag remain 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 description names a specific verb and resource ('timing from a reference video') and enumerates concrete outputs: motion peaks, holds, cuts, repeat period as a frame table, graph and sheet, plus a compare mode. It is clearly not a generic timing or compare tool, though it never names which sibling (spine_timing, spine_compare_animations) it supersedes.

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 statement and no named alternative. The clause about 'compare' aligning a Spine animation implies a secondary mode, but an agent must infer from the sibling list whether to pick this over spine_timing, spine_compare_animations, or spine_review_video.

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?

readOnlyHint=true already tells the agent this is a non-mutating read, so the description's remaining job is to add context, and it does by listing the classes of breakage it detects. It stays silent on cost/runtime (diffing a whole project plus skeleton), precedence when both a snapshot and a before file are supplied, and whether the comparison is deep or structural only.

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 with a front-loaded verb-resource pairing and no filler; the colon-introduced lists pack the diff categories efficiently. It is compact but slightly over-packed, and the animation-playback clause trails after the structural breakdown rather than being foregrounded.

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, no-output-schema comparison tool, the description omits three parameters entirely (including the only required one), does not clarify snapshot-vs-before precedence, and gives no sense of result shape or size. It conveys the concept well but is not complete enough for confident 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 only 20% (just the 'before' param), so the description must carry the burden, and it explains only two of the five: snapshot (default latest) and before (another .spine/.json). The required 'project' param, plus 'skeleton' and 'fps', are never mentioned in the description and have no schema descriptions, leaving the agent to guess their meaning and whether fps affects the playback comparison.

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 (compares) and concrete resources (a project, a snapshot, another .spine/.json file), and enumerates what the diff surfaces (lost keys, weights, meshes, removed items, animation playback differences). That is far more specific than a tautology and implicitly separates it from spine_compare_animations, but no sibling is named outright, so full distinguishability is left to inference.

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 a default behavior (snapshot defaults to latest) and a comparison target alternative, which implies the intended workflow after a re-import. It does not state when to reach for this instead of spine_validate, spine_doctor, or spine_compare_animations, nor any prerequisites, so usage is implied rather than directed.

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 readOnlyHint=true already covering safety, the description adds useful behavioral context: ~4 s runtime, caching, disabled MSAA, no physics warm-up, and a contact-sheet return. It still leaves cache invalidation and parameter-dependent behavior unstated, but the added operational detail is meaningful.

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 tightly written sentences front-load the operation and then append the runtime/quality caveat. No filler; the caveat is directly relevant to tool selection.

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 covers selection-level behavior, output type, performance, and quality limits, which is useful given no output schema. For a 9-parameter tool with low schema coverage, however, it omits guidance on most invocation parameters, so it is 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 only 33%, and the description adds no explanation of fps, maxFrames, refresh, skin, project, or scale beyond the vague mention of rendering an animation. The agent must infer most parameter meaning from names and bounds alone.

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 ('Renders') and resource ('an animation'), names the concrete output ('contact sheet'), and distinguishes this from final video output. An agent can identify it as a preview-render tool 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?

It states the primary use case ('for checking') and an explicit exclusion ('not final video'), which tells the agent when this is appropriate. It does not name a specific sibling to use for final video, so routing relies on the agent's own comparison.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the description's real contribution is the mitigation story: dry-run default, backup of the current file before applying, and atomic restore. That is useful context beyond the annotations, but gaps remain — it doesn't say whether force bypasses the backup step, what a dry-run returns, or whether the restore is reversible.

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 behavior and safety model front-loaded and no filler. Slightly elliptical phrasing ('puts a backup back') costs a little precision but no space.

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 four-parameter destructive tool with no output schema, the description covers the risky part (mutation only on apply, with an automatic safety copy) well. What's missing is modest: how to obtain backupId and what a dry-run reports.

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 50% with apply and backupId undocumented there; the description compensates for apply by explaining the dry-run/apply split, but says nothing about backupId format or provenance. The force parameter's meaning still lives only in the schema.

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 (restoring a backup of a file) and implies the counterpart to spine_list_backups without naming it. 'Puts a backup back' is colloquial but unambiguous about direction of the operation.

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 clearly explains the default/opt-in mechanics (dry-run unless apply is passed), which is the main usage decision. However, it never says when to prefer this over other recovery paths or that backupId should come from spine_list_backups, leaving the caller to infer prerequisite steps.

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?

Annotations declare readOnly=false and destructive=false; the description adds a useful side-effect boundary by saying it 'Writes only output,' and it describes what the generated video contains. It does not explain overwrite behavior or failure modes, so the disclosure is clear but not complete.

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 two tight sentences, front-loaded with the core action and artifact. The parenthetical label list is dense but informative, and 'optional audio under real-time passes' is slightly awkward but still 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 14-parameter mutation tool with 7% schema coverage and no output schema, the description is too thin. It never explains key parameters such as overwrite, project/skeleton selection, or how fps, loops, and scale affect the output.

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 only 7% across 14 parameters, so the description must compensate, but it only clarifies animations, speeds, audio, and title. Many parameters, including fps, skin, loops, scale, project, skeleton, overwrite, background, and audioOffset, are left entirely to the bare schema.

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 gives a specific verb and resource ('Review cut MP4') and details the artifact: every animation at each speed, frames labelled with animation/speed/frame/time, optional audio and title card. However, 'Review' is ambiguous between inspecting and producing a video, and no sibling such as spine_render_frames or spine_video_inspect is named to differentiate.

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 sibling is named. The agent can infer it creates a review video, but must guess how it differs from spine_render_frames, spine_showcase, spine_video_inspect, or spine_video_frames.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that writes go to a brand-new file via JSON import with the original untouched, that execution is dry-run unless opted in, and that the result lists incidental round-trip changes. That is meaningful mutation-safety context. It stops short of describing error handling or what happens if `output` 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?

There is little wasted content, but the whole thing is a single semicolon-chained run-on that is hard to parse and buries the dry-run default at the end. Front-loading the core action and splitting the safety note into its own sentence would help considerably.

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 tool with nine distinct edit operations, a nested oneOf schema, and no output schema, the description covers the operation set and write semantics but leaves gaps: how `apply` toggles execution is only implied, edit ordering/dependency behavior is unstated, and there is no sense of what the returned 'round trip changed' listing looks like.

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 50%: `project` and `output` are documented in-schema, while `apply` and `edits` are not. The description compensates partially by enumerating the edit ops (which map to the `edits` oneOf branches) and by hinting at dry-run/apply semantics, but it never names `apply` or states what `edits` ordering/validation requires.

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 the concrete operation set (addBone/addIk/addPhysics/addEvent/addSkin, setup poses, removeConstraint, meshRegion, copyMesh) and the output artifact (a NEW .spine). It is specific enough that an agent knows this is a batch rig-editing tool, though it never explicitly distinguishes itself from sibling `spine_auto_rig` or `spine_derive_animation`.

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?

'Dry-run by default' and 'original untouched' imply that an explicit opt-in (apply=true) is needed to actually write, and 'one skeleton' scopes the input. But there is no explicit statement of when to pick this over `spine_auto_rig` for rigging, or over `spine_import_layers` for import-style work, so the routing guidance 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?

readOnlyHint=true is consistent with the description and the enumeration of detection categories tells the agent exactly what classes of problems surface — meaningfully more than the annotation. It does not say whether results are errors vs warnings, whether it aborts on failure, or how findings are reported, which is a real gap for a QA 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?

Compact and front-loaded with "Rig hygiene:", but the remainder is one long comma-run of mixed-granularity items ("names (spaces, clashes, default names, mixed left/right styles)" next to vague phrases like "art a mesh cuts off"), which is hard to parse at a glance and would benefit from grouping.

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 output schema, the description should say what a result looks like and how issues are grouped or severity-ranked; it does not. Scope is well covered, but one of three parameters and the entire result contract are left to inference.

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 only 33%; only `input` is documented in the schema. The description's "too many influences" checks implicitly explains the purpose of maxInfluences, but the `skeleton` parameter is unexplained in both places and no default or threshold for maxInfluences is given.

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?

"Rig hygiene" plus an explicit enumeration of defect categories (naming clashes, unused bones, weights not summing to 1, joints that open, missing images) makes the operation concrete and distinct from a generic validator. It never states the verb directly (check/report?) but the resource and scope are 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?

It names spine_validate as a complement, which implies a division of labour, but never says when to pick this tool over spine_validate, spine_doctor, or spine_audit, nor whether this is a pre-export gate. Usage is inferable from the check list only.

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?

Annotations only say it is not read-only and not destructive; the description adds real value by clarifying that the artifact is written only to the output path (no project mutation) and that it requires ImageMagick plus img2webp or ffmpeg. It does not cover overwrite behavior or failure modes, but the dependency and write-scope notes are the important ones.

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 output description, followed by the dependency note. No filler or restatement of the tool name.

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 ten of twelve parameters are undocumented, so an agent must read the schema to understand project/skeleton selection, overwrite semantics, and background handling. The description covers the essential output contract and prerequisites but is thin for a tool of this complexity.

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 only 33% across 12 parameters, so the description needs to compensate and largely does not. It clarifies the item count limit, labelling, and the output extension set, but says nothing about project, skeleton, fps, loops, scale, width, align, hold, background, or overwrite.

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 and resource: renders 1-4 Spine animations side by side, labelled, into a single animated .webp/.gif/.mp4. That is clearly distinct from spine_render_frames or spine_compare_animations in effect, though it never names those siblings 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?

"For before/after and reels" gives a use-case context, and "written only to output" hints at the scope of the operation. There is no explicit guidance on when to choose this over spine_render_frames or spine_compare_animations, so the agent must infer the boundary.

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?

The readOnlyHint annotation already tells the agent this is a safe read operation, so the description only needs to add analytical behavior. It does disclose useful semantics – that combined skins resolve slot conflicts by last-wins and that unfilled slots are reported – but says nothing about the shape of the result or how pass/fail against limits is reported.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is compact, but the telegraphic fragments ('slots several skins set (last wins), slots none fills') are hard to parse and read as under-specification rather than genuine concision. The sentence is not front-loaded with what the agent gets back.

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 a nested object and no output schema, the description omits too much: the required input file, the device-budget limits object that drives pass/fail, and the render/animation options are unaddressed. An agent could invoke it but would not know what the call actually 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?

With 11 parameters at 45% schema description coverage, the description should carry real weight here, but it only illuminates 'atlas' and 'pack' (exact draw calls) and gestures at 'combinations'. The nested 'limits' budget object, 'fps', 'render', 'animations', 'renderTime', and 'skeleton' get no mention 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?

The description names the resource (skins, and combinations of skins) and the specific checks performed: attachment counts, slot conflicts, and per-frame budget. That is well beyond a restatement of the name, though the phrasing is compressed enough that an agent must re-read it to extract the list of checks.

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 pick this tool over the many adjacent analysis siblings such as spine_budget, spine_validate, spine_inspect, or spine_mix_check. 'atlas or pack for exact draw calls' is guidance about parameters, not about choosing between tools, so usage must be inferred.

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?

Annotations already declare it is a write operation that is not destructive, and the description reinforces this with the safety framing 'verified backup copy' and the pre-risky-work timing. Beyond that it says nothing about where snapshots are stored, whether repeated labels overwrite or accumulate, or what the call returns. The dual-mode behavior (list vs. create) under a single non-readOnly annotation is worth flagging but does not directly contradict it.

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, zero filler, with the core action and its purpose front-loaded and the mode-switching rule appended. 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?

With no output schema and no schema descriptions, the description covers the why and the label semantics but leaves the return value, snapshot storage/scoping behavior, and the 'project' parameter format unexplained. Adequate to call the tool, but not complete for a two-mode 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 description coverage is 0%, so the description must carry parameter meaning, and it does define the important one: 'label' is optional and its absence switches the tool into list mode. The required 'project' parameter is never explained (name, path, or handle is left ambiguous), so the compensation is 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 description gives a specific verb and resource ('Saves a labelled, verified backup copy') and even discloses a second mode ('Without label: lists snapshots'), which an agent can act on without opening the schema. It falls short of 5 because that listing mode overlaps with the sibling spine_list_backups, and the description never acknowledges the overlap or says which one to prefer.

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 a clear trigger ('before risky editor work') and names a follow-up tool (spine_reimport_diff), so the agent knows the workflow context. It stops short of explicit when-not guidance, and it doesn't distinguish itself from spine_list_backups or spine_restore_backup, which are the closest alternatives.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: it is instant, requires no CLI invocation, and aggregates state across file, editor, staging, and backup layers plus external changes. It does not disclose return shape or whether the snapshot includes timestamps, but for a read-only status probe this is solid 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?

Two tight sentences, front-loaded with the differentiating "Instant, no CLI" claim before the enumeration of returned state. The list is dense but every item earns its place; no filler wording.

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 output schema, the description sensibly enumerates the state categories reported, which is useful. But the parameter surface is entirely unexplained and the relationship to closely overlapping siblings is left ambiguous, so an agent is only partially equipped to call this 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 carries the full burden for explaining the two parameters, and it largely fails: neither "project" nor "recent" is mentioned or explained. The phrase "outside changes since" only faintly implies a recency window for "recent" and gives no hint about valid ranges or what "project" identifies.

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 enumerates exactly what the tool surfaces: file state, editor window, staging copy, backups, spine-mcp's last steps, and outside changes. That is a clear, specific resource picture that lets an agent distinguish it from narrower siblings like spine_editor_status or spine_list_backups. It stops short of explicitly naming those siblings, so a 4 rather than 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?

"Call first when resuming work" gives an explicit, actionable trigger for invocation. However, it offers no when-not guidance and doesn't route the agent to the overlapping siblings (spine_editor_status, spine_project_info, spine_list_backups) for narrower needs.

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?

The readOnlyHint annotation already establishes this is a safe read, so the description only needs to add output-shape context, which it partially does by enumerating what is reported (poses, intervals, durations, eases, holds). It says nothing about whether analysis is per-animation, per-skeleton, or whole-file, and gives no hint about how the limit parameter bounds output.

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 listing the four things reported, with no filler. It is efficiently sized, though the noun-list style leaves the subject (what the tool operates on) implicit.

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 6 parameters, half undocumented, and no output schema, an agent lacks enough information to choose this over spine_reference_timing or spine_measure, or to understand how bones/limit/skeleton scope the report. The description covers the output conceptually but not the invocation semantics.

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 only 50%, and the description explains none of the ambiguous parameters: bones, limit, detail ('Per-bone segments'), or skeleton. The 'per segment' wording brushes against detail but never clarifies that detail enables per-bone breakdown, so the description 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 description states a specific output ('timing structure from the keys: key poses and intervals, segment durations, ease type per segment, holds'), which tells an agent what it produces. However, it never states the verb or input source explicitly, and with near-identical siblings like spine_reference_timing and spine_measure, it does nothing to distinguish itself.

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 exclusions, and no reference to any sibling tool such as spine_reference_timing or spine_compare_animations. An agent must guess whether this is the right timing tool for its task.

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?

Beyond the annotations (readOnly=false, destructive=false), the description discloses that it reports what matched, was renamed, or could not move, that the write is dry-run by default, and that copies mode surfaces conflicts resolved via 'prefer' before writing into the base. That is meaningful operational context an agent would otherwise have to guess.

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 first sentence is front-loaded and efficient, but the second sentence is compressed to the point of being hard to parse ('copies: merge mode for animators on copies of one project') and mixes mode description with output behavior in a single semicolon chain.

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 16-parameter mutation tool with no output schema and a nested map/retarget structure, the description covers the core copy-and-merge semantics and the dry-run safety default but leaves a substantial share of parameters and the editor/staging behaviors undocumented, which is a meaningful gap.

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 only 31% across 16 parameters, so the burden falls on the description. It does explain the matching order (exact, then map, then case/separator-insensitive), the map and prefer objects, the copies array, and that 'to' is the base target — but editor, replace, retarget, normalize, allowUpgrade, stagingPath, fromSkeleton/toSkeleton, and the from/name/animation trio remain 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 description opens with a specific verb+resource ('Copies an animation to another skeleton or project') and names a second mode ('copies: merge mode'). That distinguishes it reasonably well from siblings like spine_derive_animation or spine_generate_animation, but the two modes are not clearly named as modes, so an agent must parse the second sentence to see the split.

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 says the tool is 'dry-run by default' and that the add step behaves 'like spine_add_animation', which gives some selection context, and the copies clause implies a multi-animator workflow. However, it never states when to choose this over spine_add_animation or spine_import_layers, and no explicit exclusion is 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?

readOnlyHint=true already tells the agent this is a safe read-like operation, and the description adds useful context beyond that: the work happens in a throwaway project, runs about 30 seconds, and reports per-bone animation deltas plus CPU/GC metrics. It still omits what a failing run looks like, whether Unity must be installed, and whether anything is written to disk despite the readOnly annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence with no filler, which is good. But the telegraphic style ('perf: CPU/GC per skeleton', 'fresh export ... bone by bone') trades clarity for brevity, and the trailing doc-anchor sentence is a fragment rather than usable guidance.

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 tool with 22 parameters including nested objects, four enums, and no output schema, the description is markedly under-specified. An agent would not know how to configure render, compression, or mecanim checks, nor what results to expect, without following the external link.

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?

With 22 parameters and only 32% schema description coverage, the description must carry weight, but it mentions only 'perf' in passing and defers the rest to an external doc link. High-impact options like renderPipeline, batching, compression, mecanimTransitions, and tracksPhysics are undocumented in both places, so an agent cannot tell what they change.

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 action and object: fresh export into a throwaway Unity project, with every animation compared bone by bone against spine-core, plus CPU/GC perf per skeleton. That is far more specific than the title 'Check the export in Unity'. It does not, however, distinguish itself from related siblings such as spine_unity_import or spine_validate, leaving the agent to infer the boundary.

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 choose this over spine_unity_import, spine_validate, or spine_web_check, and no prerequisites (e.g. which Unity versions are available). The only pointer is a doc anchor, 'docs/USAGE.md#into-your-unity-project', which outsources the guidance rather than providing 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?

Annotations only say readOnly=false and destructive=false; the description adds genuinely non-obvious behavior: dry-run is the default, update overwrites in place but backs up and preserves GUIDs, and when Unity is open only files are copied (no live project mutation). What is missing is what happens on failure or how the bone-by-bone comparison is surfaced. No contradiction with the annotations – the backup step is why 'destructive' is honestly false.

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 primary action, then the mutation mode, then the read-only mode, which is the right order for an agent choosing a branch. The telegraphic phrasing ('data, atlas, materials, mixes, prefab') is efficient, though the semicolon-separated mode clauses require careful parsing.

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 19-parameter mutating tool with no output schema, the definition covers the core action and its safety posture (dry-run default, backups, GUID preservation) which is the highest-value context. It stops short of explaining the majority of parameters or what the comparison report returns, leaving real 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 only 21% across 19 parameters, so the description must compensate and largely does not. Only update, audit, prefab, mixes, and the implicit apply/dry-run flag are touched; format, loop, skin, folder, component, followers, defaultMix, unityVersion, referenceAssets, startingAnimation, premultipliedAlpha and project are left undocumented in both schema and description.

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 concrete verb and resource, 'Imports a .spine into a Unity project with spine-unity,' and enumerates the produced artifacts (data, atlas, materials, mixes, prefab) plus the post-import bone comparison. It never names the close siblings (spine_unity_check, spine_audit, spine_reimport_diff), so the agent must infer the boundary itself.

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?

Mode guidance is present and useful: 'Dry-run by default,' 'update: replace in place (backed up, GUIDs kept),' and 'audit: read-only scan (version, data files, API changes).' However, there is no statement of when to pick this tool over the obvious alternatives – notably spine_audit, which overlaps the audit mode, or spine_reimport_diff – and no exclusions or prerequisites 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly supplied. The description usefully adds that apply takes a backup before writing, that renders are produced before/after, and that the .spine file is untouched. However, it never clarifies that 'restore' overwrites existing image files (a potentially destructive path) nor how backups are identified or listed.

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?

Compact and front-loaded, with the core guarantee stated first. The heavy use of sentence fragments ('grow enlarges a region image', 'restore: a backup id') makes it terse but slightly telegraphic and uneven in register.

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 mutation tool with no output schema, the description covers the main workflow but leaves four parameters undocumented and gives no sense of what a dry-run returns (render paths? a diff report?). Adequate, not 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?

With only 20% schema description coverage across 10 parameters, the description carries most of the burden, and it explains only psd, grow, placement (psd side only), apply, preview and restore. It says nothing about `only`, `scale`, `skeleton`, or what placement 'keep' means, so several 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 and resource ('Updates a project's image files from a layered PSD') plus the key invariant that the .spine skeleton is not touched, which separates it from spine_import_layers and spine_reimport_diff. It stops short of naming which sibling to use instead when the whole project must be rebuilt.

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 lays out the operating modes well: dry-run/preview by default, 'apply backs up and writes', plus the placement and grow switches. It gives clear guidance on the safe path (preview first) but never states when to prefer a sibling such as spine_import_layers or spine_restore_backup.

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?

Annotations only declare readOnlyHint=true, so the description carries the behavioral load and does add real context: it reveals that validation samples every animation in spine-core and explains the import quirk ('Spine drops them on import') that motivates the missing-reference check. It does not disclose cost/performance of sampling all animations, whether findings are warnings vs errors, or how results are surfaced, which keeps 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?

Nearly every clause carries a distinct check, so there is little outright waste, but the whole thing is one run-on sentence stitched together with semicolons and an abrupt 'face:' pivot. It is information-dense but poorly structured and hard to scan, which undercuts the front-loading benefit.

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 read-only validator with 6 parameters, a nested face config, and no output schema, the description should say what callers get back (issue list, severities, exit status). It thoroughly covers what is inspected but not the result shape or how to interpret findings, leaving a meaningful gap for a tool whose entire value is its report.

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 67%, so the baseline is 3 and the description needs to add meaning. It does partially: the face paragraph explains what the face audit compares (blinks vs pose changes, mouth swaps, lash visibility while shut), and the loop-seam check maps to loopAnimations. But the top-level parameters input, runtime and skeleton get no explanatory value, and the face sub-option semantics (hide, lids, mouths, closedFrom) are not clarified beyond the schema.

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 concrete verb and resource ('Finds problems' in a skeleton) and then enumerates the exact defect classes checked (duplicate names, bone order, missing references, mesh indices, curves, physics keys) plus an animation sampling pass and a face audit. That is far more specific than the title 'Validate skeleton'. It loses a point because it never distinguishes itself from the many overlapping sibling validators (spine_doctor, spine_audit, spine_rig_qa, spine_mix_check, spine_unity_check), so an agent cannot tell which of them 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 explicit when-to-use or when-not-to-use guidance, and no mention of alternatives. With five or more sibling tools that plausibly also validate assets, the absence of any routing statement is a real gap. The list of checks only implicitly signals that this is the pre-flight correctness check for a Spine skeleton.

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?

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description does add real behavior beyond that — labelled sheet output, red change marks in diff mode, blended overlays in onion mode, and a 48-per-call cap — but says nothing about what happens when a frame number is out of range or how start/end/fps interact with explicit frame lists.

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, front-loaded sentence with no filler; the numbering dependency and output cap are stated early. The telegraphic mode clause ('diff marks changes in red, onion blends them') is compact but slightly cryptic at first read.

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 nested objects, an unlabeled enum, and no output schema, the description is too thin — an agent cannot tell how range versus frames versus start/end combine, nor what the labelled sheet looks like. The behavioral hints are helpful but leave most of the calling surface 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 description coverage is 0% across 10 parameters, including nested objects (range/crop) and an undocumented mode enum, so the description carries the full explanatory burden. It explains only the three mode names loosely and a 48-item cap — which also sits uneasily beside the schema's maxItems of 200 — while range/step, start/end, fps, crop, width, and columns get no meaning 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 concrete verb and resource ('exact video frames by number') plus the deliverable ('a labelled sheet'), and ties frame numbering to spine_video_inspect so the agent knows the coordinates are shared. It doesn't explicitly separate itself from spine_render_frames or spine_motion_visual, so the sibling 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?

'by number (spine_video_inspect's numbering)' implies a workflow: inspect the video first, then pull specific frames — useful implied guidance. But there is no explicit when-to-use versus spine_render_frames, no statement of when diff/onion modes apply, and no 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description usefully adds what kind of output to expect (event list, per-frame curves, overview sheet) and what the verify mode does, but omits runtime cost, limits, and how the analysis scales with range/fps — relevant for a heavy frame-by-frame pass.

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 single semicolon-chained sentence is front-loaded with purpose but then becomes an undifferentiated feature dump. Every element is arguably relevant, but the run-on packing of encoding, motion, audio, and output artifacts makes it harder to parse than a short structured list.

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 output schema, the description does well to sketch return artifacts (event list, curves, overview sheet). However, for a 7-parameter tool with nested crop/verify objects and no schema descriptions, the missing parameter semantics and lack of guidance on range/fps trade-offs leave it partially 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?

Schema description coverage is 0% across 7 parameters, including nested crop and verify objects. The description only indirectly illuminates 'sheet' ('an overview sheet') and 'verify' ('compares a segment with a Spine animation'); start/end, fps, and crop semantics are entirely undocumented, so the description does not 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?

Opens with a specific verb+resource ('Frame-by-frame video check') and enumerates concrete analyses (encoding, VFR, segments, flashes, dropped frames, audio onsets), which clearly distinguishes a diagnostic inspection from a frame extractor. The purpose is clear despite the dense enumeration, and it explicitly names the sibling spine_video_frames for exact frames.

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 one explicit routing rule ('Exact frames: spine_video_frames') and notes that 'verify' compares a segment with a Spine animation, but there is no guidance on when to prefer this over siblings like spine_review_video, spine_motion_visual, or spine_video_frames beyond that single line, and no stated 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 readOnlyHint=true already covering the safety profile, the description adds real value: it discloses the headless-Chrome pipeline, the external dependency, and the metrics produced (silhouette IoU, colour difference, worst frame). It still omits cost/runtime, whether artifacts are written to disk, and failure behavior beyond the missing-browser case, so it is good but not rich.

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 operation and followed by the metric list and the environment prerequisite. No filler; every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with no output schema, the definition covers the mechanism and one prerequisite but leaves the parameters, the shape of the result, and error conditions undocumented. It is enough to understand the tool's role but not enough to invoke it 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%, and the description mentions none of the four parameters. 'project' is required but unexplained (file path? project name?), and 'animations', 'fps', and 'scale' (with their numeric bounds) are entirely undiscussed. The description does not compensate for the schema gap 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?

The description states a specific verb+resource: renders a fresh export with spine-webgl in headless Chrome and compares every frame against Spine's render, listing the comparison metrics. An agent can tell this is a rendering-fidelity check. It does not name parallel siblings such as spine_unity_check, spine_mix_check, or spine_render_frames, so 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?

It supplies a prerequisite ('Needs Chrome or CHROME_BIN'), which is useful context for whether the tool can run at all. However, there is no explicit statement of when to pick this over the similar web/unity/mix-check siblings, nor any exclusion about when not to use it.

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