Which integrations are available for this server?

Planned integration for orchestrating workflows through n8n, enabling AI-driven automation pipelines.

How do I use Yggdrasil MCP?

1. Click on "Deploy 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., "@Yggdrasil MCP Apply tree-of-thoughts reasoning to evaluate three different database designs" 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.

Yggdrasil MCP

by henrychong-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Yggdrasil MCP

npm version License: MIT Node.js

Reasoning orchestration MCP server — Tree of Thoughts with multi-agent evaluation.

A fork of Anthropic's @modelcontextprotocol/server-sequential-thinking with critical bug fixes and an ambitious roadmap for advanced reasoning capabilities.

Why Yggdrasil?

In Norse mythology, Yggdrasil is the World Tree connecting all realms. This MCP embodies that metaphor:

Branches = Different reasoning paths through possibility space
Roots = Deep foundational analysis (first principles)
Connections = Links between thoughts, revisions, and evaluations

Related MCP server: PromptSmith

Key Features

Current (v1.1.0)

6 MCP tools — sequential_thinking, deep_planning, list_plans, get_plan, promote_plan, archive_plans
Descriptive plan naming — Optional planName parameter generates dp-YYYYMMDD-{name} session IDs with duplicate detection
Plan lifecycle management — Promote Claude Code orphan plans, archive old plans, unified discovery across both systems
deep_planning tool — Structured multi-phase planning sessions (init → clarify → explore → evaluate → finalize)
Session resumption — Resume planning sessions by ID with JSONL persistence
Hybrid persistence — JSONL event log + Markdown plan export with JSON index
String coercion fix — Fixes Claude Code bug #3084 where MCP parameters are incorrectly serialized as strings
Oxlint + Biome — 50-100x faster linting, zero-config formatting
Break down complex problems into manageable steps
Revise and refine thoughts as understanding deepens
Branch into alternative paths of reasoning
Adjust the total number of thoughts dynamically
Generate and verify solution hypotheses

Roadmap

See the CLAUDE.md for details:

Mermaid diagram export
Thought history retrieval
Self-evaluation tools
Multi-agent evaluation (cross-model verification)
n8n workflow integration

Installation

Claude Desktop (recommended — one-click install)

Yggdrasil ships as a Claude Desktop Extension (.mcpb):

Download the latest .mcpb: packages.henrychong.com/yggdrasil-mcp/yggdrasil-mcp-latest.mcpb
Double-click the file — Claude Desktop opens an install dialog → click Install
Restart Claude Desktop

Requires Claude Desktop 1.8000 or later (bundles Node.js 24+).

Optionally verify integrity by comparing the SHA256 against SHA256SUMS:

shasum -a 256 ~/Downloads/yggdrasil-mcp-*.mcpb

Older versions remain available at packages.henrychong.com/yggdrasil-mcp/yggdrasil-mcp-{version}.mcpb.

Claude Cowork / Claude Code (plugin ZIP)

For Cowork / Code, install the plugin ZIP:

# Claude Code — local install
claude --plugin-dir https://packages.henrychong.com/yggdrasil-mcp/yggdrasil-mcp-latest.zip

For Cowork org admins (Teams / Enterprise): upload the ZIP via Organization settings → Plugins → Add plugins → Upload a file. All team members get the tools without further action.

Teams / Enterprise org admins

If your Claude workspace is on a Teams or Enterprise plan, an Owner can distribute Yggdrasil organisation-wide:

Surface	Where	Artefact
Claude Desktop	Organization settings → Connectors → Desktop → Add custom extension	`.mcpb`
Claude Cowork	Organization settings → Plugins → Add plugins → Upload a file	`.zip`

Both surface artefacts are attached to every GitHub Release. Mobile / browser-only Cowork remain out of scope (stdio MCP architecturally cannot reach those surfaces).

Claude Code

claude mcp add --scope user yggdrasil "npx -y yggdrasil-mcp"

Or add to ~/.claude.json:

{
  "mcpServers": {
    "yggdrasil": {
      "command": "npx",
      "args": ["-y", "yggdrasil-mcp"]
    }
  }
}

Claude Desktop

Add to your Claude Desktop config:

{
  "mcpServers": {
    "yggdrasil": {
      "command": "npx",
      "args": ["-y", "yggdrasil-mcp"]
    }
  }
}

Local Development

{
  "mcpServers": {
    "yggdrasil": {
      "command": "node",
      "args": ["/path/to/yggdrasil-mcp/dist/index.js"]
    }
  }
}

Recommended: CLAUDE.md Configuration

After installing the MCP server, add the following to your ~/.claude/CLAUDE.md (global instructions) to unlock quick-access triggerwords and ensure Claude Code can load the tools correctly.

Why this matters

Yggdrasil tools are deferred tools in Claude Code — their full schemas are not loaded until explicitly fetched. Without the configuration below, Claude Code won't know how to invoke the tools or respond to shorthand triggers. Adding this block enables:

Shorthand triggers (s1, s2, s3) for instant reasoning at different depth levels
Automatic ToolSearch so Claude Code loads the tool schema before first use
Correct thought calibration based on problem complexity

Add to `~/.claude/CLAUDE.md`

Copy the following block into your ~/.claude/CLAUDE.md file:

## Structured Reasoning (Yggdrasil MCP)

### sequential_thinking — Reflective Problem-Solving

**MANDATORY Trigger:** When `s1`, `s2`, or `s3` appears ANYWHERE in user input:
1. Load via `ToolSearch` query `select:mcp__yggdrasil__sequential_thinking`
2. Invoke with appropriate `totalThoughts`
3. Complete the full chain before responding

**This is NOT optional internal reasoning — you MUST call the external MCP tool.**

| Trigger | totalThoughts | Use Case |
|---------|---------------|----------|
| **s1** | 3-5 | Quick analysis, simple decisions |
| **s2** | 6-10 | Detailed analysis, multi-factor problems |
| **s3** | 12-20 | Comprehensive analysis, complex systems |

### deep_planning — Multi-Phase Planning Sessions

Use for structured planning that needs to track state across phases:
`init → clarify → explore → evaluate → finalize`

Best for: Architecture decisions, multi-approach evaluation, implementation planning with scored trade-offs.

Both tools are deferred — load via `ToolSearch` before first use.

ToolSearch (Recommended)

Yggdrasil tools are registered as deferred tools in Claude Code. This means their parameter schemas are not available until fetched via ToolSearch. The CLAUDE.md configuration above handles this automatically for the s1/s2/s3 triggers, but if you want to invoke the tools directly, use:

ToolSearch query: "select:mcp__yggdrasil__sequential_thinking"
ToolSearch query: "select:mcp__yggdrasil__deep_planning"

This fetches the full schema and makes the tool callable for the rest of the session.

Verification

After setup, test by typing s1 followed by a question in Claude Code. You should see Claude Code automatically invoke ToolSearch and then call sequential_thinking with 3-5 thoughts.

Tool: sequential_thinking

Facilitates a detailed, step-by-step thinking process for problem-solving and analysis.

Parameters

Required

Parameter	Type	Description
`thought`	string	The current thinking step
`nextThoughtNeeded`	boolean	Whether another thought step is needed
`thoughtNumber`	integer	Current thought number (≥1)
`totalThoughts`	integer	Estimated total thoughts needed (≥1)

Optional

Parameter	Type	Description
`isRevision`	boolean	Whether this revises previous thinking
`revisesThought`	integer	Which thought is being reconsidered
`branchFromThought`	integer	Branching point thought number
`branchId`	string	Branch identifier
`needsMoreThoughts`	boolean	If more thoughts are needed

Output

{
  "thoughtNumber": 3,
  "totalThoughts": 5,
  "nextThoughtNeeded": true,
  "branches": ["branch-a"],
  "thoughtHistoryLength": 3
}

Tool: deep_planning

Structured planning tool that manages multi-phase planning sessions. Complements sequential_thinking by tracking state while the LLM reasons deeply between phases.

Workflow

init → clarify* → explore+ → evaluate+ → finalize → done

Parameters

Parameter	Type	Phases	Description
`phase`	enum	All	`init`, `clarify`, `explore`, `evaluate`, `finalize`
`problem`	string	init	Problem statement
`planName`	string	init	Descriptive name → `dp-YYYYMMDD-{name}` session ID
`context`	string	init	Additional background
`constraints`	string	init	JSON array of constraint strings
`question`	string	clarify	Clarifying question
`answer`	string	clarify	Answer to the question
`branchId`	string	explore/evaluate	Unique approach identifier
`name`	string	explore	Short approach name
`description`	string	explore	Detailed approach description
`pros`/`cons`	string	explore	JSON arrays of strings
`feasibility`	number	evaluate	Score 0-10
`completeness`	number	evaluate	Score 0-10
`coherence`	number	evaluate	Score 0-10
`risk`	number	evaluate	Score 0-10 (lower is better)
`rationale`	string	evaluate	Reasoning for scores
`recommendation`	string	evaluate	`pursue`, `refine`, or `abandon`
`selectedBranch`	string	finalize	Branch ID of chosen approach
`steps`	string	finalize	JSON array of step objects
`risks`	string	finalize	JSON array of risk objects
`assumptions`	string	finalize	JSON array of strings
`successCriteria`	string	finalize	JSON array of strings
`format`	string	finalize	`markdown` (default) or `json`

Output

{
  "sessionId": "dp-abc123",
  "phase": "explore",
  "status": "ok",
  "approachCount": 2,
  "evaluationCount": 0,
  "validNextPhases": ["explore", "evaluate", "clarify"],
  "message": "Approach recorded..."
}

Plan Management Tools

list_plans

List saved plans with unified view of Yggdrasil plans and Claude Code orphans. Supports pagination, source filtering, and keyword search.

Parameter	Type	Description
`status`	enum	`complete` or `in-progress` (Yggdrasil only)
`keyword`	string	Case-insensitive search in title/problem text
`source`	enum	`yggdrasil` (default), `cc` (Claude Code orphans), `all`
`limit`	number	Max results (default 20, max 50)
`offset`	number	Skip first N results (default 0)

get_plan

Retrieve a saved session by ID. Formats: markdown (default, finalized plans) or jsonl (full event log).

promote_plan

Promote a Claude Code plan file to the Yggdrasil index. Renames the file to YYYYMMDD-{name}.md format and adds it to the index for unified discovery. Includes path traversal protection.

Parameter	Type	Description
`filename`	string	Current CC plan filename (e.g., `silly-parrot.md`)
`name`	string	Descriptive name (sanitized to kebab-case)

archive_plans

Archive old plans by moving files to archive/YYYY/ subdirectory. Supports archiving both Yggdrasil index entries and Claude Code orphan files. Default mode is dry run (preview only).

Parameter	Type	Description
`olderThan`	number	Archive plans older than N days
`sessionIds`	string	JSON array of specific session IDs
`source`	enum	`yggdrasil`, `cc`, `promoted`, `all`
`dryRun`	boolean	Preview mode (default: true)

Use Cases

Yggdrasil is designed for:

Complex problem decomposition — Break down multi-step problems
Iterative planning — Design with room for revision
Course correction — Analysis that adapts as understanding deepens
Scope discovery — Problems where the full scope isn't clear initially
Context maintenance — Tasks requiring state across multiple steps
Information filtering — Situations where irrelevant details need filtering

Configuration

Environment Variables

Variable	Default	Description
`DISABLE_THOUGHT_LOGGING`	`false`	Suppress stderr thought output

The String Coercion Fix

This fork addresses a critical bug in Claude Code (#3084) where MCP parameters are serialized as strings regardless of their schema type.

The Problem

// Claude Code sends:
{ nextThoughtNeeded: "true", thoughtNumber: "5" }

// Instead of:
{ nextThoughtNeeded: true, thoughtNumber: 5 }

Using z.coerce.boolean() is dangerous:

z.coerce.boolean().parse('false'); // Returns TRUE! (non-empty string = truthy)

Our Solution

// Safe coercion that correctly handles "false" → false
const coerceBoolean = (val: unknown): boolean => {
  if (typeof val === 'boolean') return val;
  if (typeof val === 'string') {
    if (val.toLowerCase() === 'true') return true;
    if (val.toLowerCase() === 'false') return false;
  }
  throw new Error(`Cannot coerce "${val}" to boolean`);
};

// Applied via z.preprocess (NOT z.coerce)
const booleanSchema = z.preprocess(coerceBoolean, z.boolean());

Development

# Install dependencies
pnpm install

# Build
pnpm build

# Run tests
pnpm test

# Lint
pnpm lint

# Format
pnpm format

# Full quality check
pnpm check

# Watch mode
pnpm watch

Requirements

Node.js >=24
pnpm (corepack-managed via packageManager field)

Upstream

This is a fork of @modelcontextprotocol/server-sequential-thinking.

We periodically sync relevant changes from upstream while maintaining our string coercion fix and additional features.

Changelog

See CHANGELOG.md for the full version history.

License

MIT License — see LICENSE file for details.

Contributing

Contributions are welcome! See CONTRIBUTING.md for guidelines.

All tests pass (pnpm test)
Linting passes (pnpm lint)
Code is formatted (pnpm format)
Version is incremented appropriately

Available Tools

6 tools

archive_plansArchive PlansA

Archive old planning sessions by moving files to archive/YYYY/ subdirectory. Default mode is dry run (preview only). Set dryRun to false to execute. Removes archived entries from the Yggdrasil index.

ParametersJSON Schema

Name	Required	Description
`dryRun`	No	Preview mode (default: true). Set to false to execute.
`source`	No	Filter by source
`olderThan`	No	Archive plans older than N days
`sessionIds`	No	JSON array of specific session IDs to archive

TDQS

A4.1/5.0

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.

deep_planningDeep PlanningA

A structured planning tool that manages multi-phase planning sessions. Complements sequential_thinking by tracking planning state while the LLM reasons deeply.

Workflow: init → clarify → explore → evaluate → finalize

init: Define the problem, context, and constraints
clarify: Record clarifying questions and answers (repeatable)
explore: Record approach branches with pros/cons (repeatable)
evaluate: Score approaches on feasibility, completeness, coherence, risk (repeatable)
finalize: Select best approach and generate structured implementation plan

Each phase returns valid next phases to guide the workflow. Complex fields (pros, cons, steps, risks, constraints) are passed as JSON strings.

Use sequential_thinking for deep reasoning between phases. Use deep_planning to record conclusions and track planning state.

ParametersJSON Schema

Name	Required	Description
`cons`	No	JSON array of disadvantage strings
`name`	No	Short approach name (required for explore)
`pros`	No	JSON array of advantage strings
`risk`	No	Risk score 0-10 (lower is better)
`phase`	Yes	Current planning phase
`risks`	No	JSON array of risk objects with description and mitigation
`steps`	No	JSON array of implementation step objects
`answer`	No	Answer to the clarifying question
`format`	No	Output format: markdown (default) or json
`context`	No	Additional background context
`problem`	No	Problem statement (required for init)
`branchId`	No	Unique approach identifier (required for explore/evaluate)
`planName`	No	Descriptive plan name (init phase only). Sanitized to kebab-case. Generates dp-YYYYMMDD-{name} session ID.
`question`	No	Clarifying question (required for clarify)
`coherence`	No	Coherence score 0-10
`rationale`	No	Reasoning for evaluation scores
`sessionId`	No	Resume a specific session by ID. Required when switching between multiple sessions. Ignored on init phase.
`assumptions`	No	JSON array of assumption strings
`constraints`	No	JSON array of constraint strings
`description`	No	Detailed approach description
`feasibility`	No	Feasibility score 0-10
`completeness`	No	Completeness score 0-10
`recommendation`	No	pursue, refine, or abandon
`selectedBranch`	No	Branch ID of chosen approach (required for finalize)
`successCriteria`	No	JSON array of success criteria strings

TDQS

A4.4/5.0

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.

get_planGet PlanA

Retrieve a saved deep_planning session by its session ID. Returns the plan in the requested format:

"markdown": Rendered Markdown plan (default, only available for finalized plans)
"jsonl": Raw JSONL event log (full session history for reconstruction)

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format: "markdown" (default) or "jsonl"
`sessionId`	Yes	The session ID to retrieve (e.g., "dp-kR3xT9vW")

TDQS

A3.8/5.0

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.

list_plansList PlansA

List saved planning sessions and discovered plan files. Supports optional filters:

status: "complete" (finalized plans) or "in-progress" (active sessions) — Yggdrasil only
keyword: Search in problem/title text (case-insensitive)
source: "yggdrasil" (default), "cc" (Claude Code orphans), or "all"
limit: Maximum results (default 20, max 50)
offset: Skip first N results (default 0)

Returns paginated results sorted by date (newest first).

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max results to return (default 20, max 50)
`offset`	No	Skip first N results (default 0)
`source`	No	Filter by source (default: yggdrasil)
`status`	No	Filter by status: "complete" or "in-progress"
`keyword`	No	Search keyword in problem/title text

TDQS

A4.2/5.0

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.

promote_planPromote PlanA

Promote a Claude Code plan file to the Yggdrasil plans index. Renames the file to YYYYMMDD-{name}.md format and adds it to the index for unified discovery. Only works on .md files not already tracked in the index.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Descriptive name for the plan (sanitized to kebab-case)
`filename`	Yes	Current filename of the plan (e.g., "silly-walking-parrot.md")

TDQS

A4.2/5.0

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.

sequential_thinkingSequential ThinkingA

A detailed tool for dynamic and reflective problem-solving through thoughts. This tool helps analyze problems through a flexible thinking process that can adapt and evolve. Each thought can build on, question, or revise previous insights as understanding deepens.

When to use this tool:

Breaking down complex problems into steps
Planning and design with room for revision
Analysis that might need course correction
Problems where the full scope might not be clear initially
Problems that require a multi-step solution
Tasks that need to maintain context over multiple steps
Situations where irrelevant information needs to be filtered out

Key features:

You can adjust total_thoughts up or down as you progress
You can question or revise previous thoughts
You can add more thoughts even after reaching what seemed like the end
You can express uncertainty and explore alternative approaches
Not every thought needs to build linearly - you can branch or backtrack
Generates a solution hypothesis
Verifies the hypothesis based on the Chain of Thought steps
Repeats the process until satisfied
Provides a correct answer

Parameters explained:

thought: Your current thinking step, which can include:
- Regular analytical steps
- Revisions of previous thoughts
- Questions about previous decisions
- Realizations about needing more analysis
- Changes in approach
- Hypothesis generation
- Hypothesis verification
nextThoughtNeeded: True if you need more thinking, even if at what seemed like the end
thoughtNumber: Current number in sequence (can go beyond initial total if needed)
totalThoughts: Current estimate of thoughts needed (can be adjusted up/down)
isRevision: A boolean indicating if this thought revises previous thinking
revisesThought: If is_revision is true, which thought number is being reconsidered
branchFromThought: If branching, which thought number is the branching point
branchId: Identifier for the current branch (if any)
needsMoreThoughts: If reaching end but realizing more thoughts needed

You should:

Start with an initial estimate of needed thoughts, but be ready to adjust
Feel free to question or revise previous thoughts
Don't hesitate to add more thoughts if needed, even at the "end"
Express uncertainty when present
Mark thoughts that revise previous thinking or branch into new paths
Ignore information that is irrelevant to the current step
Generate a solution hypothesis when appropriate
Verify the hypothesis based on the Chain of Thought steps
Repeat the process until satisfied with the solution
Provide a single, ideally correct answer as the final output
Only set nextThoughtNeeded to false when truly done and a satisfactory answer is reached

ParametersJSON Schema

Name	Required	Description
`thought`	Yes	Your current thinking step
`branchId`	No	Branch identifier
`isRevision`	No	Whether this revises previous thinking
`thoughtNumber`	Yes	Current thought number (numeric value, e.g., 1, 2, 3)
`totalThoughts`	Yes	Estimated total thoughts needed (numeric value, e.g., 5, 10)
`revisesThought`	No	Which thought is being reconsidered
`branchFromThought`	No	Branching point thought number
`needsMoreThoughts`	No	If more thoughts are needed
`nextThoughtNeeded`	Yes	Whether another thought step is needed

Output Schema

ParametersJSON Schema

Name	Required	Description
`branches`	Yes
`thoughtNumber`	Yes
`totalThoughts`	Yes
`nextThoughtNeeded`	Yes
`thoughtHistoryLength`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It discloses important traits: thoughts can be revised, branched, or backtracked; total_thoughts is adjustable; the process generates and verifies a hypothesis; and the tool repeats until satisfied. It does not clarify side effects, state persistence, or whether the tool stores thought history across calls, which are relevant for a 9-parameter tool with no annotations.

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 front-loaded with a good high-level summary, but it is lengthy and includes substantial repetition: the 'Key features' and 'You should' sections overlap heavily (e.g., revising thoughts, adding more thoughts, hypothesis generation/verification appear twice). This reduces conciseness and makes it harder to scan quickly.

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 purpose, usage scenarios, key features, and parameter meanings, which is fairly complete for a complex 9-parameter tool. However, with an output schema present, return value details are unnecessary; the main gap is the lack of sibling differentiation and clarification of state persistence, which would help an agent use it correctly in 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?

Schema description coverage is 100%, so the schema already documents each parameter. The description provides additional interpretive guidance on the meaning of 'thought' (listing types of thinking steps) and elaborates on nextThoughtNeeded and totalThoughts. That adds some value, but much of the parameter explanation repeats the schema descriptions, so the baseline 3 is appropriate.

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 states a specific tool purpose ('dynamic and reflective problem-solving through thoughts') and describes the mechanism (sequential thoughts that can build, question, or revise). It is clear what the tool does, but it does not explicitly distinguish itself from siblings or clarify the MCP vs. conceptual nature. Sibling names like deep_planning suggest related planning tools, so more differentiation would help.

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?

There is a clear 'When to use this tool' section listing several appropriate scenarios (breaking down complex problems, planning with revision, multi-step solutions, filtering irrelevant information). However, it does not state when not to use the tool or name alternatives among the siblings (e.g., deep_planning), which would make routing decisions more precise.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updatev1.2.11Sep 12, 2026

Changedsequential_thinking1 field changed

changedInput schema / required

Previous value: -[
-  "thought"
-]New value: +[
+  "thought",
+  "nextThoughtNeeded",
+  "thoughtNumber",
+  "totalThoughts"
+]

6 tool updatesv1.2.6Jul 10, 2026
- First observedarchive_plans
- First observeddeep_planning
- First observedget_plan
- First observedlist_plans
- First observedpromote_plan
- First observedsequential_thinking

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-09-12 02:30 across 6 tools

Disambiguation4/5

deep_planning and sequential_thinking have overlapping purposes but descriptions clarify the distinction: sequential_thinking is for deep reasoning while deep_planning is for structured planning state tracking. The six tools are otherwise distinct (archive_plans, get_plan, promote_plan, list_plans are clearly separate).

Naming Consistency4/5

Mostly consistent snake_case with verb_noun patterns (archive_plans, get_plan, list_plans, promote_plan). deep_planning and sequential_thinking deviate slightly as noun phrases, but remain readable and predictable.

Tool Count5/5

Six tools is well-suited for a specialized planning server, covering planning workflow, reasoning, and plan file management without redundancy.

Completeness4/5

Core lifecycle is covered: planning, reasoning, listing, retrieving, promoting, and archiving. Minor gaps include no delete or export, but these are workable around with existing tools.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

Need Help?

Related Servers

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
llm-orchestration-agent-mcp
ai.getvda
LLM Orchestration Agent (Mcp)
Agent Orchestration Autonomous Agents
1
llm-orchestration-agent-2
ai.getvda
MCP-Native LLM Orchestration Agent
Agent Orchestration AI & Machine Learning
1
llm-orchestration-mcp-agent
ai.getvda
LLM Orchestration MCP Agent
Autonomous Agents Agent Orchestration AI & Machine Learning
1

Related MCP Servers

MCP Reasoner
Autonomous Agents RAG Systems
parmarjh
A
license
C
quality
D
maintenance
A systematic reasoning MCP server for Claude Desktop, featuring Beam Search and Monte Carlo Tree Search to facilitate complex problem-solving and decision-making processes.
Updated 2 years ago (2025-01-07 03:45 UTC)
1
12
MIT
PromptSmith
Autonomous Agents Developer Tools RAG Systems
BlinkVoid
A
license
A
quality
B
maintenance
An MCP server that provides 'Reasoning as a Service' by analyzing tasks to select and generate meta-prompts from 40 distinct reasoning frameworks. It enables AI agents to optimize their execution strategy based on task complexity and category, featuring tools for strategy recommendation and performance tracking.
Updated 9 days ago (2026-09-05 07:08 UTC)
5
1
MIT
Athena MCP
AI & Machine Learning Autonomous Agents Developer Tools
DevvGwardo
A
license
A
quality
D
maintenance
An MCP server that provides a reasoning sidekick for tool-using agents with a single 'think' tool for tackling complex problems. It allows agents to consult powerful reasoning models like Claude Opus or GPT-5 only when needed, keeping costs low while maintaining control over side effects.
Updated 4 months ago (2026-05-06 17:38 UTC)
1
6 npm
3
MIT
MCP Thinking Server
Autonomous Agents AI & Machine Learning
VitalyMalakanov
A
license
Not graded
quality
D
maintenance
A powerful MCP server that enhances LLMs with advanced sequential thinking capabilities, supporting 19 thinking modes for structured reasoning and complex cognitive tasks.
Updated a year ago (2025-05-25 18:13 UTC)
17
MIT

Yggdrasil MCP

Why Yggdrasil?

Key Features

Current (v1.1.0)

Roadmap

Installation

Claude Desktop (recommended — one-click install)

Claude Cowork / Claude Code (plugin ZIP)

Teams / Enterprise org admins

Claude Code

Claude Desktop

Local Development

Recommended: CLAUDE.md Configuration

Why this matters

Add to ~/.claude/CLAUDE.md

ToolSearch (Recommended)

Verification

Tool: sequential_thinking

Parameters

Required

Optional

Output

Tool: deep_planning

Workflow

Parameters

Output

Plan Management Tools

list_plans

get_plan

promote_plan

archive_plans

Use Cases

Configuration

Environment Variables

The String Coercion Fix

The Problem

Our Solution

Development

Requirements

Upstream

Changelog

License

Contributing

Available Tools

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Add to `~/.claude/CLAUDE.md`