Which integrations are available for this server?

Provides tools for automating Spine asset pipeline tasks through the official Spine CLI, including exporting projects, packing texture atlases, summarizing JSON and atlas files, and validating runtime assets.

How do I use sky-spine-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sky-spine-mcp Export the hero.spine project to JSON format with texture packing." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

sky-spine-mcp

by claudeskydream-hash

Overview Schema Related Servers Score Discussions

JavaScript

Local

sky-spine-mcp

中文 | English

sky-spine-mcp 是一个面向 Spine 资源流水线的 MCP Server，用来通过 Spine 官方命令行工具自动执行导出、纹理打包、资源检查和文件摘要等任务。

它适合接入 Codex、Claude Desktop 或其他支持 MCP 的客户端，让 AI 可以在本地项目中调用 Spine CLI，完成常见的批处理工作。

本项目目前专注于文件级自动化：

导出 .spine 项目或 Spine 数据文件
打包纹理图集
查看 Spine CLI 信息输出
汇总导出的 JSON 与 atlas 文件
检查运行时资源目录是否完整

它不是 Spine 编辑器脚本 API，不能直接在 Spine UI 内创建骨骼、权重或关键帧。当前更可靠的自动化边界是通过 Spine CLI 处理项目文件、导出文件和图集资源。

环境要求

Node.js 20 或更高版本
已授权的 Spine 安装
可执行的 Spine CLI，例如 Spine、Spine.com、Spine.exe、Spine.sh，或通过 SPINE_CLI_PATH 指定路径

在 Windows 上，Spine 官方推荐使用 Spine.com，因为它会等待 Spine 退出，并把输出写到控制台。

Related MCP server: spine-anim-mcp

安装

npm install
npm run build

运行

$env:SPINE_CLI_PATH="C:\Program Files\Spine\Spine.com"
npm start

MCP 客户端配置

本地 MCP 配置示例：

{
  "mcpServers": {
    "sky-spine-mcp": {
      "command": "node",
      "args": ["D:/AIWorkSpace/GithubTool/sky-spine-mcp/dist/index.js"],
      "env": {
        "SPINE_CLI_PATH": "C:/Program Files/Spine/Spine.com"
      }
    }
  }
}

工具

`spine_cli_info`

运行 Spine CLI 信息命令：

Spine -i <path>

`spine_export`

导出 Spine 项目或数据文件：

Spine -i <project.spine> -o <output> -e <export.json>

exportSettings 也可以使用 json、binary、json+pack 或 binary+pack。

`spine_pack`

打包图片目录为 Spine 纹理图集：

Spine -i <images> -o <output> -p <pack.json-or-atlas-name>

`spine_summarize_json`

读取导出的 Spine JSON，返回 skeleton 元数据、数量统计、skins 和 animations。

`spine_summarize_atlas`

读取 .atlas 文件，返回图集页和 region 数量。

`spine_validate_assets`

扫描目录中的 .json/.skel、.atlas 和图片资源，检查运行时资源是否齐全。

开发

npm run dev
npm run build

说明

Spine CLI 参数行为可能随编辑器版本变化。如果命令因为启动器不识别新参数而失败，请更新 Spine launcher，或使用 Spine 官方文档中对应版本支持的 CLI 参数。

许可证

MIT

English

MCP server for automating common Spine asset pipeline tasks through the official Spine command line interface.

This project focuses on practical file-level automation:

export Spine projects or data files
pack texture atlases
inspect Spine CLI info output
summarize exported JSON and atlas files
validate runtime asset folders

It does not provide an editor scripting API for creating bones, weights, or keyframes inside the Spine UI. Spine currently exposes the reliable automation surface for these workflows through its CLI.

Requirements

Node.js 20 or newer
A licensed Spine installation
Spine CLI available as Spine, Spine.com, Spine.exe, Spine.sh, or configured with SPINE_CLI_PATH

On Windows, Spine's documentation recommends the command line executable Spine.com because it waits for Spine to exit and writes output to the console.

Install

npm install
npm run build

Run

$env:SPINE_CLI_PATH="C:\Program Files\Spine\Spine.com"
npm start

MCP Client Configuration

Example local MCP config:

{
  "mcpServers": {
    "sky-spine-mcp": {
      "command": "node",
      "args": ["D:/AIWorkSpace/GithubTool/sky-spine-mcp/dist/index.js"],
      "env": {
        "SPINE_CLI_PATH": "C:/Program Files/Spine/Spine.com"
      }
    }
  }
}

Tools

`spine_cli_info`

Runs Spine CLI info:

Spine -i <path>

`spine_export`

Exports a Spine project or data file:

Spine -i <project.spine> -o <output> -e <export.json>

exportSettings can also be json, binary, json+pack, or binary+pack.

`spine_pack`

Packs a folder of images:

Spine -i <images> -o <output> -p <pack.json-or-atlas-name>

`spine_summarize_json`

Reads exported Spine JSON and returns skeleton metadata, counts, skins, and animations.

`spine_summarize_atlas`

Reads a .atlas file and returns atlas page and region counts.

`spine_validate_assets`

Scans a folder for .json/.skel, .atlas, and page image files.

Development

npm run dev
npm run build

Notes

Spine CLI parameter behavior can vary by editor version. If a command fails because the launcher rejects a newer parameter, update the Spine launcher or use the CLI option documented by Spine for unknown parameters.

License

MIT

Available Tools

6 tools

spine_cli_infoSpine CLI infoC

Run Spine CLI info for a project, folder, JSON, or binary skeleton file.

ParametersJSON Schema

Name	Required	Description
`inputPath`	Yes	Path to a .spine project, exported data file, or folder.
`spinePath`	No	Optional path to Spine.com, Spine.exe, Spine.sh, or Spine executable.
`timeoutMs`	No

TDQS

C2.9/5.0

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.

spine_exportSpine exportB

Export a Spine project or data file with an export settings JSON file or default json/binary mode.

ParametersJSON Schema

Name	Required	Description
`clean`	No	Run animation cleanup before export.
`inputPath`	No	Optional project, JSON, binary file, or folder. Overrides export settings.
`spinePath`	No
`timeoutMs`	No
`outputPath`	No	Optional output file or folder. Overrides export settings.
`updateVersion`	No	Optional Spine editor version, for example 4.2.xx or latest.
`exportSettings`	Yes	Path to export settings JSON, or one of: json, binary, json+pack, binary+pack.

TDQS

B3.4/5.0

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.

spine_packSpine texture packB

Pack image folders into a Spine texture atlas using default settings or a pack settings JSON file.

ParametersJSON Schema

Name	Required	Description
`name`	No	Atlas name when pack is a settings JSON file.
`pack`	Yes	Texture atlas name, or path to a pack settings JSON file.
`inputPath`	Yes	Folder of images to pack.
`spinePath`	No
`timeoutMs`	No
`outputPath`	Yes	Folder where atlas and page images are written.
`projectPaths`	No	Optional .spine project paths used for mesh-aware whitespace stripping.
`updateVersion`	No

TDQS

B3.4/5.0

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.

spine_summarize_atlasSummarize Spine atlasA

Read a Spine .atlas file and return page and region counts.

ParametersJSON Schema

Name	Required	Description	Default
`atlasPath`	Yes	Path to a .atlas file.

TDQS

A3.6/5.0

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.

spine_summarize_jsonSummarize Spine JSONA

Read exported Spine JSON and return skeleton metadata, counts, skins, and animations.

ParametersJSON Schema

Name	Required	Description	Default
`jsonPath`	Yes	Path to exported Spine JSON.

TDQS

A4.2/5.0

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.

spine_validate_assetsValidate Spine assetsC

Check whether a folder contains expected Spine runtime assets.

ParametersJSON Schema

Name	Required	Description
`folderPath`	Yes	Folder to scan.
`requireAtlas`	No
`requireImages`	No

TDQS

C2.6/5.0

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.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.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.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

ChiR24-unreal_mcpOAuth
ai.smithery
Control Unreal Engine to browse assets, import content, and manage levels and sequences. Automate…
Developer Tools App Automation Multimedia Processing
2855
Caliper A
fit.caliper
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
Design Tools Software Architecture
102
God Mode AI Sprite Generator
co.godmodeai
Generate game sprite sheets and animations from an image, and clean up sprite backgrounds.
Image & Video Processing Games & Gamification AI & Machine Learning
2
Shade
io.github.Just-Moh-it
Search, inspect, organize, annotate, share, and automate creative assets in Shade.
Design Tools Content Management Systems
2

Related MCP Servers

spine-mcp
1425sd
A
license
A
quality
D
maintenance
Local MCP server for automating Spine projects via the official CLI, enabling AI tools to inspect, export, import, and add animations to .spine files.
Updated 4 months ago (2026-05-03 15:15 UTC)
16
15
11
Apache 2.0
spine-anim-mcp
Design Tools Multimedia Processing
K-ulucay
A
license
A
quality
C
maintenance
An MCP server that converts layered PSD characters into Spine 4.2 rigs with deterministic, parametric 2D/2.5D animations (idle, walk, run, jump, attack, hit) ready for the Spine editor and Unity.
Updated 3 months ago (2026-06-14 01:10 UTC)
4
MIT
spine-mcp
Games & Gamification Multimedia Processing
yb901104-wq
F
license
B
quality
C
maintenance
MCP server for reading, validating, and modifying Spine 4.1.24 JSON animation files, with tools for animation timeline editing, validation, preview, and agent integration.
Updated 3 months ago (2026-06-18 11:32 UTC)
36
Spine Motion MCP
Design Tools Multimedia Processing
nihatcagri44
A
license
Not graded
quality
C
maintenance
Enables authoring, preview, and export of Spine 2D skeletal animations via natural language from Claude Code or any MCP client, with a web dashboard and tools for keyframing, templates, and GIF preview.
Updated a month ago (2026-07-27 11:40 UTC)
2
MIT

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