spine-mcp

by egorfedorov

Overview Schema Related Servers Score Discussions

Python

Local

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 action: packing, project creation, export, info, preview, batch, environment check, source inspection, and rigging. No two tools overlap in purpose.
Naming Consistency3/5
Tool names mix conventions: some verb_noun (pack_atlas, make_project), some nouns (project_info, spine_doctor), and single verbs (preview, batch). This inconsistency makes the set less predictable, though still readable.
Tool Count5/5
9 tools is well-scoped for a Spine workflow server, covering creation, conversion, inspection, preview, and batch operations without bloat.
Completeness5/5
The server covers the full lifecycle from source inspection and rigging to atlas packing, project conversion, info, preview, and batch processing. No obvious missing operations for the stated purpose.
Average 3.5/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
The description mentions the return value but does not disclose potential side effects (e.g., file modification, overwriting, required permissions) nor any behavioral traits beyond the basic action. With no annotations, this transparency gap is significant.
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 concise (two sentences), well-structured, and free of unnecessary details. It efficiently communicates the core functionality without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and return, but lacks details about the two unexplained parameters, potential prerequisites, error conditions, or how the output summaries are structured. This leaves some gaps, though it is not overly complex.
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 explains two parameters (roster_dir and out_root) by referencing them in the action, but leaves kind and make_editable unexplained. Since the schema provides no descriptions, the description only partially compensates for the missing parameter semantics.
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's action ('Rig every PhotoshopToSpine export subfolder under roster_dir into out_root/<name>/') and its output ('Returns per-character summaries'), providing a specific and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no indication of when to use this tool over alternatives, lacks prerequisites or conditions, and does not mention any specific use cases or limitations.
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 provided, the description carries the full burden of behavioral disclosure. It reveals the import/creation nature but omits critical details such as overwrite behavior, required permissions, return values, and what 'EDITABLE' implies for the output project.
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, front-loaded sentence with no wasted words. It efficiently communicates the core action without redundancy.
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?
For a tool with only two string parameters and no output schema, the description should clarify expected return behavior and side effects. It does not state whether the output file is created, overwritten, or what happens on failure, making it incomplete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), and the description only loosely maps runtime_json to 'runtime skeleton json' and out_spine to '.spine project'. It does not clarify formats, constraints, or provide examples, leaving agents to guess parameter semantics.
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 a specific action: importing a runtime skeleton json into an editable .spine project. This distinguishes it from siblings like export_project and pack_atlas, which perform 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning prerequisites, exclusions, or a preferred context, leaving the agent to infer usage from the name alone.
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 carries the full burden of behavioral disclosure. It does not mention side effects (e.g., file overwrites), required permissions, or what happens to existing files. The agent cannot infer whether this is a safe read-only operation or a mutating export.
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, front-loaded sentence that immediately conveys the action and key choices. It uses no filler and efficiently communicates the core purpose and format options.
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 sparse for a tool with no annotations and no output schema. It does not mention side effects (e.g., writing files, overwriting), required permissions, or what constitutes a successful result. The '+pack for atlas' hint touches on related functionality but doesn't clarify dependencies or edge cases.
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 explains the 'fmt' parameter with 'json|binary' and '+pack for atlas', adding meaning beyond the schema's default. It does not elaborate on 'project' or 'out_dir', but these are fairly self-explanatory from their names. Given 0% schema coverage, the description partially compensates but could be more explicit about all parameters.
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 a .spine project') and the resource (runtime files), with format options. This distinguishes it from siblings like pack_atlas and project_info, making its purpose unambiguous.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for generating runtime files but lacks context about prerequisites, scenarios, or boundaries with sibling tools like pack_atlas or preview.
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?
There are no annotations, and the description does not disclose side effects such as file creation (the output PNG) or whether it modifies existing rig data. It simply says 'Render a PNG' without stating if it is read-only or if it overwrites files, leaving behavioral ambiguity.
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 description is concise and uses a clear list format for parameters, avoiding unnecessary verbosity. It efficiently conveys the tool's purpose and parameter meanings, though the formatting with backticks and angle brackets is slightly cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core function and provides parameter defaults, but lacks a complete picture. It does not mention what the tool returns (e.g., the output path) and omits maxpx, so a user might be uncertain about the full input/output contract.
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 explains three of four parameters (rig_dir, images_dir, out_png) with useful defaults and context, but omits any explanation for maxpx. Since the schema has no parameter descriptions, this partial coverage leaves a gap in understanding the maxpx parameter's meaning or units.
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 explicitly states the tool renders a keyframe-montage PNG of a built rig with specific poses (idle/win/blink/pop), making its primary function clear. It also distinguishes itself from sibling tools like pack_atlas or export_project by focusing on preview generation.
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?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies it is for previewing a built rig but does not mention prerequisites, sequencing, or scenarios where other tools would be more appropriate.
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 of behavioral disclosure. 'Print' suggests a read-only operation, but the description does not state whether it reads from the file system, what the output format is, whether it has any side effects, or what error conditions may occur. The existence of an output schema is not reflected in the description, leaving the agent without a clear understanding of what to expect on success.
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 immediately identifies the tool's action and target. It contains no filler, is front-loaded with the purpose, and does not repeat information already available in the schema or tool name. Every word contributes to the tool's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with a structured output schema, the description is nearly adequate—it states what the tool produces and its input domain. However, it lacks clarification on the parameter's exact form (path vs. content) and offers no guidance against sibling tools like inspect_source. These gaps make the description minimally complete but not fully self-sufficient.
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 0% schema description coverage, the description must compensate for the parameter's meaning. It clarifies that 'project_or_json' refers to a '.spine project or skeleton .json', which adds some semantic value beyond the bare schema. However, it does not specify whether the parameter accepts a file path, file contents, or a URL, so the agent still has to guess the exact expected input format.
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 uses a specific verb+resource pattern: 'Print bones/slots/animations' identifies the exact output content, and it specifies the input scoping to '.spine project or skeleton .json'. This clearly distinguishes it from the sibling tools like pack_atlas or export_project, though it does not explicitly name an alternative for comparison.
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 used for inspecting the structural components of a Spine project or skeleton JSON, but it offers no explicit guidance on when to choose this tool over siblings like inspect_source or preview. There are no stated prerequisites or exclusions, so usage context is left entirely to the agent's inference.
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 full responsibility for behavioral disclosure. It does not mention any side effects, whether output files are overwritten, prerequisites, or the nature of the operation beyond 'pack.' This lack of detail is insufficient for an agent to anticipate consequences.
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, concise sentence that front-loads the core action and output. It contains no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description provides a minimal but adequate overview for a simple tool. It states the output files (.atlas and .png) but omits behavioral details like overwriting or directory creation, making it only partially complete for an agent to safely invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the three parameters (images_dir, out_dir, name). While parameter names are somewhat self-explanatory, the description adds no explicit meaning beyond the schema titles, leaving the agent to infer semantics from context.
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's function: 'Pack a folder of PNGs into <name>.atlas + <name>.png with the Spine packer.' It uses a specific verb (pack) and resource (folder of PNGs → atlas + png), distinguishing it from sibling tools like export_project or batch.
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?
Usage context is implied by the action ('Pack a folder of PNGs') but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion criteria. The description does not mention when it is appropriate or inappropriate to use.
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?
There are no annotations, so the description must fully disclose behavioral traits. It only states the action (report availability) without mentioning whether it is read-only, whether it has side effects, what it does if dependencies are missing, or any potential errors. The description is minimal and leaves many behavioral aspects unstated.
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, concise sentence that conveys the tool's function without any fluff. Every word contributes to clarity, and it is front-loaded with the action verb 'Report' immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity of a no-parameter doctor check, the description is adequate but incomplete. It does not specify what 'availability' entails (e.g., version checks, path requirements) or what the output format is (e.g., boolean, message). Without an output schema or annotations, the description could be more explicit about the return value and any caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is fully covered by the absence of properties. Per the rule, a baseline of 4 applies for zero-parameter tools. The description adds no parameter information, but since there are no parameters, there is nothing to clarify beyond the 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 states the tool's purpose: it reports on the availability of the Spine CLI and Python dependencies. This is a specific verb ('report') and resource, and it effectively distinguishes itself from sibling tools that handle project operations like packing, exporting, or previewing.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, such as running this before other tools, or conditions under which it should be called. The name 'doctor' implies a health check, but without explicit context, an agent may not know when to invoke it.
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?
With no annotations, the description carmers the full burden. It discloses output files, optional editable project emission, and the reservation of the 'kind' parameter (both values behave the same). However, it does not mention whether files are overwritten, if Spine CLI is required for all operations, or any side effects like source modification, leaving gaps in transparency.
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 description is concise at about 7 lines, with a front-loaded purpose sentence followed by a parameter list in pseudo-code style. Every line adds value, though the parameter list could be tightened slightly without losing information. Overall, well-structured 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?
Given the tool's complexity (6 params, no output schema) and absence of annotations, the description covers purpose, parameters, and return summary. It lacks details on error handling, overwrite behavior, or specific animation semantics, but is sufficient for an agent to invoke the tool correctly in most cases. A bit more detail on return structure would push it higher.
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?
Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains each of the six parameters clearly: source path format, out_dir destination, name default behavior, kind restriction, anims subset, and make_editable side-effect. This provides significant value beyond the schema's type/default fields.
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?
Description clearly states it builds a rigged + animated Spine skeleton from a cut-up character. The action (build) and resource (rigged + animated Spine skeleton) are specific, and it distinguishes itself from sibling tools like pack_atlas or make_project by focusing on the rigging and animation pipeline.
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 gives clear context about the tool's purpose (creating Spine skeleton from character assets) and input/output expectations, but does not explicitly mention when not to use it or compare to alternatives (e.g., preview, batch). It implies usage for rigging/animation tasks but lacks explicit 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 carries the full burden. It clearly discloses the non-destructive behavior: 'WITHOUT building anything.' This is an important behavioral trait that prevents the agent from expecting side effects. It does not mention permissions or error scenarios, but for a list operation, this is acceptable.
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 two sentences, front-loaded with the primary action and immediate clarification of its non-destructive nature. Every word earns its place, with no fluff or repetition.
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 tool's simplicity (one parameter, no output schema), the description is sufficiently complete. It explains what the tool does, what input it expects, and when to use it. It does not detail the exact structure of the returned list, but the phrase 'parts and detected head-state families' offers a reasonable expectation of the output content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only one parameter ('source'). The description compensates by specifying that the source is a '.psd or PhotoshopToSpine export folder', giving the agent an understanding of acceptable input values. It does not go into format details (e.g., path vs. URL), but it provides meaningful guidance beyond the bare 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 uses a specific verb ('List') and clearly identifies the resource ('.psd or PhotoshopToSpine export folder') and the output ('parts and detected head-state families'). It also distinguishes itself from siblings by stating it does this 'WITHOUT building anything' and is meant for confirming what will be rigged.
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 provides explicit usage context: 'Use this first to confirm what will be rigged.' This tells the agent when to use the tool, but does not explicitly mention alternatives or when not to use it. The guidance is clear but lacks exclusionary language.
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:

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

Score Badge

Copy to your README.md:

[![spine-mcp MCP server](https://glama.ai/mcp/servers/egorfedorov/spine-mcp/badges/score.svg)](https://glama.ai/mcp/servers/egorfedorov/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/egorfedorov/spine-mcp'

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