sky-spine-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct Spine operation: CLI info, export, packing, atlas summary, JSON summary, and asset validation. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow a consistent 'spine_verb_noun' pattern using snake_case, making it predictable and easy to understand the action and target.
Tool Count5/5
With 6 tools, the server is well-scoped for Spine-related tasks. Each tool serves a clear purpose without redundancy, and the count is appropriate for the domain.
Completeness4/5
The tool set covers core Spine workflows: info, export, packing, summarizing, and validation. Minor gaps like importing or running specific Spine commands are absent but not critical for typical use.
Average 3.4/5 across 6 of 6 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states only 'Check whether' but does not explain if the tool is read-only, how it reports missing assets (error vs. list), what happens if the folder doesn't exist, or any required permissions. The behavioral details are insufficient for an agent to understand side effects or reliability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. While efficient, it is too minimal for a tool with multiple parameters and no annotations. It lacks structure such as separating purpose from usage details. It is neither verbose nor well-organized, earning an average score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (1 required), low schema coverage, no output schema, and no annotations, the description is critically incomplete. It fails to explain return values, validation logic, error handling, or prerequisites. An agent cannot reliably invoke this tool based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only folderPath has a brief description). The description does not mention any parameters or add meaning beyond the schema. For a 3-parameter tool with low coverage, the description should compensate by explaining the roles of requireAtlas and requireImages, but it does not, severely limiting parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a folder for Spine runtime assets (verb 'Check' + resource 'folder'). It distinguishes from sibling tools like spine_export or spine_pack, which have different purposes. However, 'expected Spine runtime assets' is somewhat vague, lacking specificity on what exactly constitutes 'expected'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (validate assets in a folder) but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. No exclusions or alternative tool references are given, but the context of validation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions input types but does not describe output, side effects, or whether it is a read-only operation. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with no output schema or annotations. It does not explain what 'info' returns, nor does it provide context on how the tool behaves, leaving the agent with insufficient information to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no new meaning beyond the schema descriptions for inputPath and spinePath. The timeoutMs parameter lacks a description in both schema and tool description. Schema coverage is 67%, so baseline is 3, but the description provides no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs Spine CLI info for specified inputs like project, folder, JSON, or binary skeleton file. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like spine_export or spine_pack.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states what it does, without any context on prerequisites, exclusions, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes the high-level function without disclosing behavioral traits such as side effects (e.g., file creation/modification), required permissions, rate limits, or error conditions. This leaves the agent without essential context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence of 20 words. It is front-loaded with the verb 'Export' and immediately conveys the core functionality. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and no annotations, the description is too brief. It does not explain the export process, how parameters interact (e.g., overrides), or what the output is. The agent lacks sufficient context to use this tool effectively in complex workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 71% schema description coverage, the baseline is 3. The description adds minimal value beyond the schema, essentially reiterating that exportSettings can be a JSON file path or default modes. Other parameters like clean, inputPath, and outputPath are not elaborated in the description.
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 states the action ('Export'), the resource ('Spine project or data file'), and the method ('with export settings JSON file or default json/binary mode'). It effectively distinguishes this tool from sibling tools like spine_pack or spine_summarize_atlas, which handle different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for exporting Spine data, but it does not explicitly state when to use it versus alternatives like spine_pack for packing or spine_cli_info for information. No guidance on when not to use or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must inform about behavioral traits. It only states the action and configuration options but does not disclose side effects (e.g., overwriting output), permissions needed, performance impact, or failure modes. For a tool with 8 parameters, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core action efficiently without any filler. It is front-loaded with the primary purpose, making it easy for an AI agent to grasp quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema, no annotations), the description is too brief. It does not explain the packing process, output format, constraints, or any prerequisites, leaving significant gaps for an AI agent to understand correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, and the description adds some context for the 'pack' parameter by mentioning 'default settings or a pack settings JSON file'. However, it does not clarify the purpose of parameters like spinePath, timeoutMs, or updateVersion, which lack schema descriptions. The baseline of 3 is appropriate as the description provides marginal added value.
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 states the verb 'Pack' and the resource 'image folders into a Spine texture atlas', making the tool's purpose unambiguous. It distinguishes itself from sibling tools like spine_export (which exports in other formats) and spine_summarize_atlas (which summarizes existing atlases).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using 'default settings or a pack settings JSON file', implying two usage modes, but does not provide explicit guidance on when to use this tool versus alternatives like spine_export or when not to use it. No exclusion criteria or named sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavioral traits. It indicates a read-only operation (read and return counts) but does not mention side effects, prerequisites, or return format. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains the primary function. However, it could be enhanced with details about the return structure or file format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter atlasPath, with a description in the schema. The tool description adds no additional meaning beyond that baseline, meeting the baseline score.
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 states the action (Read), the resource (Spine .atlas file), and the result (page and region counts). It is specific and distinct from sibling tools like spine_summarize_json.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as spine_summarize_json or other sibling tools. The description lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavior. It correctly identifies the tool as a read operation that returns data, which is sufficient for a simple summarization tool. However, it does not detail output structure or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 13-word sentence that is front-loaded with the action and resource. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with full schema coverage, no output schema, and no annotations, the description adequately explains the tool's function and return categories. It could be improved by detailing the output format, but is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'jsonPath' is fully described in the input schema (100% coverage). The tool description does not add any additional semantic value beyond what the schema provides, meeting the baseline of 3.
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 states the tool reads exported Spine JSON and returns specific data (skeleton metadata, counts, skins, animations). It effectively distinguishes from siblings like spine_summarize_atlas which targets atlas files.
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 description implies usage for Spine JSON files, but does not explicitly contrast with alternatives or state when not to use it. Given the sibling context, the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sky-spine-mcp MCP server](https://glama.ai/mcp/servers/claudeskydream-hash/sky-spine-mcp/badges/card.svg)](https://glama.ai/mcp/servers/claudeskydream-hash/sky-spine-mcp)

Score Badge

Copy to your README.md:

[![sky-spine-mcp MCP server](https://glama.ai/mcp/servers/claudeskydream-hash/sky-spine-mcp/badges/score.svg)](https://glama.ai/mcp/servers/claudeskydream-hash/sky-spine-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/claudeskydream-hash/sky-spine-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server