Yggdrasil MCP

Server Quality Checklist

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

Latest release: v1.2.10
Disambiguation5/5
Each tool has a clearly distinct purpose: archiving plans, structured planning, retrieval, listing, promotion, and sequential reasoning. No two tools overlap in functionality, even the complementary deep_planning and sequential_thinking are well-differentiated.
Naming Consistency3/5
Most tools follow a verb_noun pattern (archive_plans, get_plan, list_plans, promote_plan), but deep_planning and sequential_thinking use an adjective+gerund format, breaking the pattern. This inconsistency could cause an agent to mispredict tool names.
Tool Count4/5
6 tools is a reasonable count for a domain-specific planning server. It covers the core lifecycle without being overwhelming, though a few more tools (e.g., delete_plan) would make it feel more complete.
Completeness3/5
The tools support creation, retrieval, listing, archiving, and promotion of plans, but lack explicit update and delete operations. The deep_planning workflow is thorough for new sessions, but editing or removing existing plans is not directly supported.
Average 4.2/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 7, 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.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that markdown format is only available for finalized plans, which is useful behavioral context. However, it does not describe error behavior (e.g., what happens if session ID is invalid or plan not finalized for markdown) or authentication requirements.
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, each serving a purpose. The first sentence states the primary function, and the second bulletizes the format options. No redundant or filler words.
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 (2 params, no output schema), the description is quite complete. It explains the purpose, required parameter, and format options with implications. However, it could benefit from clarifying what happens if a non-finalized plan is requested in markdown format or if the session ID is missing.
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%, so baseline is 3. The description adds meaning by explaining what each format returns: 'Rendered Markdown plan (default, only available for finalized plans)' and 'Raw JSONL event log (full session history for reconstruction).' This goes beyond the schema's simple enum 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 purpose: 'Retrieve a saved deep_planning session by its session ID.' It uses a specific verb ('retrieve') and resource ('deep_planning session'), and distinguishes itself from sibling tools like list_plans which lists sessions, and deep_planning which creates them.
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, such as list_plans or promote_plan. It does not mention any prerequisites or conditions like requiring a finalized plan for markdown format, but fails to clarify when to use each sibling.
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?
Discloses the destructive actions (moving files, removing index entries) and the dry run feature. Without annotations, the description carries the full burden and does so adequately, though more detail on reversibility could help.
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 sentences, no fluff, all essential information front-loaded.
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?
No output schema and no annotations, so description must cover more. It explains behavior and dry run but omits return value format and any prerequisites or side effects beyond those mentioned.
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. The description adds context for dryRun but little beyond what the schema provides for other 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 (archive), the resource (old planning sessions), and the effect (moving files to archive/YYYY/ subdirectory and removing from Yggdrasil index). It distinguishes well from sibling tools like list_plans and promote_plan.
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?
Provides guidance on dry run vs execution mode, implicitly telling when to use (archive old sessions). However, it lacks explicit contraindications or alternative tool mentions.
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?
With no annotations, the description carries the full burden. It discloses that results are paginated, sorted newest first, and notes that the status filter is Yggdrasil only. It implies a read operation without side effects.
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 with a clear first sentence, then bullet-pointed filters, and a final sentence about pagination and sorting. Every sentence adds value, 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 no output schema, the description explains the paginated, sorted-by-date response. All five parameters are covered with defaults and restrictions. It could mention what fields are in the output, but for a list tool this is adequate.
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%, so baseline is 3. The description adds meaningful context: status filter is Yggdrasil-only, source default is yggdrasil, keyword is case-insensitive, limit max 50, offset default 0. This enriches the parameter definitions.
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 it lists saved planning sessions and discovered plan files, which is a specific verb+resource. It distinguishes from sibling tools like archive_plans, get_plan, promote_plan, etc., which have different actions.
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 explains what the tool does and the optional filters, but it does not provide explicit guidance on when to use this tool vs. alternatives like get_plan or deep_planning. No when-not-to-use or comparison with siblings.
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?
With no annotations provided, the description carries the full burden and does well: it discloses that the tool renames files to a specific format, adds to an index, and has a prerequisite (file not already tracked). This goes beyond the schema's parameter descriptions.
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, with three clear sentences. The first sentence states the primary purpose, followed by the transformation detail and constraint. No superfluous text.
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 simple 2-parameter tool with no output schema, the description covers purpose, transformation, and constraints adequately. It could mention return behavior or error states, but overall it provides sufficient context for an agent to use the tool correctly.
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%, but the description adds value by explaining that 'name' becomes part of the new filename in YYYYMMDD-{name}.md format and that 'filename' is the source file. This extra context helps the agent understand how parameters are used together.
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 ('Promote') and the resource ('Claude Code plan file to the Yggdrasil plans index'), and explains the transformation (renaming and indexing). It distinguishes from sibling tools like archive_plans and list_plans by the specific action of promotion.
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 provides a constraint ('Only works on .md files not already tracked in the index'), but lacks explicit guidance on when to use this tool vs alternatives or when not to use it. It offers partial context but no direct exclusions or alternatives.
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 bears full responsibility. It discloses that complex fields are JSON strings and that each phase returns valid next phases. It also mentions session resumption via sessionId and ID generation from planName. However, it does not explicitly state side effects, idempotency, or auth requirements, which are minor omissions.
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 long but well-structured: a summary sentence, a workflow list, and usage clarifications. Each sentence adds value, though it could be slightly more concise without losing meaning.
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 tool has 25 parameters and no output schema, the description explains the workflow and parameter usage well but falls short on return values. It only mentions that phases return valid next phases, lacking detail on the full output structure. This is a gap for an AI agent.
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%, so the baseline is 3. The description adds value by explaining which parameters are relevant per phase (e.g., 'name required for explore', 'problem required for init') and that complex fields are JSON strings, which is beyond the schema descriptions.
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 it is a 'structured planning tool that manages multi-phase planning sessions' and distinguishes itself from the sibling tool 'sequential_thinking' by noting it 'complements sequential_thinking' and 'tracks planning state'. The workflow phases are explicitly listed, providing a specific verb-resource-action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool vs. the sibling: 'Use sequential_thinking for deep reasoning between phases. Use deep_planning to record conclusions and track planning state.' It also outlines the workflow, making it clear how to proceed across phases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses key behaviors: ability to adjust total_thoughts, question/revise, branch, express uncertainty, generate and verify hypotheses, and iterate until satisfied. No contradictions.
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 well-structured with sections for purpose, when-to-use, key features, parameters, and guidelines. While lengthy, every section provides necessary information for a complex tool. Could be slightly more concise, but effective.
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 (9 parameters, iterative process) and no output schema details in the input, the description covers usage extensively. The presence of an output schema (indicated in context) fills the gap for return values. Adequate for the task.
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 description coverage is 100% with all parameters described. The description's 'Parameters explained' section adds context and examples beyond the schema, such as what 'thought' can include and how 'nextThoughtNeeded' should be used. This adds 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 tool is for dynamic and reflective problem-solving through thoughts, and explicitly lists use cases like breaking down complex problems, planning with room for revision, etc. It distinguishes from sibling tools that manage plans (archive_plans, get_plan, etc.) by focusing on the thinking process itself.
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?
Provides a bullet list of when to use (e.g., complex problems, planning, multi-step solutions) and a 'You should' list of guidelines. Does not explicitly state when not to use, but the context is clear enough. No mention of alternatives, but siblings are not direct substitutes.
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:

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

Score Badge

Copy to your README.md:

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

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