spine-mcp

Overview Schema Source Related Servers Discussions Admin

spine_add_attachment

Add region, mesh, point, bounding box, or path attachments to a Spine slot inside a skin; optionally assign the new attachment to the slot's setup pose.

Instructions

Attach something to a slot inside a skin (registration + optional setup assignment).

Kinds:

region - textured rectangle centered on x/y; needs width/height. image_path is the region name inside the images folder/atlas, without extension (defaults to the attachment name; a .png suffix is stripped).
mesh - textured mesh; a regular grid centered on x/y is generated from width/height/cols/rows unless explicit uvs/vertices/triangles are given (then list the outline vertices first and pass hull = their count).
point - single point with rotation (projectile/particle spawn).
boundingbox - polygon for hit detection; needs vertices (x,y pairs).
path - curve for spine_add_path_constraint; vertices are the anchor points (x,y pairs, in the slot bone's space). Smooth handles and the curve lengths are generated. closed makes a loop; constant_speed (default) keeps bones evenly spaced along it.

Args: assign: Also set this attachment as the slot's setup-pose attachment. skin: Skin to put the attachment in (created if missing).

Input Schema

Name	Required	Default
`x`	No
`y`	No
`uvs`	No
`cols`	No
`hull`	No
`kind`	No	region
`name`	Yes
`rows`	No
`skin`	No	default
`slot`	Yes
`color`	No
`width`	No
`assign`	No
`closed`	No
`height`	No
`project`	Yes
`scale_x`	No
`scale_y`	No
`rotation`	No
`vertices`	No
`triangles`	No
`image_path`	No
`constant_speed`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Since no annotations are provided, the description carries the full burden. It provides rich behavioral detail, explaining how specific parameters behave—such as the region name format (without extension) or that 'hull' counts vertices for meshes. This level of specificity is critical for successful execution.

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

Conciseness4/5

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

The definition is extremely well-structured, using clear headings and bullet points to separate complex logic. While it is dense due to the tool's complexity, every sentence is essential and logically placed.

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

Completeness5/5

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

Given the high parameter count and lack of schema context, the description provides maximum completeness. It outlines the required inputs for all major attachment types, allowing an agent to construct valid calls for various use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the tool definition relies entirely on the description. It successfully uses bullet points to link specific parameters (e.g., width/height) to specific kinds, effectively filling all the gaps left by the bare input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the tool's function: attaching a visual or functional asset to a slot inside a skin. It is highly specific about the action and the resource involved, making the tool's role obvious among spine management siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The documentation provides usage guidelines by defining distinct parameter sets for different attachment 'kinds' (e.g., 'region' vs 'mesh'). This guides the user on which fields to populate based on their desired outcome, which is a primary form of usage instruction for this complex tool.

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