yuelinghuashu/story-cli

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 operation: listing, validating, reading/writing chapters, editing config, building, stats, importing, and creating. No two tools have overlapping responsibilities; even read_chapter and write_chapter are clearly separated by direction.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (scan_stories, read_chapter, write_chapter, edit_config, create_story, import_json). However, validate, build, and stats use single words that deviate from the pattern, though they remain intuitive and consistent in style.
Tool Count5/5
Nine tools is well-scoped for a story management CLI. Each tool covers a meaningful, non-redundant function within the domain, and the count feels neither sparse nor bloated.
Completeness4/5
The set covers the core lifecycle: create stories, read/write chapters, update config, list, validate, build, and get stats. A notable gap is the lack of delete operations (story/chapter) or any removal functionality, but agents can likely work around this via filesystem or CLI.
Average 3.8/5 across 9 of 9 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 4 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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?
无注释，描述未披露行为细节，如是否验证数据、是否覆盖现有故事、是否原子操作、错误处理等。对于写入类工具，缺乏这些信息会增加风险。
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?
一句话，完全简洁，无冗余信息，直接传达核心功能。
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?
作为导入工具，描述未说明返回结果、验证机制或对现有数据的影响，无输出模式，且无注释，信息不足以让代理安全调用。
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?
模式覆盖率100%，描述中简要列出了stories的可选字段（title必填等），但未超出模式已有信息，基线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?
说明为从JSON批量导入故事，动词明确（导入），资源明确（故事），且提到与CLI同构，有助于理解。能区别于兄弟姐妹工具如scan_stories、validate等。
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?
没有提供任何何时使用或何时不使用的指导，也未提及替代工具。描述仅说明功能，未给出上下文场景。
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 present, so the description must convey behavior. It only states that validation occurs, without disclosing whether the operation is read-only, what side effects (if any) exist, or whether errors are thrown or returned. This leaves the agent uncertain about the tool's impact.
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 efficiently communicates the tool's purpose and key validation areas. No unnecessary words or redundant information.
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?
The description adequately covers the scope of validation, mentioning the specific compliance dimensions. Since no output schema exists, return values need not be explained. It lacks details on exit status or output format, but this is not mandated given the context.
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 input schema is empty, so schema coverage is complete. Per the rubric, the baseline is 3 even without parameter details. The description adds no additional parameter semantics, which is acceptable given there are no parameters.
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 validates repository compliance, listing specific aspects (directory naming, required files, config schema, encoding). It distinguishes from siblings by focusing on compliance checks rather than scanning, reading, or writing content.
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 mentions an equivalent CLI command but lacks contextual direction such as 'use this before publishing' or 'instead of manual checks.'
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 states it rebuilds READMEs and returns logs, but does not mention potential side effects like overwriting files, prerequisites, or failure behaviors. This is a significant gap for a tool that likely performs destructive writes without any annotated safety hints.
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 that front-loads the core action and then states the return value. It contains zero filler and each clause adds necessary information. It is both concise and complete for its length.
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 low complexity (no params, no output schema), the description covers the essential elements: what it does (rebuilds all READMEs) and what it returns (build results and logs). It could mention prerequisites or side effects, but for a simple build tool, this is reasonably complete. The absence of annotations slightly lowers confidence, but the description is adequate for its scope.
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 coverage is trivially 100%. According to the baseline rule, a description with 0 params earns a baseline score of 4. The description doesn't need to add parameter details since none exist, and it doesn't introduce any conflicting or misleading information, so the baseline holds.
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's action ('重建所有 README') and its purpose ('等效 story build'), making it distinct from siblings like scan_stories or validate. It names the resource (READMEs) and the modifier (rebuild), which is specific and unambiguous. However, it doesn't explicitly contrast with sibling tools, so it earns a 4 rather than a 5.
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 when to use this tool (to rebuild READMEs) and provides a parenthetical equivalence ('等效 story build') that gives context, but it fails to specify when not to use it or mention any alternatives. It gives some contextual clue but lacks explicit guidance on choosing this over other tools, so it's only minimally adequate.
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 provided, the description must carry the full burden of behavioral disclosure. It does mention the concrete side effects (creating a folder, config.json, and text.md), which is useful. However, it does not disclose any potential side effects like overwriting existing files, permissions required, or failure modes. Given the lack of annotations, more detail would be expected, but the description does provide some transparency.
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 purpose ('create a new story') and follows with the key artifacts created. There is zero wasted wording, and it is appropriately sized for a create operation with well-documented parameters.
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 is brief but covers the essential action and resulting files. However, with 7 parameters and no output schema, it might benefit from explaining how parameters map to the created files (e.g., title used for folder name) or typical return values. The schema covers parameter descriptions, but the tool's overall behavior and outcomes are only partially described. It is adequate but not rich.
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 input schema fully describes all 7 parameters (100% coverage), so the baseline is 3. The description adds no extra information about parameters beyond what the schema already states. It mentions 'draft' in relation to content, but that is already indicated in the schema as 'initial draft' (初始正文). Therefore, it does not enhance parameter understanding 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 creates a new story, with a specific verb ('创建' meaning create) and resource (story). It elaborates on what constitutes a story (folder + config.json + text.md draft), which distinguishes it from sibling tools like read_chapter or write_chapter. It is unambiguous and specific.
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 this tool is for creating new stories, but it does not explicitly say when to use it versus alternatives. There is no mention of when not to use it or when another tool would be more appropriate. While the name and context make it clear, explicit guidance is absent, so it only meets the baseline of implied usage.
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 provided, so description carries full burden. It discloses atomic write and non-blocking validate behavior, but does not cover overwrite behavior, permissions, or error handling. Partial transparency.
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?
Single sentence, front-loaded with main action, zero wasted words. Efficient and clear.
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?
Tool is a write operation with moderate complexity. Description covers atomicity and validate behavior, but lacks details on return values (though no output schema exists) and prerequisites. It is adequate but not exhaustive.
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 description coverage is 100%, so baseline is 3. Description adds contextual value for 'validate' (checking compliance after write) but does not elaborate on folder or content semantics beyond 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?
Description states a specific verb ('write') and resource ('specified story'), explicitly mentioning atomic write to text.md)Skip. It clearly distinguishes from siblings like read_chapter and edit_config.
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?
Description implies usage for writing chapter content, but provides no exclusions or alternatives. It mentions validate=true for compliance check but does not discuss when not to use this tool versus create_story or import_json.
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 are provided, so the description carries the burden. It discloses the default behavior (concise list) and the verbose option, which is useful. However, it doesn't mention whether this is a read-only operation, any rate limits, or what happens if there are no stories. The description adds some behavioral context but not comprehensive.
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 that front-loads the purpose and then explains the parameter behavior. Every word earns its place; no fluff or 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?
The tool is simple (one optional parameter, no output schema, no nested objects), and the description covers the purpose, the parameter, and the default behavior. It's complete for this level of complexity. It could mention return format details, but with no output schema and a simple list, the description is 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?
Schema description coverage is 100% (the verbose parameter is fully described in the schema). The description adds a bit of context by explaining the default (false) and the trade-off (saving tokens), which is slightly beyond the schema. Baseline 3 is appropriate since the schema already covers the parameter.
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 lists all stories with metadata (title/type/status/word count/series), using a specific verb ('列出') and resource ('所有故事'). It distinguishes itself from siblings like read_chapter and write_chapter by focusing on story-level listing, and from stats by specifying metadata fields.
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 clear context on when to use it (to list stories and metadata) and mentions the default behavior (concise list to save tokens) with an option for full details. It doesn't explicitly state when not to use it or name alternatives, but the sibling context (read_chapter, write_chapter) makes the distinction implicit.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. The verb '获取' communicates that this is a retrieval/statistics operation, and the listed metrics give some idea of the output content. Still, it does not explain whether the tool reads all stored stories automatically, whether it invokes side effects, or what 'health' means behaviorally.
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 compact sentence with a parenthetical list of metrics. It is efficient, front-loaded, and every word adds value. There is no redundant text or unnecessary detail.
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 has zero parameters and no output schema, the description supplies a reasonable preview of the produced statistics. It lists five relevant dimensions and leaves little ambiguity about the tool's role. It could be richer, but for a simple retrieval/stats tool this is sufficient.
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 no parameters, so the input schema provides no meaningful additional semantics. The description adequately fills this void by indicating what dimensions the statistics cover, which is the only context needed for a parameterless retrieve-stats tool.
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 verb ('获取') and identifies the resource (故事库写作统计), then enumerates the exact kinds of statistics: total words, chapter count, series grouping, health, and repeated phrases. This is distinct from siblings like read_chapter, write_chapter, and validate, making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose strongly implies it is used when someone needs write/health statistics for the story library. However, the description does not explicitly explain when to prefer this over alternatives like validate or scan_stories, nor does it provide any exclusions or conditional prerequisites.
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 provided, the description carries full burden for behavioral disclosure. It adds useful context about tailLength saving tokens and on-demand loading, but does not mention the behavior of returning all chapter titles when chapterIndex is omitted (which is only in the schema). This is a non-critical but unstated behavioral aspect.
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, dense sentence (with a clause) that front-loads the core purpose and immediately explains the key parameter's benefit. No wasted words; every phrase adds value.
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?
With no output schema, the description does not mention the return format for the case when chapterIndex is omitted (returning a list of titles). While this is described in the schema, the description alone might leave an agent unaware of that behavior, and it does not explain error scenarios or permissions. It is minimally complete but could be more informative.
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?
Schema coverage is 100% for all three parameters, and the description adds meaning to tailLength by explaining its purpose (continuation and token savings). It does not add much on folder or chapterIndex beyond the schema, but the tailLength explanation goes beyond the schema, justifying a score above baseline.
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 chapter content of a specified story, with the ability to load on demand by chapter index. It effectively distinguishes from sibling tools like write_chapter or scan_stories by explicitly focusing on read operation for chapter content.
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 on when to use the tool (reading chapters, using tailLength for continuation) but does not explicitly exclude alternatives or provide when-not-to-use guidance. It implies usage for reading specific chapters, which is adequate given the sibling tools are clearly different actions.
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?
For a tool with no annotations, the description discloses key behavioral traits: null values remove optional fields, immutable identity/audit fields are protected, and repository-level schema validation happens before writing (failure means no write). This is a strong level of disclosure for a mutation tool, though return/error behavior is not mentioned.
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?
Three concise and information-dense sentences cover purpose, editable fields, null semantics, forbidden fields, validation behavior, and a required post-step. No wasted words.
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 tool's moderate complexity, lack of annotations, and no output schema, the description adequately covers key behaviors: allowed/forbidden fields, null handling, validation, and post-action build step. The agent can correctly invoke and assess the tool's effects.
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?
Schema coverage is 100%, and the description adds meaningful context beyond the schema by enumerating all editable fields, explicitly naming protected fields, and clarifying null-removal semantics. The folder parameter is self-explanatory with the example in its schema 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 tool updates metadata fields of story config.json, listing specific editable fields. This distinguishes it from siblings like write_chapter (chapter content) and create_story (story creation), with an explicit scope of 'metadata fields'.
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?
It clearly specifies which fields are allowed and which are forbidden, and instructs to run build afterward to update README. It does not explicitly name sibling alternatives, but the field scoping makes appropriate use reasonably clear.
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:

[![story-cli MCP server](https://glama.ai/mcp/servers/yuelinghuashu/story-cli/badges/card.svg)](https://glama.ai/mcp/servers/yuelinghuashu/story-cli)

Score Badge

Copy to your README.md:

[![story-cli MCP server](https://glama.ai/mcp/servers/yuelinghuashu/story-cli/badges/score.svg)](https://glama.ai/mcp/servers/yuelinghuashu/story-cli)

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/yuelinghuashu/story-cli'

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