claude-code-mcp
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@claude-code-mcprefactor the main function in src/index.ts to use async/await"
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.
claude-code-mcp
MCP server that wraps Claude Code (Claude Agent SDK) as tools, enabling any MCP client to invoke Claude Code for autonomous coding tasks. Designed for local use — the MCP server and client are expected to run on the same machine. It works especially well with OpenCode/Codex-style clients that prefer async polling and explicit permission decisions.
Inspired by the Codex MCP design philosophy — minimum tools, maximum capability.
This package is CLI-first: it is intended to run as an MCP server process (npx @leo000001/claude-code-mcp), not as a stable programmatic library API.
Visibility Boundary
Not every piece of documentation below is visible to an MCP-connected coding agent.
Usually visible to the agent: MCP tool names, tool descriptions, input field descriptions, and MCP resources that the client explicitly reads.
Not safe to assume visible: this
README.md,docs/DESIGN.md,AGENTS.md, and other repository files unless the client or orchestrator copies that content into the model context.Authoring rule: keep protocol-critical calling rules in tool descriptions and MCP resources first; mirror them in README for humans, but do not rely on README alone.
In practice, the most important runtime rules are duplicated in the claude_code* tool descriptions and the quickstart / gotchas / compat-report resources so async polling clients can succeed even when they never read this file.
Related MCP server: claude-cli-mcp
Features
4 tools covering the full agent lifecycle: start, continue, check/poll, manage
Read-only MCP resources for server info, internal tool catalog, and compatibility diagnostics
Session management with resume and fork support
Local settings loaded by default — automatically reads
~/.claude/settings.json,.claude/settings.json,.claude/settings.local.json, andCLAUDE.mdso the agent behaves like your local Claude Code CLIAsync permissions — allow/deny lists + explicit approvals via
claude_code_checkCustom subagents — define specialized agents per session
Cost tracking — per-session turn and cost accounting
Session cancellation via AbortController
Auto-cleanup — 30-minute idle timeout for expired sessions
Security — callers control tool permissions via allow/deny lists + explicit permission decisions
See CHANGELOG.md for release history.
Prerequisites
Node.js >= 18 is required.
Same-platform deployment — this MCP server is designed to run on the same machine as the MCP client. It communicates via stdio (child process), reads local Claude configuration files from
~/.claude/, and accesses the local file system directly. Remote deployment is not supported.
This MCP server uses the @anthropic-ai/claude-agent-sdk package, which bundles its own Claude Code CLI (cli.js). When no explicit pathToClaudeCodeExecutable is provided, this server now prefers a detected local claude command, then claude-internal, and falls back to the SDK-bundled CLI if neither is found.
The SDK bundles a Claude Code CLI; its version generally tracks the SDK package version, but the exact scheme is not guaranteed
Default executable resolution order is: request-level
pathToClaudeCodeExecutable->CLAUDE_CODE_MCP_DEFAULT_CLAUDE_PATH->CLAUDE_CODE_MCP_DEFAULT_CLAUDE_COMMAND-> auto-detectedclaude-> auto-detectedclaude-internal-> SDK-bundled CLIConfiguration is shared — the bundled CLI reads API keys and settings from
~/.claude/, same as the system-installedclaudeAll local settings are loaded by default — unlike the raw SDK (which defaults to isolation mode), this MCP server loads
user,project, andlocalsettings automatically, includingCLAUDE.mdproject context. Passadvanced.settingSources: []to opt outYou must have Claude Code configured (API key set up) before using this MCP server: see Claude Code documentation
Note: The bundled CLI version may differ from your system-installed
claude. To check:claude --version(system) vsnpm ls @anthropic-ai/claude-agent-sdk(SDK).
Quick Start
As an MCP server (recommended)
Install globally or use npx (no install needed):
npm install -g @leo000001/claude-code-mcpAdd to your MCP client configuration (Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"claude-code": {
"command": "npx",
"args": ["-y", "@leo000001/claude-code-mcp"]
}
}
}Some clients cache tool/resource metadata at connect-time. This server emits
notifications/tools/list_changedandnotifications/resources/list_changedafter runtime tool discovery so clients can refresh both theclaude_codetool description andinternal-toolsresource.
Anthropic Claude Code CLI (as an MCP client)
claude mcp add --transport stdio claude-code -- npx -y @leo000001/claude-code-mcpOpenCode
Add a local MCP entry in opencode.json / opencode.jsonc (project) or the global OpenCode config under ~/.config/opencode/:
{
"mcp": {
"claude-code": {
"type": "local",
"command": ["npx", "-y", "@leo000001/claude-code-mcp"],
"enabled": true
}
}
}OpenCode tip: start with claude_code, keep the returned sessionId, then background-poll with claude_code_check. When approvals appear, decision: "allow_for_session" is usually the best UX because it reduces repeated prompts for the same tool in a session.
OpenCode project configs can launch local commands. Only enable repository-level MCP configs in repos you trust.
OpenAI Codex CLI
codex mcp add claude-code -- npx -y @leo000001/claude-code-mcpOr manually add to ~/.codex/config.toml:
[mcp_servers.claude-code-mcp]
command = "npx"
args = ["-y", "@leo000001/claude-code-mcp"]Codex supports both user-level (~/.codex/config.toml) and project-level (.codex/config.toml) configuration. See Codex config reference for advanced options like tool_timeout_sec and enabled_tools.
From source
git clone https://github.com/xihuai18/claude-code-mcp.git
cd claude-code-mcp
npm install
npm run build
npm startTools
claude_code — Start a new session
Start a new Claude Code session. The agent autonomously performs coding tasks: reading/writing files, running shell commands, searching code, managing git, and interacting with APIs.
Important protocol note: this call starts background work and returns quickly with sessionId; it does not return the final result. Callers must poll claude_code_check(action="poll"), persist nextCursor, and use claude_code_reply to continue the same session later.
Parameter | Type | Required | Description |
| string | Yes | Task or question for Claude Code |
| string | No | Working directory (defaults to server cwd) |
| string[] | No | Auto-approved tool names. Default: |
| boolean | No | Server-side strict allowlist toggle. When |
| string[] | No | Forbidden tool names. Default: |
| number | No | Maximum number of agent reasoning steps. Each step may involve one or more tool calls. Default: SDK/Claude Code default |
| string | No | Model to use (e.g. |
| string | No | Effort string: |
| object | No | Thinking config object, not a string: |
| string | object | No | Override the agent's system prompt. Default: SDK/Claude Code default. Pass a string for full replacement, or |
| number | No | Timeout in milliseconds waiting for permission decisions, auto-deny on expiry. Default: |
| object | No | Advanced/low-frequency parameters (see below) |
Parameter | Type | Description |
| string[] | object | Visible built-in tool set. Array of exact tool names, |
| boolean | Persist session history to disk ( |
| number | Session init timeout in milliseconds waiting for |
| object | Define custom sub-agents the main agent can delegate tasks to. Default: none. SDK default: if a sub-agent omits |
| string | Name of a custom agent (defined in |
| number | Maximum budget in USD. Default: SDK/Claude Code default |
| string[] | Beta features (e.g. |
| string[] | Additional directories the agent can access beyond cwd. Default: none |
| object | Structured output config: |
| string | Path to the Claude Code executable. Default: auto-detect |
| object | MCP server configurations keyed by server name. Default: none |
| object | Sandbox behavior config object. This controls sandbox behavior, not the actual Read/Edit/WebFetch permission rules. Default: SDK/Claude Code default |
| string | Fallback model if the primary model fails or is unavailable. Default: none |
| boolean | Enable file checkpointing to track file changes during the session. Default: |
| object | Per-tool built-in configuration. Example: |
| boolean | When true, includes intermediate streaming messages in the response. Useful for real-time progress monitoring. Default: false |
| boolean | When true, emits post-turn prompt suggestion events ( |
| boolean | When true, emits AI-generated summaries on |
| boolean | Enforce strict validation of MCP server configurations. Default: |
| string | object | Extra Claude Code flag settings. Pass either a path to a settings JSON file or an inline settings object. These load at the highest-priority flag-settings layer. Default: none |
| string[] | Which filesystem settings to load. Defaults to |
| boolean | Enable debug mode for verbose logging. Default: |
| string | Write debug logs to a specific file path (implicitly enables debug mode). Default: omitted |
| object | Environment variables merged over |
Returns: { sessionId, status: "running", pollInterval, resumeToken? }
Notes:
resumeTokenis omitted by default, and is only returned whenCLAUDE_CODE_MCP_RESUME_SECRETis set on the server.On error:
{ sessionId: "", status: "error", error }modelis optional. If omitted, Claude Code chooses the effective model from its own defaults/settings; inspect session/result metadata if you need to know what actually ran.If you plan to continue with
claude_code_reply, keep the session persistent (advanced.persistSession=true, which is already the default).
Use claude_code_check to poll events and obtain the final result.
Notes:
Subagents require the
Tasktool to be available to the primary agent. If you useallowedTools, include"Task"or the agent will be unable to invoke subagents.If you configure
advanced.mcpServersand want the agent to auto-use tools from those servers without approvals, include the exact tool names inallowedTools(e.g.["mcp__my_server__tools/list"]). Otherwise you will see permission requests viaclaude_code_check.
advanced.includePartialMessagesaffects the underlying SDK event stream; intermediate messages are captured as events and returned viaclaude_code_check(theclaude_codecall itself does not stream).
Security: Configure permissions based on your own scope. Callers (MCP clients / orchestrating agents) MUST set
allowedToolsanddisallowedToolsaccording to their own permission boundaries. Only pre-approve tools that you yourself are authorized to perform — do not grant the agent broader permissions than you have. For example, if you lack write access to a directory, do not includeWrite/EditinallowedTools. When in doubt, leave both lists empty and review each permission request individually viaclaude_code_check.
claude_code_reply — Continue a session
Continue an existing session by sending a follow-up message. The agent retains full context from previous turns including files read, code analysis, and conversation history.
Important protocol note: prefer claude_code_reply over starting a fresh claude_code session when you want to continue the same work. This requires a persistent in-memory session, or diskResumeConfig when disk resume fallback is enabled.
Parameter | Type | Required | Description |
| string | Yes | Session ID from a previous |
| string | Yes | Follow-up prompt |
| boolean | No | Create a branched copy of this session. Default: |
| string | No | Effort string override for this run (and for future replies when not forking): |
| object | No | Thinking config object override for this run (and for future replies when not forking): |
| number | No | Timeout in milliseconds waiting for permission decisions, auto-deny on expiry. Default: |
| number | No | Fork init timeout in milliseconds (only when |
| object | No | Disk resume parameters (see below). Used when |
Parameter | Type | Description |
| string | Resume token returned by |
| string | Working directory. Required for disk resume. |
| string[] | Auto-approved tool names (see |
| string[] | Forbidden tool names (see |
| boolean | Server-side strict allow-list behavior for |
| string[] | object | Base tool set (see |
| boolean | Persist session history to disk. Default: |
| number | Maximum number of agent reasoning steps. Default: SDK/Claude Code default |
| string | Model to use. Default: SDK/Claude Code default |
| string | object | Override the agent's system prompt. Default: SDK/Claude Code default |
| object | Custom sub-agent definitions (see |
| string | Primary agent name (see |
| number | Maximum budget in USD. Default: SDK/Claude Code default |
| string | Effort level. Default: SDK/Claude Code default |
| string[] | Beta features. Default: none |
| string[] | Additional directories. Default: none |
| object | Structured output config. Default: omitted (plain text) |
| object | Thinking config object: |
| string | Resume only up to and including a specific message UUID. Default: omitted |
| string | Path to Claude Code executable. Default: auto-detect |
| object | MCP server configurations keyed by server name. Default: none |
| object | Sandbox behavior config object. Default: SDK/Claude Code default |
| string | Fallback model. Default: none |
| boolean | Enable file checkpointing. Default: |
| object | Per-tool built-in configuration. Default: none |
| boolean | Include intermediate streaming messages. Default: |
| boolean | Emit post-turn prompt suggestion events ( |
| boolean | Emit AI-generated subagent progress summaries. Default: |
| boolean | Strict MCP config validation. Default: |
| string | object | Extra Claude Code flag settings (path or inline object), loaded at the highest-priority flag-settings layer. Default: none |
| string[] | Which filesystem settings to load. Default: |
| boolean | Debug mode. Default: |
| string | Debug log file path (implicitly enables debug). Default: omitted |
| object | Environment variables merged over |
Returns: { sessionId, status: "running", pollInterval, resumeToken? }
Notes:
resumeTokenis omitted by default, and is only returned whenCLAUDE_CODE_MCP_RESUME_SECRETis set on the server.On error:
{ sessionId, status: "error", error }
Use claude_code_check to poll events and obtain the final result.
Gotchas:
Permission approvals have a timeout (default 60s via
permissionRequestTimeoutMs) and will auto-deny; watchactions[].expiresAt/actions[].remainingMs.claude_code_replyrequires a persistent session or an enabled disk-resume setup; one-shot/non-persistent sessions cannot be resumed later.Readhas a per-call size cap in practice (often ~256KB); for large files useoffset/limitor chunk withGrep.Editwithreplace_all=trueis substring replacement; if no match is found the tool returns a clear error.On Windows, this server normalizes common MSYS-style paths (e.g.
/d/...,/mnt/c/...,/cygdrive/c/...,//server/share/...) forcwd,additionalDirectories, and tool inputs that includefile_path.On Windows, POSIX home paths like
/home/user/...are not rewritten to drive paths; prefer absolute Windows paths under your currentcwdto avoid out-of-bounds permission prompts.On Windows, Claude Code itself needs Git Bash; set
CLAUDE_CODE_GIT_BASH_PATHin your MCP client config if auto-detection is unreliable.TeamDeletemay require members to reachshutdown_approved(otherwise you may see "active member" errors); cleanup can be asynchronous during shutdown.Skills may become available later in the same session (early calls may show "Unknown", later succeed after skills are loaded/registered).
toolCatalogCountandavailableToolsare different views: catalog is server-known tools, whileavailableToolscomes from each session's runtimesystem/init.tools.Some internal features (e.g. ToolSearch) may not appear in
availableTools(derived from SDKsystem/init.tools).
Resources
If your MCP client supports resources, this server exposes a couple of read-only MCP resources:
claude-code-mcp:///server-info(JSON): server metadata (version/platform/runtime + capabilities/limits)claude-code-mcp:///internal-tools(JSON): internal tool catalog (runtime-aware, includes permission/schema metadata)claude-code-mcp:///gotchas(Markdown): practical limits/gotchasclaude-code-mcp:///quickstart(Markdown): minimal async start/poll/respond flowclaude-code-mcp:///errors(JSON): structured error-code catalog and remediation hintsclaude-code-mcp:///compat-report(JSON): compatibility report (transport/platform assumptions, runtime warnings, guidance, recommended settings, tool count diagnostics)
Resource templates:
claude-code-mcp:///session/{sessionId}: lightweight session snapshot for a specific sessionclaude-code-mcp:///tools/runtime{?sessionId}: runtime tool view globally or per sessionclaude-code-mcp:///compat/diff{?client}: client-specific compatibility guidance
Disk resume (optional): By default, claude_code_reply requires the session to exist in the MCP server's in-memory Session Manager. If you set CLAUDE_CODE_MCP_ALLOW_DISK_RESUME=1, it can attempt to resume using the Claude Code CLI's on-disk transcript even when the in-memory session is missing (e.g. after a restart / TTL cleanup). For safety, disk resume fallback requires CLAUDE_CODE_MCP_RESUME_SECRET to be set on the server and requires callers to pass diskResumeConfig.resumeToken (returned by claude_code / claude_code_reply when CLAUDE_CODE_MCP_RESUME_SECRET is set).
claude_code_session — Manage sessions
List, inspect, cancel, or interrupt sessions.
Parameter | Type | Required | Description |
| string | Yes |
|
| string | For get/cancel/interrupt | Target session ID |
| boolean | No | Include |
Returns: { sessions, message?, isError? }
sessions[] now includes lightweight diagnostics fields: pendingPermissionCount, eventCount, currentCursor, lastEventId, ttlMs, lastError?, lastErrorAt?, fastModeState?, and redactions[].
claude_code_check — Poll events and respond to permission requests
Poll session events/results and approve/deny pending permission requests.
Important protocol note: action="poll" is the main loop, and action="respond_permission" is the only interactive approval flow on this backend. respond_user_input is not supported.
Parameter | Type | Required | Description |
| string | Yes |
|
| string | Yes | Target session ID |
| number | No | Event cursor for incremental polling ( |
| string | No |
|
| number | No | Max events per poll (pagination via |
| string | For respond_permission | Permission request ID |
| string | For respond_permission |
|
| string | No | Deny reason shown to Claude ( |
| boolean | No | When true, denying also interrupts the whole agent ( |
| object | No | Fine-grained poll control options (see below) |
| object | No | Advanced permission response options (see below) |
Parameter | Type | Description |
| boolean | When true, includes |
| boolean | When false, omits |
| boolean | When false, omits |
| boolean | When false, omits top-level |
| boolean | Include |
| boolean | Include |
| boolean | Include |
| boolean | When true, keeps terminal |
| boolean | When true, includes noisy SDK progress subtypes (e.g. |
| number | Approximate max JSON bytes for |
Parameter | Type | Description |
| object | Modified tool input to run ( |
| array | Permission rule updates suggested/applied ( |
Returns (poll and respond_permission): { sessionId, status, pollInterval?, cursorResetTo?, truncated?, truncatedFields?, events, nextCursor?, availableTools?, toolValidation?, compatWarnings?, actions?, result?, cancelledAt?, cancelledReason?, cancelledSource?, lastEventId?, lastToolUseId? }
Notes:
On error (e.g. invalid arguments, missing/expired session):
{ sessionId, isError: true, error }respond_user_inputis not supported on this backend. Userespond_permissionfor interactive approvals.Always treat
cursoras an incremental position: storenextCursorand pass it back on the next poll to avoid replaying old events.If
cursorResetTois present, yourcursorwas too old (events were evicted); reset your cursor tocursorResetTo.For safety, de-duplicate events by
event.idon the client side.If
truncated=true, the server intentionally limited the payload (e.g.maxEvents) — continue polling withnextCursor.nextCursorcan remain unchanged withevents=[]during quiet intervals; this is normal transient behavior. Retry a few times (for example up to 3) before treating it as abnormal.toolValidationreports whether configuredallowedTools/disallowedToolsmatch runtime-discovered tool names.compatWarningssurfaces compatibility hints (for example, unresolved tool names or path/platform mismatch signals) and is non-blocking; treat it as advisory unless the session actually fails.Permission
actions[]includetimeoutMs,expiresAt, and best-effortremainingMsto help callers avoid auto-deny timeouts.Permission
actions[]may also include SDK-providedtitle/displayNamemetadata; clients should prefer those strings when rendering approval UI.For
decision="allow_for_session", the server now prefers SDK-providedsuggestions(for exampleaddDirectories) when present, then falls back to a generic per-session tool allow rule.permission_resultevent data is{ requestId, toolName, behavior, source, message?, interrupt? }(denial details only present fordeny).result.fastModeStatemay be present when the SDK reports fast-mode state, andclaude_code_sessionsurfaces the latest knownfastModeStatefor each session.In
"minimal"mode (default): assistant message events are slimmed (stripsusage,model,id,cache_controlfrom content blocks); noisy SDK progress subtypes (tool_progress,auth_status,system/api_retry,system/task_progress,system/hook_progress) are filtered out;lastEventId/lastToolUseIdare omitted;AgentResultomitsdurationApiMs/sessionTotalTurns/sessionTotalCostUsd. UseresponseMode: "full"or individualinclude*flags to restore any of these.In
"delta_compact"mode: defaults minimize per-poll payload size (eventsand top-levelresultomitted unless explicitly enabled viapollOptions), while still returning session status/actions/cursors. Note: this does not change the recommended poll interval —runningsessions should still be polled at >=2 minute intervals.
Usage Example
# 1) Start a new session (async start)
start = await mcp.call_tool("claude_code", {
"prompt": "Fix the authentication bug in src/auth.ts",
"cwd": "/path/to/project",
"allowedTools": ["Read", "Edit", "Bash", "Glob", "Grep"],
"effort": "high",
"advanced": {
"maxBudgetUsd": 5.0
}
})
session_id = json.loads(start)["sessionId"]
cursor = 0
# 2) Poll until idle/error/cancelled
while True:
polled = await mcp.call_tool("claude_code_check", {
"action": "poll",
"sessionId": session_id,
"cursor": cursor,
"pollOptions": {
"includeProgressEvents": True
}
})
data = json.loads(polled)
cursor = data.get("nextCursor", cursor)
# If permission is needed, approve/deny via respond_permission
for action in data.get("actions", []) or []:
if action.get("type") == "permission":
await mcp.call_tool("claude_code_check", {
"action": "respond_permission",
"sessionId": session_id,
"requestId": action["requestId"],
"decision": "allow"
})
# Final result is available when status becomes idle/error
if data.get("status") in ["idle", "error", "cancelled"]:
final_result = data.get("result")
break
# 3) Manage sessions (list/get/cancel/interrupt)
result = await mcp.call_tool("claude_code_session", {"action": "list"})Windows Support
The Claude Code CLI bundled in the SDK requires Git for Windows (which includes bash.exe). If you run this MCP server on Windows and see:
Claude Code on Windows requires git-bash (https://git-scm.com/downloads/win).This means the spawned CLI process cannot locate bash.exe. Your locally installed claude command may work fine — the issue is that the MCP server's child process may not inherit your shell environment.
claude-code-mcp will try to auto-detect Git Bash from common install locations and set CLAUDE_CODE_GIT_BASH_PATH for child processes. If you still see this error, set CLAUDE_CODE_GIT_BASH_PATH explicitly in your MCP server config:
For JSON-based MCP clients (Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"claude-code": {
"command": "npx",
"args": ["-y", "@leo000001/claude-code-mcp"],
"env": {
"CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
}
}
}
}For OpenCode (opencode.json / opencode.jsonc):
{
"mcp": {
"claude-code": {
"type": "local",
"command": ["npx", "-y", "@leo000001/claude-code-mcp"],
"enabled": true,
"environment": {
"CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
}
}
}
}For OpenAI Codex CLI (~/.codex/config.toml):
[mcp_servers.claude-code-mcp]
command = "npx"
args = ["-y", "@leo000001/claude-code-mcp"]
[mcp_servers.claude-code-mcp.env]
CLAUDE_CODE_GIT_BASH_PATH = "C:\\Program Files\\Git\\bin\\bash.exe"Replace the path with your actual
bash.exelocation. Common paths:
C:\Program Files\Git\bin\bash.exe(default installer)To find yours:
where gitin CMD/PowerShell, then look forbash.exeunder the same Git root'sbin\folder.
Alternatively, set the environment variable system-wide so all processes inherit it:
# PowerShell (permanent, requires new terminal)
setx CLAUDE_CODE_GIT_BASH_PATH "C:\Program Files\Git\bin\bash.exe"Security
Async permission approvals — when a tool call needs approval, the session transitions to
waiting_permissionand surfaces requests viaclaude_code_check(actions[]).No runtime privilege escalation tool — permission decisions are per-session (allow/deny lists + explicit approvals), and the server does not expose a
claude_code_configurebypass switch.Environment variables are inherited — the spawned Claude Code process inherits all environment variables (including
ANTHROPIC_API_KEY) from the parent process by default. Theadvanced.envparameter merges withprocess.env(user-provided values take precedence), so you can safely add or override individual variables without losing existing ones.Permission policy is enforced in two places —
allowedTools/disallowedToolsare passed to the SDK and also guarded incanUseToolas a defensive consistency check (for example,blockedPathcan still trigger an approval flow).Tool visibility vs approvals:
Use
advanced.toolsto restrict which tools the agent can see (hidden tools cannot be called).Use
allowedToolsto auto-approve specific tools without prompting (the SDK may still prompt for path-based restrictions likeblockedPath).Use
disallowedToolsto hard-block tools; they are denied even if later approved viaclaude_code_check.
maxTurnsandadvanced.maxBudgetUsdprevent runaway execution.Sessions auto-expire after 30 minutes of inactivity.
Vulnerability reporting: see
SECURITY.md.
Environment Variables
All environment variables are optional. They are set on the MCP server process (not on the Claude Code child process — for that, use the env tool parameter).
Variable | Description | Default |
| Path to | Auto-detected |
| Exact command name to resolve from | (unset) |
| Explicit filesystem path to use as the default Claude executable. Mutually exclusive with | (unset) |
| Set to |
|
| HMAC secret used to validate | (unset) |
| Maximum number of in-memory sessions (set |
|
| Maximum number of outstanding permission requests per session (set |
|
| Soft limit for in-memory event buffer per session ( |
|
| Hard limit for in-memory event buffer per session (clamped to be |
|
Choosing the default Claude executable
CLAUDE_CODE_MCP_DEFAULT_CLAUDE_PATHandCLAUDE_CODE_MCP_DEFAULT_CLAUDE_COMMANDare mutually exclusive.If neither is set, the server auto-detects
claude, thenclaude-internal, then falls back to the SDK-bundled CLI.Request-level
pathToClaudeCodeExecutablestill overrides these server defaults.Invalid values for these env vars are treated as startup misconfiguration and will fail the server fast.
How to configure
JSON-based MCP clients (Claude Desktop, Cursor, etc.) — add an "env" block:
{
"mcpServers": {
"claude-code": {
"command": "npx",
"args": ["-y", "@leo000001/claude-code-mcp"],
"env": {
"CLAUDE_CODE_MCP_ALLOW_DISK_RESUME": "1",
"CLAUDE_CODE_MCP_RESUME_SECRET": "change-me"
}
}
}
}OpenAI Codex CLI — add an [mcp_servers.claude-code-mcp.env] section in ~/.codex/config.toml:
[mcp_servers.claude-code-mcp]
command = "npx"
args = ["-y", "@leo000001/claude-code-mcp"]
[mcp_servers.claude-code-mcp.env]
CLAUDE_CODE_MCP_ALLOW_DISK_RESUME = "1"
CLAUDE_CODE_MCP_RESUME_SECRET = "change-me"OpenCode — add an environment block under the local MCP entry:
{
"mcp": {
"claude-code": {
"type": "local",
"command": ["npx", "-y", "@leo000001/claude-code-mcp"],
"enabled": true,
"environment": {
"CLAUDE_CODE_MCP_ALLOW_DISK_RESUME": "1",
"CLAUDE_CODE_MCP_RESUME_SECRET": "change-me"
}
}
}
}System-wide — set via your shell profile or OS settings so all processes inherit them:
# bash / zsh
export CLAUDE_CODE_MCP_ALLOW_DISK_RESUME=1
export CLAUDE_CODE_MCP_RESUME_SECRET=change-me
# PowerShell (permanent, requires new terminal)
setx CLAUDE_CODE_MCP_ALLOW_DISK_RESUME 1
setx CLAUDE_CODE_MCP_RESUME_SECRET change-meDevelopment
npm install # Install dependencies
npm run build # Build with tsup
npm run typecheck # Type check with tsc
npm test # Run tests with vitest
npm run dev # Watch mode buildE2E regression commands
# Run cancel->poll regression loop (single mode)
npm run e2e:stdio:cancel
# Run waiting_permission + cancel regression loop
npm run e2e:stdio:cancel:wp
# Run both modes and output one summary report
npm run e2e:stdio:runnerE2E notes (Codex and other clients)
Some clients do not expose
tools/listdirectly in the chat loop. In those clients, treat "tool is callable" as the primary discovery signal, and usetools/listonly when available.allowedTools: ["Read", "Write"]does not guarantee the model will never attemptBash. For deterministic smoke tests, adddisallowedTools: ["Bash"]and state "do not use Bash" in the prompt.For
claude_code_session(action="get", includeSensitive=true), only assert fields that were actually configured. Optional fields that were never set may be omitted.If a client reports
Transport closedduring E2E cleanup, reconnect the MCP server first, then runclaude_code_session(action="list")and cancel any remainingrunning/waiting_permissionsessions.
For an end-to-end local test plan (third-party CLI/client integration + real coding tasks), see docs/E2E_LOCAL_TEST_PLAN.md.
Architecture
MCP Client ←→ (stdio/JSON-RPC) ←→ MCP Server [same machine]
├── Session Manager (Map<id, state>)
└── Claude Agent SDK (query())Session persistence: The MCP server's Session Manager holds in-memory session metadata, a snapshot of session options (tool config, limits, cwd, allow/deny lists, etc.), and an event buffer used by claude_code_check. This metadata is not persisted to disk by the MCP server. The actual conversation history is persisted to disk by the Claude Code CLI (under ~/.claude/projects/) — this is managed by the SDK, not by this MCP server. By default, if the MCP server restarts or the session expires from memory, claude_code_reply will return SESSION_NOT_FOUND even though the CLI transcript may still exist on disk. You can opt into disk-resume behavior by setting CLAUDE_CODE_MCP_ALLOW_DISK_RESUME=1.
Sessions are automatically cleaned up after 30 minutes of idle time, or after 4 hours of continuous running (timed-out running sessions transition to cancelled).
Turn/Cost semantics: numTurns and totalCostUsd are per-call increments. For cumulative per-session totals, use sessionTotalTurns and sessionTotalCostUsd. When forkSession=true, the returned sessionId (and sessionTotal*) refer to the forked session; the original session totals are preserved.
Error Codes
MCP server validation/policy errors are returned as Error [CODE]: message where CODE is one of:
INVALID_ARGUMENT— invalid inputs (e.g. missing sessionId, empty cwd)SESSION_NOT_FOUND— session not found in memory (expired or server restarted)SESSION_BUSY— session currently runningPERMISSION_DENIED— operation not allowed by server policyPERMISSION_REQUEST_NOT_FOUND— permission request ID not found (already finished or expired)RESOURCE_EXHAUSTED— resource limit reached (e.g. max sessions or max pending permissions)TIMEOUT— operation timed outCANCELLED— session was cancelledINTERNAL— unexpected error or protocol mismatch
For Claude Agent SDK execution failures, also check errorSubtype (e.g. error_max_turns, error_max_budget_usd, error_during_execution) and the returned result text.
License
MIT — see LICENSE
Contributing
See CONTRIBUTING.md for development setup and guidelines.
Available Tools
4 toolsclaude_codeADestructive
Start a background Claude Code run and return sessionId immediately. No final result is returned here. Main loop: call claude_code_check(action='poll'), store nextCursor, and keep polling until status becomes idle, error, or cancelled. If actions[] contains permission requests, answer them with claude_code_check(action='respond_permission'). respond_user_input is not supported. Adjust polling cadence to progress: poll faster while new events/actions are arriving, and slower when the session is quietly thinking. Long-running work is normal: Claude Code can keep working for 10+ minutes, especially with high/max effort, so wait for polling to settle before assuming it is stuck. If you want to continue after a run pauses or finishes, use claude_code_reply with the same sessionId instead of starting a new claude_code session. For runtime-authoritative tool names, call claude_code_check with pollOptions.includeTools=true.
Internal tools (runtime list when includeTools=true):
[agent]
Task: Spawn subagent (must be in allowedTools)
TaskOutput: Get subagent output
TaskStop: Cancel subagent
TeamDelete: Delete team (may need shutdown_approved first)
TodoWrite: Task/todo checklist
[execute]
Bash: Run shell commands
[file_read]
Glob: Find files by glob pattern
Grep: Search file contents (regex)
Read: Read file contents (large files: use offset/limit or Grep)
[file_write]
Edit: Targeted edits (replace_all is substring-based)
NotebookEdit: Edit Jupyter notebook cells (Windows paths normalized)
Write: Create or overwrite files
[interaction]
AskUserQuestion: Ask user a question
[mcp]
SubscribeMcpResource: Subscribe to an MCP resource stream
SubscribePolling: Subscribe to periodic polling
UnsubscribeMcpResource: Unsubscribe from an MCP resource stream
UnsubscribePolling: Unsubscribe from periodic polling
[network]
WebFetch: Fetch web page or API content
WebSearch: Web search
Permission control: allowedTools pre-approves tools but is not a strict allowlist unless strictAllowedTools=true; disallowedTools always denies; other tools may require approval.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working dir. Default: server cwd | |
| model | No | Default: SDK | |
| effort | No | Effort string: 'low' | 'medium' | 'high' | 'max'. Default: SDK | |
| prompt | Yes | Prompt for a new background run. The final result arrives later via claude_code_check, not this call. Store nextCursor from polls and reuse sessionId with claude_code_reply if you want to continue later. | |
| advanced | No | Default: none | |
| maxTurns | No | Default: SDK | |
| thinking | No | Thinking config object, not a string. Use {type:'adaptive'} | {type:'enabled', budgetTokens?:N} | {type:'disabled'}. Default: SDK | |
| allowedTools | No | Pre-approved tool names. Default: []. This is not a strict allowlist unless strictAllowedTools=true. | |
| systemPrompt | No | System prompt config: string, {type:'preset',preset:'claude_code'}, or {type:'preset',preset:'claude_code',append:'...'}. Default: SDK | |
| disallowedTools | No | Always-denied tool names. Default: [] | |
| strictAllowedTools | No | Default: false. When true, tools outside allowedTools are denied. | |
| permissionRequestTimeoutMs | No | Server permission wait timeout in ms; not forwarded to SDK Options. Default: 60000, clamped to 300000 |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| status | Yes | |
| sessionId | Yes | |
| resumeToken | No | |
| pollInterval | No | |
| compatWarnings | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, openWorldHint=true), the description adds critical behavioral context: the tool starts a background process, explains the long-running nature (10+ minutes), details the polling loop, permission handling, and internal tool behavior. It also clarifies that allowedTools is not a strict allowlist unless strictAllowedTools is true, providing transparency on permission control.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for the complexity, front-loading the core purpose and polling loop. It then covers permissions, continuation, and internal tool lists in a structured manner. While long, every section adds value; could be slightly more concise but earns a 4 for effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (asynchronous polling, permissions, internal tools) and the presence of a detailed schema and output schema, the description is complete. It covers the main loop, permission handling, session management, runtime tool discovery, and permission control nuances, leaving no significant gaps 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.
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 minimal parameter insight beyond the schema: it reiterates that prompt starts a run and mentions storing nextCursor from polls, but does not elaborate on other parameters. The description focuses on the workflow rather than individual parameter details, which is acceptable given the schema's thoroughness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool starts a background Claude Code run and returns a sessionId immediately, with no final result returned here. It distinguishes itself from sibling tools (claude_code_check, claude_code_reply, claude_code_session) by explaining when to use each and that claude_code_reply should be used for continuation instead of starting a new session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: to start a run. It details the main polling loop using claude_code_check, handling permission requests with respond_permission, adjusting polling cadence based on progress, and waiting for long-running work. It also tells when to use claude_code_reply instead of starting a new session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claude_code_checkADestructive
Poll session state or answer a pending permission request.
POLLING FREQUENCY: Do NOT poll every turn. Claude Code tasks take minutes, not seconds.
"running": sleep at least 2 minutes between polls; increase for complex tasks. Do NOT high-frequency poll — it wastes tokens.
"waiting_permission": poll ~1s and respond quickly.
"idle"/"error"/"cancelled": stop polling.
Adapt interval based on task complexity and whether the previous poll returned new events.
Main loop: call action='poll', persist nextCursor, and use action='respond_permission' for approvals.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | 'poll' fetches new events/actions/result; 'respond_permission' answers one pending permission request. | |
| cursor | No | Default: 0. Pass the previous nextCursor to avoid replaying old buffered events. | |
| decision | No | Default: none. Required for action='respond_permission'. 'allow_for_session' reduces repeated prompts in the same session. | |
| interrupt | No | Default: false. When true, a deny decision also interrupts the whole session. | |
| maxEvents | No | Default: 200 (minimal), unlimited (full/delta_compact) | |
| requestId | No | Default: none. Required for action='respond_permission'. | |
| sessionId | Yes | Session ID returned by claude_code or claude_code_reply. | |
| denyMessage | No | Default: 'Permission denied by caller'. Used only with decision='deny'. | |
| pollOptions | No | Default: none. Advanced polling payload controls for action='poll'. | |
| responseMode | No | Default: 'minimal'. Use 'delta_compact' for compact event payloads; use 'full' mainly for diagnostics. | |
| permissionOptions | No | Default: none. Advanced permission response overrides for action='respond_permission'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| events | Yes | |
| result | No | |
| status | Yes | |
| actions | No | |
| isError | No | |
| sessionId | Yes | |
| truncated | No | |
| nextCursor | No | |
| cancelledAt | No | |
| lastEventId | No | |
| pollInterval | No | |
| cursorResetTo | No | |
| lastToolUseId | No | |
| availableTools | No | |
| compatWarnings | No | |
| toolValidation | No | |
| cancelledReason | No | |
| cancelledSource | No | |
| truncatedFields | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds valuable behavioral context: explains token-wasting risks, the need for adaptive polling, and the ability to interrupt sessions via the interrupt parameter. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings for polling frequency and main loop. It is somewhat lengthy but every sentence adds essential context, especially given the tool's complexity. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, nested objects, output schema exists), the description covers the high-level flow, polling states, and main loop adequately. It does not explain all edge cases, but schema descriptions handle parameter details. Completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already explained. The description adds semantic value by explaining how parameters like action, cursor, and decision fit into the polling loop and permission response flow, going beyond the schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool polls session state or answers pending permission requests, with a specific verb+resource. It distinguishes from siblings (claude_code, claude_code_reply, claude_code_session) by its unique polling and permission-responding functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit polling frequency guidelines based on session state, including minimum intervals and when to stop polling. Also describes the main loop pattern and adapts intervals based on task complexity. This exceeds typical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claude_code_replyADestructive
Send a follow-up to an existing session. Reuse the same sessionId instead of starting a new claude_code session when you want to continue. Returns immediately; poll with claude_code_check. Use diskResumeConfig only when the in-memory session is missing and disk resume is enabled.
| Name | Required | Description | Default |
|---|---|---|---|
| effort | No | Effort string: 'low' | 'medium' | 'high' | 'max'. Default: SDK | |
| prompt | Yes | Follow-up prompt for the existing session. | |
| thinking | No | Thinking config object, not a string. Use {type:'adaptive'} | {type:'enabled', budgetTokens?:N} | {type:'disabled'}. Default: SDK | |
| sessionId | Yes | Session ID from claude_code or an earlier claude_code_reply. Prefer this over starting a fresh claude_code session. Reply works only for persistent sessions, or with diskResumeConfig when disk resume fallback is enabled. | |
| forkSession | No | Default: false | |
| diskResumeConfig | No | Default: none. Use only when the in-memory session is missing and the server allows disk resume. | |
| sessionInitTimeoutMs | No | Default: 10000. Applies when forkSession=true. | |
| permissionRequestTimeoutMs | No | Server permission wait timeout in ms; not forwarded to SDK Options. Default: 60000, clamped to 300000 |
Output Schema
| Name | Required | Description |
|---|---|---|
| error | No | |
| status | Yes | |
| sessionId | Yes | |
| resumeToken | No | |
| pollInterval | No | |
| compatWarnings | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns immediately and requires polling, adds nuance about diskResumeConfig, and aligns with annotations (destructiveHint=true, openWorldHint=true). It provides valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with purpose, and each sentence adds unique value. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter coverage, the description sufficiently covers essential behavioral aspects and use cases. It is complete for an async tool with polling and conditional disk resume.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds meaning by clarifying when to use sessionId and diskResumeConfig, exceeding the schema's documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a follow-up to an existing session, distinguishes it from starting a new session via 'claude_code', and references polling via 'claude_code_check'. It explicitly mentions reusing sessionId, making the verb and resource specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to reuse sessionId instead of starting a new session, advises polling with claude_code_check, and specifies when to use diskResumeConfig. It provides clear context and exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
claude_code_sessionBDestructive
List, inspect, cancel, or interrupt sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Session operation: list, get, cancel, or interrupt. | |
| sessionId | No | Required for get/cancel/interrupt. | |
| includeSensitive | No | Default: false. Exposes more session fields, but some secrets remain redacted. |
Output Schema
| Name | Required | Description |
|---|---|---|
| isError | No | |
| message | No | |
| sessions | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide destructiveHint: true, indicating destructive actions. The description mentions cancel and interrupt, but does not clarify differences or side effects. With annotations, the description adds no extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, front-loaded with verbs. Could be structured better for multi-action tools, but not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given multiple actions and an output schema, the description should detail what each action does and prerequisites (e.g., sessionId required for get/cancel/interrupt). Missing these details makes it incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; parameters are well-documented in the schema. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages sessions with actions like list, inspect, cancel, or interrupt. It distinguishes from sibling tools like 'claude_code_check' or 'claude_code_reply' which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs siblings, or when to choose one action over another. For a tool with multiple distinct actions, such guidance is missing.
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.
4 tool updates
v2.8.3- First observed
claude_code - First observed
claude_code_check - First observed
claude_code_reply - First observed
claude_code_session
TDQS
Each tool has a distinct purpose: starting a session, polling/responding, sending follow-ups, and managing sessions. No overlap.
All tools follow the claude_code_<action> pattern except the base start command (claude_code). This minor deviation is consistent enough for easy recognition.
Four tools cover the essential operations for managing Claude Code sessions without unnecessary complexity.
The tool surface covers the full lifecycle: start, poll/respond to permissions, send follow-ups, and manage sessions. No obvious gaps.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Give any MCP-compatible AI assistant a builder for live, hosted web tools and workflows.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables MCP clients to spawn and control Codex CLI and Claude Code sessions on the host machine, with session management and filesystem access.4MIT
- AlicenseAqualityDmaintenanceWraps Anthropic Claude Code CLI as tools, allowing MCP clients to invoke headless Claude Code sessions.2147MIT
- FlicenseNot gradedqualityCmaintenanceExposes Claude Code's file editing, command execution, and test running capabilities as composable MCP tools for any MCP-compatible host, enabling code operations via a stateless bridge.-
- AlicenseAqualityAmaintenanceEnables search, analytics, and visualization of Claude Code sessions with MCP tools for session management, recovery, and insights.101MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/xihuai18/claude-code-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server