What can you do with this server?

This server bridges any MCP host to Claude Opus running headlessly, enabling powerful autonomous AI delegation. It offers the following tools: * ask — Pose read-only questions to Opus for architecture, planning, or explanations. * delegate — Hand off a complete autonomous task (file edits, shell commands, tests) to Opus, which runs its own agentic loop until completion. * fire — Start a background autonomous task and return immediately with a session_id for later progress checks. * check — Poll the status and progress of a background fire task by session_id. * follow_up — Continue a prior session by session_id without resending context, since it lives on Claude's side. * adversarial_review — Get a critical, read-only review of code, plans, or diffs — hunting for bugs, edge cases, security issues, and race conditions. Useful as a pre-merge gate. * web_lookup — Delegate a web/documentation lookup to Opus (with live web access) to find library docs, API references, error explanations, or current package versions. All tools support cwd (project root) and effort (low/medium/high) parameters, and most support model selection (defaulting to Opus). Delegated tasks also support permission controls (e.g., acceptEdits, bypassPermissions).

How do I use claude-mcp-bridge?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claude-mcp-bridge analyze the src directory for bugs" 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-mcp-bridge

by JaimeJunr

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

claude-mcp-bridge

MCP server that lets any agent or MCP host (Cursor, Codex, Antigravity, another Claude Code, your own app) escalate to Opus via Claude Code running headless (claude -p / claude --bg).

Opus is expensive but very capable — this bridge is deliberately narrow: complex reasoning, architecture questions, adversarial review, and autonomous work. Cheap mechanical work (mapping a repo, scanning files) should stay on the host agent's lighter model.

Nested MCP delegation is blocked: Opus sessions spawned by this bridge cannot call claude-mcp-bridge (or any MCP) again.

Tools

Tool	Purpose	Model
`ask`	Read-only Q&A — architecture, explanation, planning (`claudecode({ prompt: "..." })`)	Opus (forced)
`delegate`	Full autonomous task — edit, shell, tests (max turns, synchronous)	Opus (forced)
`fire`	Fire-and-forget background task — returns `session_id` immediately	Opus (forced)
`check`	Compact progress report for a `fire` session	read-only (no model)
`follow_up`	Continue a prior session by `session_id`	Opus (forced)

Parallel background tasks

fire({ prompt: "Refactor the auth module to use JWT" })
→ returns session_id immediately

check({ session_id: "..." })
→ check progress anytime

Examples

// Ask Opus to explain architecture (read-only)
{ "prompt": "Explain the architecture of this project" }

// Delegate autonomous work (waits for completion)
{ "prompt": "Refactor auth to JWT and fix all tests" }

// Background refactor — poll while you keep working
{ "prompt": "Refactor the auth module to use JWT", "name": "JWT refactor" }
// → session_id: ...
{ "session_id": "..." }

Every tool accepts: cwd (project root), effort (low | medium | high, default high).

Related MCP server: agent-network

Requirements

Node ≥ 18
claude CLI v2.1.139+ installed and authenticated (claude once to log in). Background tasks (fire / check) require claude --bg and claude agents --json.

Install

git clone https://github.com/JaimeJunr/claude-mcp-bridge.git
cd claude-mcp-bridge
npm install
npm run build

Register in an MCP host

Claude Code:

claude mcp add claude-bridge -s user -- node /abs/path/to/claude-mcp-bridge/dist/index.js

Cursor / Codex / any host — add to its mcp.json:

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

Configuration (env)

Var	Default	Meaning
`CLAUDE_BIN`	`claude`	Path to the `claude` binary.
`CLAUDE_BRIDGE_MODEL`	`opus`	Model alias — always Opus in this bridge.
`CLAUDE_BRIDGE_EFFORT`	`high`	Default reasoning effort.
`CLAUDE_BRIDGE_MAX_TURNS`	`20`	Max agentic turns for `delegate` / `fire`.
`CLAUDE_BRIDGE_PERMISSION`	`acceptEdits`	Permission mode for delegate/fire: `plan` \| `default` \| `acceptEdits` \| `bypassPermissions`.
`CLAUDE_BRIDGE_TIMEOUT_MS`	`600000`	Per-call timeout for sync tools (`ask`, `delegate`).
`CLAUDE_BRIDGE_SHORT_TIMEOUT_MS`	`30000`	Timeout for `fire` / `check`.

Security: acceptEdits lets delegated Opus edit files autonomously; bypassPermissions additionally allows unrestricted shell. Only raise this for trusted workspaces. ask always uses plan (read-only).

Develop

npm test       # vitest — unit tests for arg building / json parsing
npm run dev    # run from source via tsx

License

MIT

Available Tools

4 tools

adversarial_reviewA

Get an adversarial code/plan review from Claude. Claude hunts for bugs, edge cases, security issues, race conditions and unstated assumptions. USE THIS before merging or committing. Read-only: Claude is instructed not to modify files.

ParametersJSON Schema

Name	Required	Description
`content`	No	Inline content to review (plan, diff, code snippet).
`files`	No	File paths to review instead of inline content.
`focus`	No	Optional focus area, e.g. 'security', 'concurrency'.
`cwd`	No	Absolute path to the project root. Defaults to the server's cwd.
`model`	No	Claude model alias or full name (e.g. 'opus', 'sonnet', 'haiku'). Omit to use the default.
`effort`	No	Reasoning effort: 'low' \| 'medium' \| 'high'. Higher = deeper, slower, costlier.

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description carries the full burden. It discloses that Claude is instructed not to modify files (read-only), and outlines the scope of the review. Lacks details on other behaviors like rate limits or auth, but sufficient for a non-destructive tool.

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, front-loaded with purpose and usage. Every sentence adds value without redundancy. Highly efficient.

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?

With 6 parameters and no output schema, the description covers purpose, usage, and behavioral aspects. It could elaborate on what the review output looks like, but overall provides sufficient context for an agent to decide when to invoke.

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 baseline is 3. The description does not add extra meaning beyond the parameter descriptions in the schema. It focuses on tool purpose, not parameter details.

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 performs an adversarial review of code or plans, hunting for bugs, edge cases, security issues, race conditions, and unstated assumptions. It distinguishes itself from sibling tools (delegate, follow_up, web_lookup) by focusing on review.

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 use before merging or committing. Also notes read-only behavior. Could be improved by specifying when not to use, but the guidance is clear and actionable.

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

delegateA

Delegate a complete task to Claude Code running headless (claude -p). Claude has full tool access (read, edit, shell, web) in the given cwd and runs its own agentic loop. Use for heavy autonomous work: refactors, multi-file implementation, running and fixing tests.

ParametersJSON Schema

Name	Required	Description
`prompt`	Yes	The complete task prompt for Claude.
`cwd`	No	Absolute path to the project root. Defaults to the server's cwd.
`model`	No	Claude model alias or full name (e.g. 'opus', 'sonnet', 'haiku'). Omit to use the default.
`effort`	No	Reasoning effort: 'low' \| 'medium' \| 'high'. Higher = deeper, slower, costlier.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description fully explains behavioral traits: Claude runs headless with full tool access and its own agentic loop. It adds context about autonomous operation beyond what the input schema provides, though it omits details about result handling or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: three sentences that front-load the core action, then provide behavioral details, then usage guidance—no wasted words.

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?

While the description covers purpose and behavioral context well, it is silent on the return value or any output format, which is a gap given the lack of output schema and the complexity of delegation.

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 detailed parameter descriptions. The tool description does not add further meaning to any parameter beyond the schema, matching the baseline expectation.

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

Purpose5/5

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

The description clearly states the verb ('delegate') and resource ('complete task to Claude Code'), and distinguishes from siblings by emphasizing autonomous multi-file work, which is not covered by adversarial_review, follow_up, or web_lookup.

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 guides usage for 'heavy autonomous work: refactors, multi-file implementation, running and fixing tests', providing clear context for when to use, though it does not directly contrast with siblings.

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

follow_upA

Continue a previous Claude session by session_id (returned by every other tool). The prior context lives on Claude's side, so you don't resend it.

ParametersJSON Schema

Name	Required	Description
`session_id`	Yes	The session id returned by a previous claude-mcp-bridge call.
`question`	Yes	The follow-up question.
`cwd`	No	Absolute path to the project root. Defaults to the server's cwd.
`model`	No	Claude model alias or full name (e.g. 'opus', 'sonnet', 'haiku'). Omit to use the default.
`effort`	No	Reasoning effort: 'low' \| 'medium' \| 'high'. Higher = deeper, slower, costlier.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It reveals that prior context is stored server-side and not resent, which is a key behavioral trait. However, it does not disclose whether the operation is read-only or mutates state, error conditions, or rate limits.

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, front-loaded with the core purpose. No redundant or unnecessary information, making it efficient and easy to parse.

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?

For a tool with 5 parameters and no output schema or annotations, the description is minimal. It explains the core purpose and the key advantage but omits details about return values, error handling, session lifecycle, and how to obtain the session_id beyond a vague reference.

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 baseline is 3. The description adds value for the 'session_id' parameter by explaining why it is needed and that context is preserved. No additional semantic info is provided for other parameters beyond their schema descriptions.

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

Purpose5/5

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

Description clearly states 'Continue a previous Claude session by session_id', using a specific verb and resource. It distinguishes from siblings like 'delegate' and 'web_lookup' as it focuses on continuing an existing session rather than starting a new task or lookup.

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 states that the tool is used to continue a session by providing a session_id returned by other tools, and mentions the benefit of not resending context. However, it does not provide alternatives or explicit when-not-to-use guidance.

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

web_lookupA

Delegate a web/documentation lookup to Claude (with web access): library docs, API references, error messages, current versions. Use when you need information that may be newer than your training data.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	What to look up on the web.
`cwd`	No	Absolute path to the project root. Defaults to the server's cwd.
`model`	No	Claude model alias or full name (e.g. 'opus', 'sonnet', 'haiku'). Omit to use the default.
`effort`	No	Reasoning effort: 'low' \| 'medium' \| 'high'. Higher = deeper, slower, costlier.

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'Claude (with web access)' but does not disclose behavioral traits like rate limits, cost, latency, or that it makes external requests. Significant gaps for a tool that initiates network calls.

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 redundancy. First sentence introduces the tool, second sentence adds usage context. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is adequate for a simple lookup tool but lacks details on return format, error handling, or operational characteristics. Could be more complete.

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

Parameters4/5

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

Schema coverage is 100%, providing baseline parameter descriptions. The description adds value by specifying example query types (library docs, error messages), enhancing semantic understanding beyond the schema.

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

Purpose4/5

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

The description clearly states it delegates web/documentation lookup to Claude, listing specific use cases like library docs and API references. It does not explicitly differentiate from sibling tools but the purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides usage guidance: 'Use when you need information that may be newer than your training data.' This gives clear context for when to invoke, though it lacks explicit when-not-to-use or alternative tool mentions.

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

Tool Schema Changelog

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

4 tool updatesv0.2.0Jun 22, 2026
- First observedadversarial_review
- First observeddelegate
- First observedfollow_up
- First observedweb_lookup

Deploy Server

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

TDQS

A4/5.0

Scored 2026-06-22 20:30 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: adversarial_review for code review, delegate for autonomous tasks, follow_up for session continuation, and web_lookup for web searches. No overlap is apparent.

Naming Consistency4/5

All tools use snake_case, with a mix of verb_noun (delegate, follow_up), adjective_noun (adversarial_review), and noun_verb (web_lookup). The pattern is mostly consistent but not perfectly uniform.

Tool Count5/5

With 4 tools, the set is well-scoped for a delegation bridge server. Each tool earns its place, covering review, autonomous execution, session management, and web lookup.

Completeness4/5

The tool surface covers key delegation scenarios: code review, autonomous work, session continuation, and web research. A minor gap is a simple chat or query tool, but the core use cases are addressed.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

microservices.sh
sh.microservices
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Cloud Platforms Agent Orchestration Developer Tools
21
agentmailrooms-mcp
com.clauxel.agentmailrooms
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
Agent Orchestration Autonomous Agents
2
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128

Related MCP Servers

cc-agent
Autonomous Agents Coding Agents Version Control
Gonzih
A
license
A
quality
D
maintenance
MCP server that spawns autonomous Claude Code agents in GitHub repos, enabling task delegation with persistent state, multi-step workflows, and job monitoring.
Updated 3 months ago (2026-06-21 20:37 UTC)
47
187 npm
2
Apache 2.0
agent-network
Agent Orchestration Communication Coding Agents
sharifli4
A
license
Not graded
quality
D
maintenance
MCP server that enables Claude Code to communicate with other Claude Code agents over HTTP, allowing users to ask questions about remote codebases or delegate coding tasks.
Updated 6 months ago (2026-03-13 07:21 UTC)
MIT
claude-bridge-mcp
Code Execution Coding Agents Developer Tools
millanrp25-dot
A
license
Not graded
quality
C
maintenance
An MCP server that lets ChatGPT or any MCP client securely delegate coding tasks to a local Claude Code instance, with git checkpointing, approval gates, and structured results. Supports code review, test running, and rollback via simple tool calls.
Updated a month ago (2026-08-08 22:06 UTC)
5 npm
MIT
claude-for-hermes
Coding Agents Autonomous Agents Command Line
7D-codes
A
license
Not graded
quality
B
maintenance
A local MCP server that lets Hermes supervise Claude Code, delegating focused coding, research, or review tasks to the Claude Code CLI and managing worker sessions, background jobs, cancellations, and read-only reviews.
Updated a month ago (2026-08-06 13:39 UTC)
2
MIT