Which integrations are available for this server?

Allows using Apple's on-device AI CLI for vision tasks and offline inference. Allows using Google's Gemini CLI with 1M-token context, fresh knowledge, and vision. Allows running local AI models via Ollama for free cross-checks and offline tasks. Provides security review analysis based on OWASP guidelines.

How do I use cli-bridge?

1. Click on "Install 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., "@cli-bridge Generate a social card image using GPT lane" 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.

cli-bridge

by JoaoBerne

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

English · Français · 简体中文 · Español · Português (BR) · 日本語 · Deutsch

cli-bridge

PyPI stars python license MCP ban--safe

Your assistant is only as good as the one model you opened. cli-bridge is a Model Context Protocol server that lets it borrow the other AI CLIs you already run — a bigger context, vision, a free second opinion from a different vendor, or a delegated build that comes back as a reviewable diff.

No API keys · no token extraction · no Node · no daemon · stdlib + mcp only.

In one sentence

You're talking to one AI assistant. You've also installed and logged into others — Claude Code, Codex, Gemini, opencode, Ollama. cli-bridge connects them: when your assistant needs something it can't do alone, it asks one of the other CLIs and hands you the result.

The problem it solves

Whatever assistant you're using has hard limits. It can't read a 2M-token repo in one pass, can't see a screenshot, can't hand you a generated image, and can't check its own work without bias — but some other CLI on your machine can do each of those. cli-bridge is the bridge between them: it spawns the official CLI as a subprocess (exactly as you'd run it by hand — no keys, no token extraction) and returns the answer to your assistant.

The result: one assistant whose ceiling on every axis is the best tool in your toolbox, not the one you happened to open.

The 10-second demo

You're in Claude. Claude can't hand you an image. Codex can — natively with gpt-image-2, or by writing a script that renders one. For a precise layout like a social card, have it script and run it:

ask_build(lane="gpt", task="generate a 1200×630 social card to assets/card.png — write a script that renders it, then run it", zone="assets")
→ Codex writes assets/card.png · you get the path back, never a binary blob (artifact-return)

Your assistant just gained an ability it doesn't have. That's the whole idea — now scale it to giant-context reads, vision, parallel grunt-work, and independent cross-vendor verification.

(Codex generates the image with gpt-image-2, a real text-to-image model built into the CLI — counted against your ChatGPT plan's usage, no separate API key (image generation needs a paid plan; it's not on the Free tier). It comes back as a path, not a blob, because binaries travel by artifact-return, not the text channel. A build lane can also render charts, diagrams or SVGs by writing code, when that's the better fit.)

…and it delegates real work, safely

cli-bridge build <lane> "<task>" hands the job to another model running in a throwaway git worktree, then gives you back a diff — your repo is never touched until you apply it yourself.

Related MCP server: cli2mcp

What you get — the four levers

cli-bridge isn't one feature, it's four abilities your assistant gains. Get these and every tool below slots into place:

Borrow — reach a capability your assistant lacks (vision, a 1M-token context window, a file a coding agent generates, a model that's simply better at this).
Spread — when one subscription hits its limit, keep going on another lane you already pay for.
Offload — fan laborious, parallel grunt-work across cheap/free lanes while you build elsewhere.
Verify — have a different vendor family check the work, because a model can't catch its own blind spots. This is the one thing a single-vendor tool structurally cannot do.

What this unlocks

Each block: one sentence of when you reach for it, the exact call, and what you get back.

Borrow abilities your assistant doesn't have

Every CLI has a different superpower, and each runs non-interactively — so cli-bridge can spawn it. Borrow the one your host lacks (it must be installed + logged in):

Superpower	Which CLI has it	Borrow it when
Images	Codex (`gpt-image-2`, no API key — paid ChatGPT plan, not Free)	your host can't draw
Huge context	Gemini (1M-token window)	a file/repo won't fit your host's context
Fresh knowledge	Gemini (Google-Search grounding) · Grok (live web/X) ⚗️	beat a stale cutoff: "what's the current API of `<lib>`?"
Vision	`images=[…]` on Codex · opencode · Ollama · Apple · Gemini ⚗️	analyse a screenshot or diagram
A free second opinion	opencode · Ollama · Apple (local, $0) · Gemini (scarce free tier)	a $0 cross-check
Generated files	any build lane → artifact-return	get a chart / PDF / diagram back by path
Video ⚗️	Grok (Imagine) — if your installed CLI exposes it (Veo isn't exposed by any official Gemini CLI extension)	you need a generated clip

ask_build(lane="gpt", task="generate a 1200×630 social card to assets/card.png", zone="assets")   # Codex image → file by path, no API key (paid ChatGPT plan)
ask_gemini(task="find the bug across ./src — read the files you need", cwd="path/to/repo")         # 1M-token context
ask_gemini(task="what's the current recommended API for <lib>? check the latest docs")            # fresh knowledge (Search grounding)
ask_apple(task="what's wrong in this UI?", images=["screenshot.png"])                             # vision, on-device, $0, offline

Vision, honestly: images=[…] is no longer one vendor's feature. Five lanes take it and each lane declares its own shape as data, so you always just pass paths — an argv flag (apple --image, gpt -i, opencode -f) or a path folded into the prompt (gemini @path, ollama bare); a sixth lane is one field, not a code path. Caveat: whether the image is actually read depends on the model behind the lane, not the lane — on the same test image one free model transcribed every line and another answered "model lacks vision". Full table in docs/TOOLS.md.

⚗️ = experimental / depends on the installed CLI's current build (e.g. Grok Build is beta) — verify with doctor --deep.

Never stop working when you hit a limit

When your main subscription caps out mid-task. ask_cascade falls through to another lane you already pay for, skipping any lane that's cooled down after a quota/auth/timeout error.

ask_cascade(task="finish wiring this endpoint")   # cheapest→strongest; a cooled-down lane is skipped
ask_best(task="…", mode="deep")                   # let the router pick the most suitable available lane

Offload the grunt work — in parallel, and cheap

When the work is laborious but not hard (refactors, migrations, test coverage). Fan it out, journaled so a server restart resumes instead of restarting; delegate a build and keep working.

batch_run(tasks=[...], dry_run=true)                       # cost envelope first — nothing is spawned
batch_run(tasks=[...], max_calls=20, max_credits=2.0)      # then run under a hard budget (resumable)
ask_build(lane="opencode", task="add the landing page", zone="frontend", mode="direct", async=true)   # delegate, keep building
job_tail(job_id="…")  ·  build_steer(job_id="…", instruction="use Tailwind, not inline CSS")

Break self-confirmation — the 2026 problem one vendor can't solve

When you need to trust a result. A model reviewing its own work (or a sibling's) just confirms its own blind spots. cli-bridge puts a different model family in the reviewer's seat.

workflow(preset="jury", task="is this migration safe?", author_lane="gpt")            # cross-family vote, fail-closed
workflow(preset="verify_repair", task="add retry with backoff",
         builder_lane="gpt", verifier_lane="gemini")                                   # A builds, B reviews, loop to green
security_review(base="origin/main")   ·   review_diff(base="origin/main")              # OWASP, severity-ranked

Get a real second opinion

When you've reached a conclusion and want it pressure-tested, or several models side by side.

challenge(task="I'm dropping the cache layer — here's why: …")                         # one skeptic attacks it
consensus(task="which migration strategy is safest here?")                             # N answer, peer-rank the best
workflow(preset="fanout_compare", task="fix this failing test", lanes=["gpt","gemini","opencode"])

The toolbox

~30 tools, grouped by intent — the headline ones:

Consult (read-only): ask_<lane> (one model), ask_all (every free lane in parallel + a disagreement score), ask_cascade (resilient fall-through), ask_best (router), consensus, challenge.
Build (opt-in write): ask_build — mode=isolated→diff · mode=direct→zone-guarded · async→steerable, behind an executable Definition-of-Done gate.
Review & verify: review_diff, security_review (findings tagged by severity and category — security / correctness / scope / ambiguity / performance / ops), debate, and workflow(preset=…) — converge (governance loop: an independent arbiter commits a blind verdict, anonymized cross-vendor peers review, every issue is adjudicated with a reason, then revise-or-converge), jury (cross-family k-of-N vote, fail-closed), verify_repair, fanout_compare, …
Orchestrate & operate: batch_run (durable, budget-capped fan-out), plus usage_report, rate_lane, lane_stats, set_lane_cost, doctor.

Full reference — every tool, every flag: docs/TOOLS.md (or cli-bridge --help). Run CLI_BRIDGE_LEAN=1 for a curated ~12-tool surface.

There's also a human CLI — cli-bridge doctor|ask|build|review-diff|eval|… — the same engine from your terminal or CI (--json everywhere); cli-bridge build <lane> "<task>" returns a reviewable diff without touching your repo (--apply to land it as unstaged changes).

What you actually get when you combine them

One assistant whose ceiling on every axis is the ecosystem's best — not the tool you opened this morning: code with the strongest model, read ~1M tokens when yours is too short, answer with fresh knowledge past a stale cutoff, generate images/video, see screenshots, and fall back to a free/local lane when you're capped — spread across the subscriptions you already pay for.

The emergent property no single CLI has: true cross-vendor control — a different vendor in the reviewer's seat. Same-family subagents (Claude Code's, Grok's) can only self-confirm.

The honest seam: this unites capabilities, not mind — stateless spawns (no shared memory), spawn latency/cost, uneven quality, and the host always drives. It's orchestration, not fusion: you conduct specialists, you don't get one brain with every power.

→ Per-CLI strengths & limits (dated, churns fast): docs/COMPARISON.md.

Why cli-bridge (and not another "call other models" MCP)

🛡️ Ban-safe by design. It spawns each model's official CLI, exactly as you'd run it by hand — no OAuth-token extraction, no API-key reuse. Each CLI handles its own auth and billing.
💸 Cost-safe defaults you tune to your plan. Out of the box ask_all / ask_cascade build a free council and never touch paid quota unless you ask. Each lane ships a tier sourced from the vendor's published plans (dated in docs/COSTS.md, never detected from your account); override per lane with CLI_BRIDGE_<LANE>_COST=free|limited|paid. Two caps are enforced at spawn — CLI_BRIDGE_<LANE>_DAILY_LIMIT (runs/day, any lane) and CLI_BRIDGE_DAILY_CREDIT_CAP — full model in docs/BUDGET.md.
🔌 Works from any host. Claude Code, Codex, opencode, Cursor, VS Code (Cline/Continue), Zed — anything that speaks MCP over stdio. The host's own lane is kept out of fan-out; hide it with CLI_BRIDGE_HIDE_HOST=1. Even a local model can be the host — see examples/local-first-host.md.
🧭 The cross-vendor edge is the moat. Independent verification means a different vendor in the reviewer's seat — the scarce thing as AI writes a larger share of code, and exactly what a single-vendor tool can't offer.

Side by side

How the multi-model orchestrators differ on the axes that bite later — auth model, spend control, and what happens to your repo. (As of June 2026, read from each project's public repo/docs — corrections welcome.)

	claude-octopus	PAL / zen-mcp	deliberation	cli-bridge
How other models are reached	hybrid: CLI spawn, OAuth-subscription reuse, or API keys	API keys (providers) + CLI spawn (`clink`)	CLI spawn (Codex/Gemini) + API keys (Grok, OpenRouter)	official CLI subprocess by default — each CLI keeps its own auth; optional opt-in API lanes
API keys needed	optional fallback	for most providers	for Grok & OpenRouter	never by default — opt-in API lanes stay hidden until you set their key
Spend control	session-only cost gate (`OCTOPUS_MAX_COST_USD`; no cross-session history)	none found	none found	enforced: per-lane daily run limit + daily credit cap + per-invocation budget, persisted (docs/BUDGET.md)
Consensus governance	—	—	blind verdict + mandatory reason for each dismissal	`converge`: blind arbiter verdict, reasoned adjudication, no-self-approval — over anonymized cross-vendor peers, all 3 guards enforced in code
Delegated edits	in-place	in-place (bypass/yolo flags)	in-place (`workspace-write` experts)	throwaway worktree → diff (your repo untouched), or zone-guarded direct mode (+ opt-in read-only-write guard)
Survives host restart / `/compact`	session-scoped state	in-memory threads (TTL)	opt-in on-disk; in-memory by default	sqlite: conversations, jobs, fan-out journal
Runtime deps	Node 18+, npm, bash	Python + pip packages	Node 18+, npm	Python stdlib + `mcp`
Hosts	Claude Code-first (plugin; MCP server secondary)	any MCP host	any MCP host (+ Claude Code plugin)	any MCP host (+ a Claude Code plugin)

Where they're stronger, honestly: claude-octopus ships a much larger workflow surface (49 commands, 32 personas, CI reactions); PAL has the biggest community (~11.6k★) with a polished tool set; and deliberation is a focused, mature single-purpose governance tool that pioneered the blind-verdict / mandatory-dismissal-reason model — cli-bridge has since adopted exactly those guards as workflow preset=converge (and runs them over anonymized cross-vendor peers under enforced budgets), but deliberation remains the more specialized product for that one job. cli-bridge's bet is broader: ban-safe auth, enforced budgets, cross-vendor verification, and delegation that can't wreck your repo — verified by its own shipped eval instead of claimed.

How it works

host (Claude/Codex/…) ──MCP──> cli-bridge ──spawn──> official CLI ──> model
                                    │
       keeps the host's own lane out of fan-out · only shows installed, enabled CLIs
       kills the whole process tree on timeout/cancellation · redacts secrets
       classifies errors (auth/limit/failed) · spills huge output to a file

No network calls of its own. No keys stored. It runs the same binaries you already trust, in your working directory, and hands the answer back.

Real run, real-time: the Verify lever — security-review fans OWASP roles across several models in parallel (claude/gpt/opencode/ollama here); they flag a committed auth bypass blocker, and usage shows the receipts.

Two different vendors independently flag the same bypass — that's the point: uncorrelated blind spots, not one model's opinion. Note what it does not hide: a reviewer came back empty, so the recap says 3/4 answered and the residual-risk line names the category nobody assessed.

# Security review (OWASP-aware)

_Base: `HEAD~1` · reviewers: injection (Mistral (Vibe CLI)), auth & access control (OpenCode
(gateway to many models)), data exposure & SSRF (OpenCode (gateway to many models)) · read-only_

## Reviewers — 3/4 answered

- ✅ **injection (Mistral (Vibe CLI))** _10927ms_ — 1 finding(s)
- ✅ **auth & access control (OpenCode (gateway to many models))** _13875ms_ — 1 finding(s)
- ❌ **secrets & crypto (Mistral (Vibe CLI))** _8465ms_ — empty
- ✅ **data exposure & SSRF (OpenCode (gateway to many models))** _11792ms_ — 0 finding(s)

**2 findings** (1 blocker, 1 high) — _block — blocker-level issues must be fixed before merge_

_By type: 2 security_

## Blocker

- **Unauthenticated user granted admin access** `auth.py:3` — _single_ · OpenCode · _security_
  require_admin returns True when user is None, meaning any unauthenticated/anonymous caller is
  treated as admin. This bypasses the is_admin check entirely.
  **Fix:** If user is None: raise PermissionError('authentication required')

## High

- **Insecure default for anonymous users** `auth.py:3` — _single_ · Mistral (Vibe CLI) · _security_
  The function returns True for user=None, granting admin privileges to unauthenticated sessions.
  This allows anonymous users to bypass admin checks.
  **Fix:** Remove the `if user is None: return True` block and let the function raise
  PermissionError for anonymous users.

## Residual risk

Treat with care — reviewer role(s) failed (secrets & crypto=empty); their categories are
unassessed; this is a static review of the shown diff only — no runtime, dependency, or
deployment/secrets-config analysis was performed.

Reproduce it on the throwaway fixture (a committed if user is None: return True, built in /tmp):

sh docs/demo/setup.sh                 # creates /tmp/demo-authz
cd /tmp/demo-authz && cli-bridge security-review --base HEAD~1

(Trace footer omitted — CLI_BRIDGE_TRACE_FOOTER=off. Lanes vary with what you have logged in.)

Writing code safely: two modes

Writes are contained, two ways — you pick review-gated or hands-off:

isolated (default). Edits in a throwaway git worktree and hands back a diff. Your working tree is never touched.
direct. Writes real files, but only inside a zone you declare, behind a per-zone lock with a post-turn zone-violation check. You in backend/, a delegate in frontend/, concurrently — neither can scribble across your whole repo; undo is zone-scoped, never a global reset.

And a tripwire for the read-only path: set CLI_BRIDGE_VERIFY_PLAN_READONLY=1 and any plan (read-only) delegate that nonetheless writes to a git workspace gets a ⚠️ WORKSPACE MUTATION DETECTED flag on its answer (surfaced, never auto-reverted — you decide).

Delegate re-entry is depth-capped (CLI_BRIDGE_MAX_DEPTH, default 1) so a misconfigured delegate can't fork-bomb the council.

Where a delegate runs. Pass cwd and that wins. Leave it out and cli-bridge asks the host for its MCP workspace root — because hosts launch a user-scoped MCP server from your home directory, so the directory it inherits is an accident, and it decides both where an unscoped build delegate writes and where the delegate's own session file gets filed. Override with CLI_BRIDGE_DEFAULT_CWD if your host declares no roots.

Installation (≈5 min)

Prerequisites

Python 3.10+ and uv (uvx ships with it): curl -LsSf https://astral.sh/uv/install.sh | sh (macOS/Linux) · winget install astral-sh.uv (Windows).
At least one AI CLI installed and logged in — that's what cli-bridge borrows. Have any of: Claude Code, Codex, Gemini CLI, opencode, Ollama (local, $0). You consult only the lanes you already have.

1. Check what cli-bridge can see (no install — uvx fetches, runs, discards):

uvx --from cli-bridge-mcp cli-bridge doctor

doctor lists which CLIs are detected, their resolved paths, and cost tiers. doctor --deep validates each lane against its own --help.

2. Add it to your MCP host. cli-bridge is an MCP server — it runs inside your assistant, not by hand. Point the host at the same command:

Claude Code — as a plugin (one-time, adds /cli-bridge:council, /cli-bridge:review, /cli-bridge:security, /cli-bridge:build, /cli-bridge:setup and wires the MCP server):
```
claude plugin marketplace add JoaoBerne/cli-bridge-mcp
claude plugin install cli-bridge@cli-bridge-mcp
```

Claude Code — MCP only (no slash commands):

claude mcp add cli-bridge -- uvx cli-bridge-mcp

Desktop apps — Claude Desktop, Hermes Desktop, … cli-bridge is a plain stdio MCP server, so any desktop MCP client runs it:
- Claude Desktop: Settings → Developer → Edit Config (claude_desktop_config.json), add the mcpServers block below, restart the app.
- Hermes Desktop (Nous Research): Settings → MCP servers → Add → command uvx, args cli-bridge-mcp.
- GUI apps launch servers with a minimal PATH — cli-bridge compensates by also searching the usual install dirs (/opt/homebrew/bin, /usr/local/bin, ~/.local/bin, ~/.npm-global/bin, …) for your CLIs. If a lane still shows "NOT on PATH" in doctor, point it directly: CLI_BRIDGE_<LANE>_BIN=/full/path/to/cli in the server's env.
Any other host (Codex, Cursor, VS Code, Zed, …) — add to its MCP config (~/.claude.json, .mcp.json, or the host's equivalent):
```
{
  "mcpServers": {
    "cli-bridge": {
      "command": "uvx",
      "args": ["cli-bridge-mcp"]
    }
  }
}
```
Full example with env vars: examples/mcp.example.json. Per-host config paths (Cursor, VS Code, Cline, Windsurf, Continue, Zed, Visual Studio, Neovim, Xcode) and how to make your agent consult it on its own: docs/HOSTS.md.

Note: cli-bridge-mcp (the MCP server) is the host entry point; cli-bridge (no -mcp) is the human terminal CLI you ran for doctor in step 1.

3. Use it. Restart/reload your host and ask it to consult a lane — e.g. "use cli-bridge to get a second opinion from gpt" or "ask gemini to read ./src and find the bug".

Lanes

Built-in: Claude Code, Codex, Gemini (+ Antigravity agy), Mistral (Vibe), opencode, Ollama (local models, $0, offline), Apple Foundation Models (fm, on-device, $0, offline, unmetered), Qwen Code, Copilot, Cursor (cursor-agent), Grok, and two opt-in lanes that stay hidden until you set their env var (so the ban-safe default surface is unchanged): OpenRouter (400+ models, needs OPENROUTER_API_KEY) and Apple PCC (APPLE_FM_SERVE_URL).

Apple PCC talks to a local fm serve over HTTP. fm refuses PCC to anything cli-bridge spawns — it walks the caller's ancestry to the session boundary and checks that ancestor's code signature — so start the server through Terminal instead, which you can do from anywhere, including from your assistant: osascript -e 'tell application "Terminal" to do script "fm serve --port 1976"'. Terminal becomes the parent, which is the chain fm trusts. Same HTTP pattern serves llama.cpp / vLLM / LM Studio — the bundled cli-bridge-openai bridge now works keyless. See examples/apple-fm-serve.lane.json.

Local runtimes beyond Ollama — LM Studio · MLX · llama.cpp — ship as zero-code recipes: point CLI_BRIDGE_LANES_FILE at examples/lmstudio.lane.json, mlx.lane.json, or llamacpp.lane.json. (Several local runtimes of the same open weights give correlated answers — real council diversity comes from distinct vendors, not a second local runtime.)

Community lanes (examples/community-lanes.json, experimental + limited until you declare their cost): Aider, Goose, Plandex, Amp, Crush, Amazon Q Developer CLI, Droid.

Anything else is ~3 lines of JSON. Add a custom lane, or wrap any OpenAI-compatible endpoint two ways: spawn curl (key kept inside curl, never in argv), or use the bundled cli-bridge-openai stdlib bridge — set availability_env so the lane stays hidden until its key is exported. See examples/openai-compatible.lane.json and examples/ for recipes.

The honest part

"More models = better" is fragile — big models share training data, so their errors correlate. We measured our own central claim (cli-bridge eval, no LLM judge): a diverse council did not catch more bugs than one strong model — it cut the false alarms ~2×. Same catch rate, far less noise — which is exactly what keeps a reviewer trustworthy instead of muted. Precision is the product, not recall. The harness ships, so you can confirm it on your CLIs — numbers either way in docs/BENCHMARKS.md.

Known limitations

Ban-safe = no token/key extraction, not a blanket guarantee — non-interactive use of a provider's CLI isn't formally sanctioned everywhere and can change. Use your own accounts within their terms.
Async jobs are in-process — a server restart marks running jobs interrupted. batch_run / workflow are the exception: they journal each task and resume via resume_id.
The injection guard is heuristic — it catches high-signal patterns, not everything; treat delegate output as data, not instructions.
Token/credit figures are estimates (chars/4 + your CREDITS_PER_1K), never exact.
Cost tiers are sourced defaults, not detection — vendor-plan facts are dated; doctor warns when the snapshot is stale.
Experimental (qwen, copilot, grok, community lanes, images=): flags aren't verified live — doctor --deep checks them against each CLI's --help on your machine.

Roadmap

See CHANGELOG.md for shipped history. Currently exploring (not shipped): an independent-oracle verify mode (a cross-family lane writes tests from the spec, blind to the implementation, so the test catches the bug instead of mirroring it) and tighter limit-aware failover. Big inter-agent "bus" ideas (recursive spawn, shared state, wire protocol) are positioned honestly as a direction, never sold as a shipped protocol — see docs/ARCHITECTURE.md.

References

The design choices above aren't vibes — each maps to a finding in the literature. Every entry was checked against its source (authors + venue), because a tool that sells "honest cross-vendor verification" should get its own citations right.

Paper	ID	What it backs here
Du et al. — Improving Factuality and Reasoning via Multiagent Debate	2305.14325	`debate`: models critiquing each other beat one model alone
ReConcile — Round-Table Conference Improves Reasoning	2309.13007	`debate` convergence + confidence-weighted consensus
Mixture-of-Agents	2406.04692	layered aggregation across diverse models (and its limits)
Chain-of-Agents	2406.02818	role-specialized multi-agent pipelines
CriticGPT — LLM Critics Help Catch LLM Bugs	2407.00215	`review_diff` / `security_review`: an LLM critic catches bugs humans miss
Perez et al. — Discovering Language Model Behaviors (sycophancy)	2212.09251	why a same-family judge is weak → cross-vendor `jury` + peer anonymization
Wynn, Satija & Hadfield — Talk Isn't Always Cheap	2509.05396	debate failure modes → fail-closed verdicts, bounded rounds
CONSENSAGENT — Consensus via Sycophancy Mitigation (Findings of ACL 2025)	ACL 2025	sycophancy in consensus → "earn their seat" / anonymized peers
Maryanskyy — When Agents Disagree: The Selection Bottleneck	2603.20324	`consensus`: selection > synthesis (the deterministic peer-vote default)

A citation hygiene note. Talk Isn't Always Cheap (2509.05396) is Wynn, Satija & Hadfield — a popular council framework miscites it as "Xiong et al." We double-check attributions before repeating them, and flag it because honesty is the whole pitch.

Development

uv venv && uv pip install -e . pytest pytest-asyncio
pytest -q          # unit + integration (cross-host) tests; no real CLI or network needed

License

Apache 2.0

one side · bridged to a council

Available Tools

6 tools

doctorA

Read-only

Health check: which CLIs are installed, which is the host, paid lanes, defaults, current cost profile. Pass deep=true to also probe each lane with a tiny live call (checks auth/quota — uses a bit of free quota; skips paid lanes).

ParametersJSON Schema

Name	Required	Description	Default
`deep`	No	Live-probe each free lane's auth.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context: deep=true makes a tiny live call, uses a bit of free quota, and skips paid lanes. This goes beyond the annotation to explain side effects and cost behavior, which is essential for an agent to decide whether to use deep mode.

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 well-structured sentences. The first front-loads the purpose with a compact list of checked items. The second efficiently explains the deep flag with its key trade-offs. No wasted words; every clause adds information.

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?

For a simple one-parameter read-only tool without an output schema, the description adequately explains what the check covers and the deep behavior. It doesn't describe the return format, but the enumerated list of checked items gives a clear picture of the output content. This is fairly complete given the tool's simplicity.

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?

The schema already describes the 'deep' parameter as 'Live-probe each free lane's auth.', so the baseline is 3. The description enhances this by specifying that deep=true 'uses a bit of free quota' and 'skips paid lanes', adding cost and scope semantics 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?

The description uses a specific verb ('Health check') and enumerates the exact resources inspected: installed CLIs, host, paid lanes, defaults, and current cost profile. This clearly distinguishes it from siblings like setup, lane_stats, usage_report, usage_budget, and reset_lane_state.

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 clearly frames when to use this tool—as a health check for environment state and lane status—and provides detailed guidance on the deep=true flag, including its cost and scope. It doesn't explicitly name alternatives or exclusion criteria, but context is sufficient for an agent to choose this over sibling tools.

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

lane_statsA

Read-only

Per-lane health: total runs, failures, consecutive failures/timeouts, and any active cooldown (a lane in cooldown is skipped by ask_all until it clears).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds semantic context about cooldown (lanes in cooldown are skipped by ask_all), which helps interpret the reported value. It does not disclose return format or pagination, but the read-only nature is already covered by annotations.

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 a single, well-structured sentence that front-loads the purpose and lists the key metrics, with a parenthetical clarifying cooldown semantics. Every word earns its place and there is no wasted text.

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

Completeness4/5

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

The description covers all the tool's value propositions: the metrics it reports and the meaning of cooldown. With zero parameters and read-only annotations, the context is largely complete. However, since there is no output schema, it does not specify the return data structure (e.g., a map keyed by lane name), which an agent would need to parse the response.

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?

The tool has zero parameters and schema description coverage is trivially 100%. With no params, the baseline is 4, and the description adds meaningful context about what the tool reports (per-lane health metrics), which is essential given the empty input 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 the tool provides per-lane health metrics (total runs, failures, consecutive failures/timeouts, and active cooldown), which is specific and distinct from sibling tools like usage_report or reset_lane_state. It lacks an explicit action verb but the resource and scope are unambiguous.

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

Usage Guidelines3/5

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

The description implies the tool is used for inspecting lane health, but it does not explicitly say when to prefer it over alternatives like doctor or usage_report, nor does it provide exclusions. The cooldown note adds context about lane behavior but not direct usage guidance.

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

reset_lane_stateA

Clear a lane's cooldown + failure counters (e.g. after you re-logged in or your quota reset). Pass the lane key, e.g. 'gemini'.

ParametersJSON Schema

Name	Required	Description	Default
`lane`	Yes	Lane key to reset (e.g. gemini, gpt).

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already indicate a non-read-only, non-destructive operation. The description adds specifics about what state is affected (cooldown and failure counters) and the rationale (re-login or quota reset), giving behavior 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.

Conciseness5/5

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

The description is two sentences, front-loaded with the core action and followed by a relevant usage context and example. Every word earns its place; no fluff or repetition.

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

Completeness5/5

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

For a simple single-parameter tool, the description covers the purpose, when to use it, and what state will be cleared. It does not need to explain return values since there is no output schema and the operation is clear.

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?

The input schema fully describes the lane parameter with an example. The description reinforces this with 'Pass the lane key, e.g. 'gemini' and a practical example, adding value beyond the schema. Since schema coverage is 100%, the baseline is 3, but the example earns a 4.

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 identifies the action (clear) and the target (a lane's cooldown and failure counters). It distinguishes itself from sibling tools like lane_stats and usage_report by specifying it resets state rather than reporting or analyzing. The example 'gemini' further clarifies the resource.

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

Usage Guidelines4/5

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

Provides concrete use cases: 'after you re-logged in or your quota reset.' This gives clear context for when to use the tool. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of a 5.

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

setupA

Read-only

Show the cost-profile choice (saver/balanced/max) to walk the user through configuring how cli-bridge spends paid credits/quota. Call this on first use if the profile isn't set, ASK the user, then tell them how to set it.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and destructiveHint=false. The description adds context that this is a walkthrough that presents choices and tells how to set the profile, not actually mutate state. It implies interactivity ('ASK the user') but doesn't specify behavior if the profile is already set, which is a minor gap.

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 the core function, followed by usage context. Every word earns its place, no redundancy or fluff.

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?

For a 0-parameter informational tool with no output schema, the description covers purpose, timing, and content. It mentions the profile choices and the ask-action. The only missing piece is an explicit statement that it doesn't modify state, but annotations cover that.

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?

The tool has 0 parameters and schema coverage is 100%. No parameter explanation is needed; baseline 4 applies. The description adds no param info, but none is required.

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's purpose: to show cost-profile choices (saver/balanced/max) and guide the user through configuring spending. The specific verb 'show' and the resource 'cost-profile choice' distinguish it from sibling tools like usage_report or reset_lane_state.

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 explicit when-to-use guidance: 'Call this on first use if the profile isn't set'. It also instructs to 'ASK the user', which clarifies the interactive workflow. It doesn't mention when not to use, but the conditional is clear.

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

usage_budgetA

Read-only

Per-lane runs since UTC midnight vs an optional CLI_BRIDGE__DAILY_LIMIT (ENFORCED at spawn once reached), plus estimated tokens/credits spent today. Estimates only.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds valuable context by noting the data is 'Estimates only' and that the daily limit is 'ENFORCED at spawn once reached', which clarifies the tool's non-authoritative, informational nature and the enforcement behavior.

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 a single sentence that packs in all essential information without wasted words: the metric, the time window, the optional limit, the enforcement point, and the estimation caveat.

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 there are no parameters, no output schema, and strong annotations, the description covers the core behavior sufficiently. It names the key data points (runs, limit, tokens/credits) but could have been slightly more explicit about the returned representation; overall, it is reasonably complete for this simple 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?

The input schema is empty, so there are no parameter semantics to clarify. The baseline score for zero parameters is 4, and the description appropriately avoids inventing parameter details.

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 explains what the tool does: reports per-lane runs since UTC midnight against an optional daily limit, plus estimated token/credit spend. It is specific about the resource (per-lane usage) and scoping (since UTC midnight), but does not explicitly distinguish it from siblings like usage_report or lane_stats.

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

Usage Guidelines3/5

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

The mention of 'ENFORCED at spawn once reached' implies the tool is useful for checking whether a lane's daily limit has been hit, but there is no explicit guidance on when to use this tool versus alternatives. The usage context is somewhat implied rather than stated.

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

usage_reportA

Read-only

Local usage stats (this machine only): total runs, per-lane counts/success/avg latency, ESTIMATED tokens (chars/4) and credits (if CLI_BRIDGE__CREDITS_PER_1K is set), and recent calls. All token/credit figures are estimates, never exact.

ParametersJSON Schema

Name	Required	Description	Default
`since`	No	Limit to a recent window, e.g. '24h', '7d', '90m' (default: all).
`output_format`	No	text (default) or json.

TDQS

A3.7/5.0

Behavior5/5

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

Beyond the readOnlyHint/destructiveHint annotations, the description adds valuable context: the scope is local-only, token figures are estimated using a chars/4 approximation, credits depend on an environment variable, and all token/credit numbers are explicitly 'never exact'. This is strong transparency about accuracy and conditional behavior.

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, front-loaded with the core purpose, and every piece of information earns its place. No redundancy or filler.

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

Completeness4/5

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

Given the read-only annotations, fully documented schema, and simple report nature, the description covers the essential scope, estimation caveats, and conditional credits. The lack of an output schema is a minor gap, but the description's mention of 'recent calls' provides enough context for expected return content.

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?

The input schema already describes both parameters fully (since and output_format) with 100% coverage. The description does not add any parameter-specific meaning, so the baseline of 3 applies.

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 identifies the tool as a local usage report covering total runs, per-lane metrics, token estimates, credits, and recent calls. It provides specific scope ('this machine only') that distinguishes it from potentially broader stats tools, though it doesn't explicitly name sibling alternatives.

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

Usage Guidelines2/5

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

The description implies when to use it (for local usage stats) but gives no explicit guidance on when not to use it or how it compares to siblings like usage_budget or lane_stats. There are no exclusions or alternative tool references.

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.

6 tool updatesv0.2.0Aug 6, 2026
- First observeddoctor
- First observedlane_stats
- First observedreset_lane_state
- First observedsetup
- First observedusage_budget
- First observedusage_report

Install Server

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

TDQS

A3.9/5.0

Scored 2026-08-06 23:25 across 6 tools

Disambiguation4/5

Tools are mostly distinct: doctor focuses on overall health and auth, lane_stats on per-lane health and cooldowns, usage_report on local totals, usage_budget on daily limits, and reset_lane_state on clearing state. Some overlap exists between doctor and lane_stats, but descriptions clarify the boundaries.

Naming Consistency3/5

Names mix single verbs (doctor, setup) with noun phrases (lane_stats, usage_report, usage_budget, reset_lane_state). The verb_noun pattern is not consistent across the set, though the names themselves are descriptive and readable.

Tool Count5/5

Six tools is well-scoped for a CLI bridge management server, covering health, usage, budget, and state reset without redundancy or bloat.

Completeness4/5

The domain of monitoring and managing CLI lanes is reasonably covered: health checks, usage stats, daily budgets, and state reset are all present. A minor gap is the lack of a direct configuration tool (e.g., setting the cost profile), though setup guides the user through it.

Maintenance

ActivitySlowing

ResponsivenessSlow

Resources

GitHub Repository

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
QuallaaOAuth
com.quallaa
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
AI & Machine Learning Communication
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Multi-CLI MCP
Agent Orchestration AI & Machine Learning
osanoai
F
license
A
quality
C
maintenance
An MCP server that bridges multiple AI clients (Claude, Gemini, Codex, OpenCode) so they can call each other as tools.
Updated a month ago (2026-08-03 13:55 UTC)
1
41
69
-
cli2mcp
Command Line Shell Access
yaacov
A
license
Not graded
quality
D
maintenance
Enables AI assistants to call any CLI tool by scanning its help output and serving it as an MCP server.
Updated 3 months ago (2026-06-15 08:33 UTC)
1
GPL 3.0
Agent Factory MCP
Command Line Agent Orchestration
utenadev
A
license
B
quality
F
maintenance
A universal MCP server that automatically discovers and registers CLI tools as AI-powered agents with persona configuration, enabling any CLI tool to be used as an MCP tool.
Updated 8 months ago (2026-01-24 11:14 UTC)
4
1
MIT
wrapmcp
Shell Access Command Line
SubZtep
A
license
Not graded
quality
C
maintenance
Universal MCP server that wraps any CLI tool, enabling AI assistants to run commands via natural language.
Updated 3 months ago (2026-06-08 02:02 UTC)
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/JoaoBerne/cli-bridge-mcp'

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