Retrieve Spine project information from the CLI, including editor version, animation counts, and warnings for files the offline parser may not understand.
Ask the Spine CLI for project information (-i project). Shows the editor version, animation counts and warnings for files the offline parser may not understand.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| timeout | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does partially meet it by naming the underlying CLI invocation (-i project) and the shape of the returned information. It is silent on operational realities: the tool shells out to an installed Spine CLI, the 180s default timeout implies it can be slow, and failure modes or non-zero exit behavior are unaddressed. Read-only intent is implied by 'info' but never stated.
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 action and the CLI flag, followed by the payoff. No filler, no repetition of the tool name as a substitute for meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is legitimately omitted. But for a tool that shells out to an external binary with no annotations and an undocumented timeout parameter, an agent still lacks prerequisites (is the Spine CLI installed?) and guidance on the sibling diagnostic tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and only partly does: the '-i project' snippet clarifies that 'project' is the value handed to the CLI flag. The 'timeout' parameter, whose 180s default is a strong hint at long-running external execution, is never mentioned, leaving half the interface 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 states a specific verb and resource (ask the Spine CLI for project information) and enumerates what comes back: editor version, animation counts, parser warnings. That is concrete and agent-legible. It does not, however, distinguish itself from nearby siblings like spine_inspect, spine_validate, or spine_doctor, all of which plausibly read project state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the mention of warnings for files the offline parser may not understand hints at a diagnostic context. There is no explicit when-to-use, no when-not-to-use, and no named alternative such as spine_doctor for health checks. The agent has to infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.