What can you do with this server?

Claude Octopus is an MCP server that turns generic MCP clients into a multi-agent Claude Code orchestration system. Here's what you can do with it: * Run autonomous agents: Send tasks to Claude Code agents that read/write files, run shell commands, search codebases, and handle complex software engineering tasks end-to-end. * Continue conversations: Resume past sessions by session_id for follow-up questions and iterative, multi-step workflows. * Orchestrate multi-agent workflows: Coordinate multiple specialized agents (e.g., code reviewer, test writer, security auditor) under a shared timeline, with a coordinator agent dispatching tasks to others as internal MCP tools. * Fine-tune agents per invocation: Override model, working directory, tools, effort, budget, permission mode, and system prompt on each call. * Query cross-agent workflow timelines: List all workflow runs or inspect a specific run's sequence of agent calls (grouped by run_id), including costs and turns. * Retrieve full session transcripts: Fetch complete conversation history for any session from Claude Code's storage, with pagination support. * Generate HTML reports: Produce self-contained reports with agent sequences, cost breakdowns, and collapsible transcripts for individual runs or all runs. * Monitor via dashboard: View live stats, recent activity, total runs, invocations, costs, and errors via a local web dashboard (npx claude-octopus dashboard). * Automate configuration: Use the npx claude-octopus init wizard to set up pre-tuned agent teams from templates, or use the agent-factory tool to interactively generate custom agent configurations. * Flexible auth & permissions: Configure ANTHROPIC_API_KEY or CLAUDE_CODE_OAUTH_TOKEN per agent, and control tool access and permission modes (default, acceptEdits, bypassPermissions, plan) at the server or invocation level.

de en es ja ko ru zh

claude-octopus

by xiaolai

Overview Schema Related Servers Score Discussions

TypeScript

Local

Claude Octopus

One brain, many arms.

An MCP server that wraps the Claude Agent SDK, letting you run multiple specialized Claude Code agents — each with its own model, tools, system prompt, and personality — from any MCP client.

Why

Claude Code is powerful. But one instance does everything the same way. Sometimes you want a strict code reviewer that only reads files. A test writer that defaults to TDD. A cheap quick helper on Haiku. A deep thinker on Opus.

Claude Octopus lets you spin up as many of these as you need. Same binary, different configurations. Each one shows up as a separate tool in your MCP client.

Related MCP server: claude-agent-mcp

Prerequisites

Node.js >= 18
Claude Code — the Claude Agent SDK is bundled as a dependency, but it spawns Claude Code under the hood, so you need a working claude CLI installation
Anthropic API key (ANTHROPIC_API_KEY env var) or an active Claude Code OAuth session

Install

Three paths, pick whichever matches your MCP client.

npm (most direct)

npm install claude-octopus

npx (no install needed)

Skip the install entirely — reference claude-octopus@latest in your .mcp.json and the client will fetch on demand (see Quick Start below).

MCP Registry

The server is published to the MCP Registry under the name io.github.xiaolai/claude-octopus. Registry-aware MCP clients can resolve and install it by that name without touching npm directly.

Quick Start

The fastest way to get started:

npx claude-octopus init

This interactive wizard lets you pick a template, detects your MCP client, and writes the config for you.

Or add to your .mcp.json manually:

{
  "mcpServers": {
    "claude": {
      "command": "npx",
      "args": ["claude-octopus@latest"],
      "env": {
        "CLAUDE_PERMISSION_MODE": "bypassPermissions"
      }
    }
  }
}

This gives you six tools:

Tool	Purpose
`claude_code`	Send a task, get a result
`claude_code_reply`	Continue a conversation
`claude_code_timeline`	Query the workflow timeline
`claude_code_transcript`	Read full session transcripts
`claude_code_sessions`	List Claude Code session history (this project, or all)
`claude_code_report`	Generate HTML reports

That's it — you have Claude Code as a tool, with full workflow observability built in.

Multiple Agents

The real power is running several instances with different configurations:

{
  "mcpServers": {
    "code-reviewer": {
      "command": "npx",
      "args": ["claude-octopus@latest"],
      "env": {
        "CLAUDE_TOOL_NAME": "code_reviewer",
        "CLAUDE_SERVER_NAME": "code-reviewer",
        "CLAUDE_DESCRIPTION": "Strict code reviewer. Finds bugs and security issues. Read-only.",
        "CLAUDE_MODEL": "opus",
        "CLAUDE_ALLOWED_TOOLS": "Read,Grep,Glob",
        "CLAUDE_APPEND_PROMPT": "You are a strict code reviewer. Report real bugs, not style preferences.",
        "CLAUDE_EFFORT": "high"
      }
    },
    "test-writer": {
      "command": "npx",
      "args": ["claude-octopus@latest"],
      "env": {
        "CLAUDE_TOOL_NAME": "test_writer",
        "CLAUDE_SERVER_NAME": "test-writer",
        "CLAUDE_DESCRIPTION": "Writes thorough tests with edge case coverage.",
        "CLAUDE_MODEL": "sonnet",
        "CLAUDE_APPEND_PROMPT": "Write tests first. Cover edge cases. TDD."
      }
    },
    "quick-qa": {
      "command": "npx",
      "args": ["claude-octopus@latest"],
      "env": {
        "CLAUDE_TOOL_NAME": "quick_qa",
        "CLAUDE_SERVER_NAME": "quick-qa",
        "CLAUDE_DESCRIPTION": "Fast answers to quick coding questions.",
        "CLAUDE_MODEL": "haiku",
        "CLAUDE_MAX_BUDGET_USD": "0.02",
        "CLAUDE_EFFORT": "low"
      }
    }
  }
}

Your MCP client now sees distinct tools for each agent — code_reviewer, test_writer, quick_qa — each purpose-built.

Multi-Agent Orchestration

Agents can coordinate through a coordinator pattern: one agent has the others as inner MCP tools via CLAUDE_MCP_SERVERS, and its system prompt drives the pipeline.

{
  "mcpServers": {
    "publishing-house": {
      "command": "npx",
      "args": ["claude-octopus@latest"],
      "env": {
        "CLAUDE_TOOL_NAME": "publishing_house",
        "CLAUDE_SERVER_NAME": "publishing-house",
        "CLAUDE_MODEL": "opus",
        "CLAUDE_PERMISSION_MODE": "bypassPermissions",
        "CLAUDE_APPEND_PROMPT": "You are a publishing house coordinator. Dispatch tasks to your specialist agents and drive the pipeline to completion.",
        "CLAUDE_MCP_SERVERS": "{\"researcher\":{\"command\":\"npx\",\"args\":[\"claude-octopus@latest\"],\"env\":{\"CLAUDE_TOOL_NAME\":\"researcher\",\"CLAUDE_SERVER_NAME\":\"researcher\",\"CLAUDE_MODEL\":\"sonnet\",\"CLAUDE_PERMISSION_MODE\":\"bypassPermissions\"}},\"architect\":{\"command\":\"npx\",\"args\":[\"claude-octopus@latest\"],\"env\":{\"CLAUDE_TOOL_NAME\":\"architect\",\"CLAUDE_SERVER_NAME\":\"architect\",\"CLAUDE_MODEL\":\"opus\",\"CLAUDE_PERMISSION_MODE\":\"bypassPermissions\"}}}"
      }
    }
  }
}

The coordinator agent autonomously calls researcher, architect, etc. as MCP tools — fully autonomous, no human in the loop until it finishes. Every invocation is tracked in the shared timeline.

Agent Factory

Don't want to write configs by hand? Add a factory instance:

{
  "mcpServers": {
    "agent-factory": {
      "command": "npx",
      "args": ["claude-octopus@latest"],
      "env": {
        "CLAUDE_FACTORY_ONLY": "true",
        "CLAUDE_SERVER_NAME": "agent-factory"
      }
    }
  }
}

This exposes a single create_claude_code_mcp tool — an interactive wizard. Tell it what you want ("a strict code reviewer that only reads files") and it generates the .mcp.json entry for you, listing all available options you can customize.

In factory-only mode, no query tools are registered — just the wizard. This keeps routing clean: the factory creates agents, the agents do work.

Init Wizard

Don't want to edit JSON by hand? The init wizard gets you from zero to working in 30 seconds:

npx claude-octopus init

  Claude Octopus — init wizard

  One brain, many arms. Let's set up your agents.

Pick a template (or build your own):

  1. Code Review Team — Reviewer + test writer + security auditor
  2. Publishing House — Researcher + architect + editor + proofreader
  3. Tiered Models — Haiku for quick Q&A, Sonnet for coding, Opus for hard problems
  4. Solo Agent — Single Claude Code agent with sensible defaults
  5. Agent Factory — Interactive wizard that generates agent configs on demand
  6. Custom — describe your own agent(s)

Choice [1-6]:

It auto-detects installed MCP clients (Claude Desktop, Claude Code, Cursor, Windsurf), merges with existing config, and warns before overwriting.

npx claude-octopus init --template code-review-team
npx claude-octopus init --template tiered-models
npx claude-octopus init --template publishing-house

Templates

Five built-in templates, battle-tested and ready to use:

Template	Agents	Purpose
`code-review-team`	code-reviewer (opus), test-writer (sonnet), security-auditor (opus)	Thorough code review pipeline
`publishing-house`	researcher (sonnet), architect (opus), editor (sonnet), proofreader (haiku)	Multi-stage content/code pipeline
`tiered-models`	quick-qa (haiku), coder (sonnet), deep-thinker (opus)	Right model for the job
`solo-agent`	claude (default)	Single agent, quick setup
`factory`	agent-factory	Generates configs on demand

Each agent comes pre-tuned with appropriate model, tools, effort level, and system prompt.

Dashboard

Monitor your agents in real time:

npx claude-octopus dashboard

Opens a local web dashboard at http://localhost:3456 with:

Live stats — total runs, invocations, cost, SDK turns, responses, errors
Recent activity — agent cards for the latest run
Run table — all runs with cost, duration, and status
Auto-refresh — SSE connection pushes updates as agents run

# Custom port
npx claude-octopus dashboard --port 8080

The dashboard reads the same timeline index used by the _timeline and _report tools. No additional configuration needed.

Tools

Each non-factory instance exposes:

Tool	Purpose
`<name>`	Send a task to the agent, get a response + `session_id` + `run_id`
`<name>_reply`	Continue a previous conversation by `session_id`
`<name>_timeline`	Query the cross-agent workflow timeline
`<name>_transcript`	Retrieve full session transcript from Claude Code's storage
`<name>_sessions`	List Claude Code session history — this project by default, or all projects with `all_projects: true`
`<name>_report`	Generate a self-contained HTML report for a run or all runs

Query and reply parameters

Parameter	Description
`prompt`	The task or question (required)
`run_id`	Workflow run ID — groups related agent calls into one timeline. Auto-generated if omitted; returned in every response for propagation.
`cwd`	Working directory override
`model`	Model override (`sonnet`, `opus`, `haiku`, or full ID)
`tools`	Restrict available tools (intersects with server restriction)
`disallowedTools`	Block additional tools (unions with server blacklist)
`additionalDirs`	Extra directories the agent can access
`plugins`	Additional plugin paths to load
`effort`	Thinking effort (`low`, `medium`, `high`, `max`)
`permissionMode`	Permission mode (can only tighten, never loosen)
`maxTurns`	Max agent-loop round trips (see effort counters)
`maxBudgetUsd`	Max spend in USD
`systemPrompt`	Additional prompt (appended to server default)

Timeline

Every agent invocation is recorded in a lightweight JSONL index at ~/.claude-octopus/timelines/timeline.jsonl. This solves the multi-agent correlation problem: when several agents participate in a workflow, the timeline tracks which sessions belong to the same run, in what order they executed, and what role each played.

Full session transcripts stay in Claude Code's own storage (~/.claude/projects/). The timeline is just the table of contents — ~200 bytes per entry — that cross-references via session_id.

graph TB
    subgraph "Timeline Index (~200 bytes/entry)"
        TL["~/.claude-octopus/timelines/timeline.jsonl"]
    end

    subgraph "Claude Code Session Storage (full transcripts)"
        S1["~/.claude/projects/.../ses-aaa.jsonl"]
        S2["~/.claude/projects/.../ses-bbb.jsonl"]
        S3["~/.claude/projects/.../ses-ccc.jsonl"]
    end

    TL -->|"session_id cross-ref"| S1
    TL -->|"session_id cross-ref"| S2
    TL -->|"session_id cross-ref"| S3

How it works

Every <name> and <name>_reply call appends one line to the timeline
If you pass run_id, all agents sharing the same run_id are grouped into one run
If you omit run_id, one is auto-generated and returned in the response — pass it to subsequent agents to keep them grouped

Querying the timeline

# List all runs
<name>_timeline({})

# Show one run's agent sequence
<name>_timeline({ run_id: "abc-123" })

# Look up a specific session
<name>_timeline({ session_id: "ses-xyz" })

# Retrieve full transcript (separate tool)
<name>_transcript({ session_id: "ses-xyz" })

Multi-agent workflow example

Host:  researcher({ prompt: "Research X", run_id: "pub-001" })
       → { run_id: "pub-001", session_id: "ses-aaa", result: "..." }

Host:  architect({ prompt: "Structure based on...", run_id: "pub-001" })
       → { run_id: "pub-001", session_id: "ses-bbb", result: "..." }

Host:  verifier({ prompt: "Check this plan", run_id: "pub-001" })
       → { run_id: "pub-001", session_id: "ses-ccc", result: "..." }

Later: researcher_timeline({ run_id: "pub-001" })
       → [
           { agent: "researcher", session_id: "ses-aaa", cost: 0.05, turns: 4, tool_calls: 3, response_groups: 2 },
           { agent: "architect",  session_id: "ses-bbb", cost: 0.08, turns: 6, tool_calls: 5, response_groups: 3 },
           { agent: "verifier",   session_id: "ses-ccc", cost: 0.03, turns: 3, tool_calls: 2, response_groups: 2 },
         ]

Later: researcher_transcript({ session_id: "ses-aaa" })
       → full conversation transcript from Claude Code's storage

HTML Reports

Generate self-contained HTML reports with agent sequence visualization, cost breakdown, and collapsible transcripts. Dark theme, no external dependencies — one file, open in any browser.

Via MCP tool

<name>_report({})                        # index of all runs
<name>_report({ run_id: "pub-001" })     # detailed report for one run

Via CLI

# Index of all runs
npx claude-octopus report --out index.html

# Detailed report for one run
npx claude-octopus report pub-001 --out report.html
open report.html

# Without transcripts (faster, smaller file)
npx claude-octopus report pub-001 --no-transcripts --out report.html

# To stdout (pipe-friendly)
npx claude-octopus report pub-001 > report.html

What's in the report

Run summary — agent count, total cost, duration, SDK turns, responses, tool calls
Timeline bar — numbered dots for each agent (green = success, red = error)
Agent cards — timing, cost, effort counters, session ID, prompt excerpt
Collapsible transcripts — full tool calls, reasoning, and results per agent

Reading the effort counters

Three numbers describe how much work an invocation took. They are not interchangeable, and the first one is the one that surprises people:

Metric	What it counts
`num_turns` (shown as SDK turns)	Raw value from the Agent SDK. Measured against the runtime it tracks `tool_use` blocks plus the final response — not API round trips.
`response_groups` (responses)	Distinct assistant responses in the main agent loop — one per API round trip, no matter how many tools that response called in parallel.
`tool_calls` (tool calls)	`tool_use` blocks issued across the main agent loop.

When an agent calls several tools in parallel, num_turns climbs faster than the number of visible responses. A run with 3 assistant responses issuing 4 tool calls reports num_turns: 5, response_groups: 3, tool_calls: 4. maxTurns, meanwhile, is enforced against round trips: that same run completes under maxTurns: 3 and aborts under maxTurns: 2. So size maxTurns against responses, not against SDK turns.

Both new counters cover the main agent loop only — work inside a sub-agent (Task) belongs to its own loop and is excluded. Timeline entries written by older versions have neither, and render as — rather than as a false zero.

Configuration

All configuration is via environment variables in .mcp.json. Every env var is optional.

Identity

Env Var	Description	Default
`CLAUDE_TOOL_NAME`	Tool name prefix (generates `<name>`, `<name>_reply`, `<name>_timeline`, `<name>_transcript`, `<name>_report`)	`claude_code`
`CLAUDE_DESCRIPTION`	Tool description shown to the host AI	generic
`CLAUDE_SERVER_NAME`	MCP server name in protocol handshake	`claude-octopus`
`CLAUDE_FACTORY_ONLY`	Only expose the factory wizard tool	`false`

Agent

Env Var	Description	Default
`CLAUDE_MODEL`	Model (`sonnet`, `opus`, `haiku`, or full ID)	SDK default
`CLAUDE_CWD`	Working directory	`process.cwd()`
`CLAUDE_PERMISSION_MODE`	`default`, `acceptEdits`, `bypassPermissions`, `plan`	`default`
`CLAUDE_ALLOWED_TOOLS`	Comma-separated tool restriction (available tools)	all
`CLAUDE_DISALLOWED_TOOLS`	Comma-separated tool blacklist	none
`CLAUDE_MAX_TURNS`	Max agent-loop round trips per invocation	unlimited
`CLAUDE_MAX_BUDGET_USD`	Max spend per invocation	unlimited
`CLAUDE_EFFORT`	`low`, `medium`, `high`, `max`	SDK default

Prompts

Env Var	Description
`CLAUDE_SYSTEM_PROMPT`	Replaces the default Claude Code system prompt
`CLAUDE_APPEND_PROMPT`	Appended to the default prompt (usually what you want)

Advanced

Env Var	Description
`CLAUDE_ADDITIONAL_DIRS`	Extra directories to grant access (comma-separated)
`CLAUDE_PLUGINS`	Local plugin paths (comma-separated)
`CLAUDE_MCP_SERVERS`	MCP servers for the inner agent (JSON)
`CLAUDE_PERSIST_SESSION`	`true`/`false` — enable session resume (default: `true`)
`CLAUDE_SETTING_SOURCES`	Settings to load: `user`, `project`, `local`
`CLAUDE_SETTINGS`	Path to settings JSON or inline JSON
`CLAUDE_BETAS`	Beta features (comma-separated)

Timeline

Env Var	Description	Default
`CLAUDE_TIMELINE_DIR`	Directory for the cross-agent timeline index	`~/.claude-octopus/timelines`

Authentication

Env Var	Description	Default
`ANTHROPIC_API_KEY`	Anthropic API key for this agent	inherited from parent
`CLAUDE_CODE_OAUTH_TOKEN`	Claude Code OAuth token for this agent	inherited from parent

Leave both unset to inherit auth from the parent process. Set one per agent to use a different account or billing source.

Lists accept JSON arrays when values contain commas: ["path,with,comma", "/normal"]

Security

Permission mode defaults to default — tool executions prompt for approval unless you explicitly set bypassPermissions.
cwd overrides preserve agent knowledge — when the host overrides cwd, the agent's configured base directory is automatically added to additionalDirectories so it retains access to its own context.
Tool restrictions narrow, never widen — per-invocation tools intersects with the server restriction (can only remove tools, not add). disallowedTools unions (can only block more).
_reply and _transcript tools respect persistence — not registered when CLAUDE_PERSIST_SESSION=false.
Timeline writes are best-effort — a failed timeline append never blocks or fails the primary query.

Architecture

graph TB
    subgraph "MCP Client (Claude Desktop, Cursor, etc.)"
        C["Sees: code_reviewer, test_writer, quick_qa"]
    end

    C -->|"JSON-RPC / stdio"| O1
    C -->|"JSON-RPC / stdio"| O2
    C -->|"JSON-RPC / stdio"| O3

    subgraph "Claude Octopus Instances"
        O1["code-reviewer<br/>model=opus, tools=Read,Grep,Glob"]
        O2["test-writer<br/>model=sonnet"]
        O3["quick-qa<br/>model=haiku, budget=$0.02"]
    end

    O1 -->|"Agent SDK query()"| SDK["Claude Agent SDK"]
    O2 -->|"Agent SDK query()"| SDK
    O3 -->|"Agent SDK query()"| SDK

    O1 -->|"append"| TL["Timeline Index<br/>~/.claude-octopus/timelines/"]
    O2 -->|"append"| TL
    O3 -->|"append"| TL

    SDK -->|"persist"| SS["Session Storage<br/>~/.claude/projects/"]
    TL -.->|"cross-ref"| SS

How It Compares

Feature	Built-in `claude`	claude-code-mcp	Claude Octopus
Approach	Built-in	CLI wrapping	Agent SDK
Tools per instance	16 raw tools	1 prompt tool	5 (prompt, reply, timeline, transcript, report)
Multi-instance	No	No	Yes
Per-instance config	No	No	Yes (20 env vars)
Init wizard	No	No	Yes (`init` + 5 templates)
Factory wizard	No	No	Yes
Session continuity	No	No	Yes
Cross-agent timeline	No	No	Yes
Web dashboard	No	No	Yes (live, SSE)
HTML reports	No	No	Yes

Development

pnpm install
pnpm build       # compile TypeScript
pnpm test        # run tests (vitest)
pnpm test:coverage  # coverage report

License

ISC - Xiaolai Li

Available Tools

5 tools

claude_codeA

Send a task to an autonomous Claude Code agent. It reads/writes files, runs shell commands, searches codebases, and handles complex software engineering tasks end-to-end. Returns the result text plus a session_id for follow-ups via claude_code_reply.

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	Task or question for Claude Code
`run_id`	No	Workflow run ID — groups related agent calls into one timeline. Auto-generated if omitted; returned in every response for propagation.
`cwd`	No	Working directory (overrides CLAUDE_CWD)
`model`	No	Model override (e.g. "sonnet", "opus", "haiku")
`tools`	No	Restrict available tools to this list (intersects with server-level restriction)
`disallowedTools`	No	Additional tools to block (unions with server-level blacklist)
`additionalDirs`	No	Extra directories the agent can access for this invocation
`plugins`	No	Additional plugin paths to load for this invocation (unions with server-level plugins)
`effort`	No	Thinking effort override
`permissionMode`	No	Permission mode override (can only tighten, never loosen)
`maxTurns`	No	Max conversation turns
`maxBudgetUsd`	No	Max spend in USD
`systemPrompt`	No	Additional system prompt (appended to server default)

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral disclosure burden. It honestly describes the agent's autonomous capabilities (read/write files, run shell commands), implying potential side effects. However, it does not disclose safety constraints, permission requirements, or destructive potential beyond what is implied.

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: the first states purpose and capabilities, the second explains return value and follow-up mechanism. Every sentence adds value, no redundancy, and key information is front-loaded.

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?

While the tool has many parameters and no output schema, the description covers the essential outcome (result text + session_id) and follow-up usage. For a complex tool, it provides sufficient context, though more detail on return format or behavior with various parameters could improve completeness.

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%, meaning all 13 parameters have descriptions in the schema. The description does not add additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 sends tasks to an autonomous Claude Code agent and lists specific capabilities (reads/writes files, runs shell commands, searches codebases). It distinguishes from sibling tools by noting it returns a session_id for follow-ups via claude_code_reply.

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 implicitly provides usage guidelines by stating return of session_id for follow-ups, indicating when to use this tool (initial task) vs claude_code_reply (follow-up). No explicit when-not or alternatives, but context is clear.

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

claude_code_replyA

Continue a previous claude_code conversation by session ID. Use this for follow-up questions, iterative refinement, or multi-step workflows that build on prior context.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes	Session ID from a prior claude_code response
`prompt`	Yes	Follow-up instruction or question
`run_id`	No	Workflow run ID — pass the same run_id from the original call to keep entries grouped.
`cwd`	No	Working directory override
`model`	No	Model override
`maxTurns`	No	Max conversation turns
`maxBudgetUsd`	No	Max spend in USD

TDQS

A4/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 burden. It indicates state continuation but does not disclose behaviors like session validity, error handling, or whether the operation is safe. This is adequate 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?

Two sentences, no fluff, front-loaded with purpose. Every sentence earns its place.

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 7 parameters, no annotations, and no output schema, the description covers the essential purpose and usage. It could be more complete about return values or limitations, but it is sufficient for a continuation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds minimal extra context (e.g., 'from a prior claude_code response'). Baseline 3 is appropriate.

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 continues a previous claude_code conversation using session ID, and explicitly differentiates from siblings by focusing on follow-ups and iterative refinement.

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 explicitly says to use for follow-up questions and multi-step workflows, providing clear context. It does not explicitly state when not to use, but the sibling names imply that.

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

claude_code_reportA

Generate a self-contained HTML report of a workflow run. No args: list all runs. run_id: detailed report for that run with agent sequence, cost breakdown, and collapsible transcripts. Save the returned HTML to a file and open in a browser.

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	No	Generate detailed report for this run. Omit to list all runs.
`include_transcripts`	No	Include full session transcripts in run reports (default: true, requires session persistence)

TDQS

A4.4/5.0

Behavior4/5

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

Discloses what the tool produces: HTML report, content of detailed report, cost breakdown, transcripts. Notes dependency for include_transcripts. No annotations exist, so description carries full burden; it does well without contradictions.

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?

Two concise sentences: one states purpose, second covers both parameter modes and output handling. No redundancy, perfectly front-loaded.

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?

No output schema, but description explains return value (HTML string) and what to do with it. Covers both parameter use cases sufficiently for a simple two-parameter tool.

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% (baseline 3). Description adds value by elaborating on report contents for run_id and explaining the default for include_transcripts.

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?

Clearly states it generates self-contained HTML reports of workflow runs. Distinguishes two modes: without run_id lists all runs; with run_id provides detailed report including agent sequence, cost breakdown, and collapsible transcripts. Distinct from sibling tools like claude_code_reply or claude_code_transcript.

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?

Explicitly describes when to use each parameter: omit run_id to list, provide it for detailed report. Mentions prerequisite for include_transcripts (session persistence). No explicit when-not-to-use, but the two modes are clearly differentiated.

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

claude_code_timelineA

Query the cross-agent workflow timeline. No args: list all runs. run_id: show one run's agent sequence. session_id: retrieve timeline entry and session metadata. Use claude_code_transcript for full transcripts.

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	No	Show all entries for this workflow run, ordered by time
`session_id`	No	Retrieve timeline entry and session metadata for a specific session

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided. Description does not explicitly state whether the tool is read-only, destructive, or any auth requirements. It implies read-only behavior by describing queries, but doesn't guarantee it.

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?

Two sentences that front-load the purpose and action, with no unnecessary words. Every part 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?

No output schema; description does not specify the format of returned data (e.g., fields in timeline entries). Lacks details on pagination, limits, or error handling, but sufficient for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. The description adds some context (e.g., 'agent sequence' for run_id) but does not significantly improve 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?

Description clearly states 'Query the cross-agent workflow timeline' which is a specific verb and resource. It distinguishes from sibling tools like claude_code_transcript which handles full transcripts.

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?

Provides explicit guidance on when to use each argument: 'No args: list all runs. run_id: show one run's agent sequence. session_id: retrieve timeline entry and session metadata.' Also directs to alternative tool: 'Use claude_code_transcript for full transcripts.'

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

claude_code_transcriptA

Retrieve the full conversation transcript for a session from Claude Code's storage. Returns chronological user/assistant messages. Use session_id from a prior query or timeline lookup.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes	Session ID to retrieve transcript for
`limit`	No	Maximum number of messages to return
`offset`	No	Skip this many messages from the start
`include_system`	No	Include system messages (default: false)

TDQS

A4/5.0

Behavior3/5

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

With no annotations, description carries the full burden. It discloses that the tool returns chronological user/assistant messages (a read operation) but does not mention authentication requirements, rate limits, or error handling for invalid session_ids.

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?

Extremely concise: two sentences, front-loaded with the primary purpose, no redundant words. Every sentence adds essential context.

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?

Provides sufficient context for a transcript retrieval tool: what it returns and how to get session_id. Lacks mention of pagination behavior or error handling, but given the schema parameters, it is mostly complete.

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?

Input schema has 100% description coverage, with each parameter clearly described (e.g., session_id, limit, offset, include_system). The description adds no new semantic information beyond the schema, meeting the baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'retrieve' and the resource 'full conversation transcript', specifying it returns chronological user/assistant messages. It is distinct from siblings like 'claude_code_reply' and 'claude_code_timeline'.

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?

Explicitly advises using session_id from a prior query or timeline lookup, providing clear context for when to use this tool. However, it does not mention when not to use it or alternative tools beyond the implicit distinction.

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. Dates show when Glama detected each change.

5 tool updatesv1.1.10Apr 28, 2026
- First observedclaude_code
- First observedclaude_code_reply
- First observedclaude_code_report
- First observedclaude_code_timeline
- First observedclaude_code_transcript

Install Server

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

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct aspect of Claude Code interaction: initiation, continuation, report generation, timeline querying, and transcript retrieval. No two tools have overlapping purposes or ambiguous boundaries.

Naming Consistency5/5

All tools follow a consistent claude_code_<noun> pattern (except claude_code itself, which is the base action). The naming is predictable and descriptive, aiding quick identification of each tool's role.

Tool Count5/5

With 5 tools, the set is tightly scoped to the domain of managing Claude Code sessions. Each tool contributes a necessary function without redundancy, and the count is appropriate for the server's focused purpose.

Completeness4/5

The tools cover the core workflow: initiating, continuing, reporting, and reviewing sessions. A minor gap is the lack of a cancel/stop tool, but for most use cases the set is complete.

Maintenance

ActivityMaintained

ResponsivenessSlow

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
RogerRat A
io.github.opcastil11
Real-time chat hub for AI agents — Claude Code, Cursor, Cline, Codex over MCP or REST.
Communication Agent Orchestration
21
try B
md.install
Create guides as MCP servers to instruct coding agents to use your software (library, API, etc).
Documentation Access Developer Tools Coding Agents
132
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128

Related MCP Servers

openai-agents-mcp
AI & Machine Learning Agent Orchestration
merlinrabens
A
license
A
quality
D
maintenance
MCP server that bridges OpenAI's Agents SDK with Claude Code, enabling web search, file search, and computer use capabilities directly in your development environment.
Updated a year ago (2025-08-22 11:32 UTC)
2
9
1
MIT
claude-agent-mcp
AI & Machine Learning Coding Agents Agent Orchestration
j-token
A
license
Not graded
quality
D
maintenance
An MCP server that wraps the Claude Agent SDK, enabling Claude-powered queries, coding tasks, web search, and customizable agent execution using OAuth without an API key.
Updated 5 months ago (2026-03-26 16:42 UTC)
21
MIT
Clanker
Coding Agents Code Execution Autonomous Agents
kckylechen1
A
license
A
quality
F
maintenance
MCP server for running external coding agents as background tasks inside Claude Code. Supports multiple backends including Codex, Grok, GLM, DeepSeek, and more.
Updated 2 months ago (2026-07-09 13:59 UTC)
7
MIT
Agent Fleet MCP Server
Agent Orchestration Autonomous Agents Code Execution
Magic-Man-us
A
license
A
quality
A
maintenance
MCP server that exposes a pool of Claude SDK agents as tools, enabling deterministic agent creation, retrieval, and resumption from a capability corpus.
Updated 22 days ago (2026-08-15 16:33 UTC)
10
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xiaolai/claude-octopus'

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

Claude Octopus

Why

Prerequisites

Install

npm (most direct)

npx (no install needed)

MCP Registry

Quick Start

Multiple Agents

Multi-Agent Orchestration

Agent Factory

Init Wizard

Skip the menu

Templates

Dashboard

Tools

Query and reply parameters

Timeline

How it works

Querying the timeline

Multi-agent workflow example

HTML Reports

Via MCP tool

Via CLI

What's in the report

Reading the effort counters

Configuration

Identity

Agent

Prompts

Advanced

Timeline

Authentication

Security

Architecture

How It Compares

Development

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API