Skip to main content
Glama
catid
by catid

claude_mcp

claude_mcp is a local, stdio-only Model Context Protocol server that gives Codex a controlled Claude Opus 5 collaborator through the installed Claude Code CLI and the user's Claude subscription. Opus can inspect an allowed workspace, plan or review work without editing, or take a separately annotated write-capable task that can edit files and run focused tests.

Codex remains the orchestrator and final authority. This bridge does not call the Anthropic API directly, accept an Anthropic API key, scrape a terminal, create commits, or run a resident Claude session.

Collaboration model

The intended workflow is writer–verifier separation:

User
  -> Codex (GPT-5.6-sol, orchestrator)
  -> claude_mcp over MCP stdio
  -> claude -p --model claude-opus-5
  -> controlled access to one validated workspace
  -> structured Opus report + trusted bridge observations
  -> Codex inspects the real diff, reruns important checks, and answers the user

Useful patterns include:

  • Codex implements a substantial change, then starts a fresh Opus review.

  • Opus implements a bounded change, then Codex inspects the actual diff and independently verifies it.

  • A read-only planning session is resumed into implementation in the same canonical workspace.

  • Final independent review normally uses a fresh session rather than resuming the authoring session.

Only one operation may use a workspace at a time. Calls for different workspaces may run concurrently up to the configured global limit. Do not ask both models to write the same workspace concurrently, and skip Opus for trivial mechanical work.

Related MCP server: claude-consult-mcp

Why claude -p

Claude Code's non-interactive print mode provides an argument-vector interface, explicit tools and permission mode, structured JSON output, session IDs, and a normal subprocess lifecycle. That is substantially more auditable than PTY, tmux, terminal-control-sequence, or interactive-TUI scraping. The bridge uses asyncio.create_subprocess_exec with no shell and supplies all task content as JSON on stdin.

Public MCP tools

Version 0.1 exposes exactly three tools:

  • opus_status: free local readiness diagnostics. It runs claude --version and claude auth status, but never a model completion.

  • opus_consult: read-only plan, review, diagnose, or design work using only Read,Glob,Grep. Those tools are explicitly allowed in both CLI arguments and the per-call settings policy. Scrubbed Claude Code sessions use the effective default permission mode directly, avoiding a misleading forced-mode warning. Any observed workspace change is returned as a policy violation.

  • opus_execute: destructive, non-idempotent implement, fix, refactor, test, or document work using Read,Glob,Grep,Edit,Write,Bash. Git is required by default.

Both collaboration tools return the validated Opus report separately from bridge-observed process, session, policy, and workspace metadata. Claude's own files_changed claim is advisory; the bridge's pre/post manifest is independent. Full source diffs are not returned because Codex already has local workspace access and should inspect them directly.

The public tools use reliable turn ceilings: 24 for read-only consultation and 64 for execution. These are maxima, not quotas, so Claude stops earlier when the task is complete. If Claude exhausts a ceiling, the bridge reports error_max_turns as a process failure with the selected ceiling and safe remediation; it does not mislabel the result as a non-Opus fallback or a broken structured-output contract.

Requirements

  • Python 3.11 or newer

  • uv

  • Git

  • macOS, Linux, or WSL2 (not native Windows)

  • Claude Code at or above the configured minimum, currently 2.1.224

  • Native Claude Code sandbox dependencies. On Linux and WSL2 this normally means bubblewrap (bwrap) and socat; macOS uses Seatbelt.

  • A Claude subscription login through Claude Code, or a deliberately supplied CLAUDE_CODE_OAUTH_TOKEN

The bridge fails closed when the native sandbox, required security settings, supported CLI version, or allowed workspace roots are missing. Write-capable execution also requires a successful authentication status probe unless the operator deliberately supplied CLAUDE_CODE_OAUTH_TOKEN; in that case the actual bounded request validates the token. Because some Claude Code releases can report a stale status for a usable stored login, read-only consultation also lets the bounded model request make the final authentication determination and returns its redacted failure reason.

Installation

git clone git@github.com:catid/claude_mcp.git
cd claude_mcp
uv sync --all-groups

Verify the installed entry point without sending a model request by configuring the server in Codex and calling opus_status.

Authentication

Use the normal Claude Code subscription login:

claude auth login
claude auth status

CLAUDE_CODE_OAUTH_TOKEN is preserved if the operator deliberately supplies it. Version 0.1 does not support API-key billing or Bedrock, Vertex, Foundry, custom gateways, profiles, or alternate endpoints.

Before every diagnostic and task process, the bridge copies the parent environment and removes variables that could switch authentication, provider, endpoint, organization, profile, or model. This includes ANTHROPIC_*, CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX, and CLAUDE_CODE_USE_FOUNDRY, plus selected cloud credentials. Interpreter/loader injection variables such as NODE_OPTIONS, PYTHONPATH, and LD_PRELOAD, all GIT_* variables, proxy and custom-CA variables, and CLAUDE_CONFIG_DIR are also removed. It forces CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 so Bash children do not inherit Anthropic or cloud credentials. opus_status reports detected override and dangerous environment names, never values. Ordinary requirements such as HOME, PATH, SHELL, TMPDIR, and locale are retained. Version 0.1 intentionally does not inherit corporate proxies; explicit opt-in proxy support is future work. Current Claude Code may create known zero-byte scrub stubs and append matching .git/info/exclude blocks. The bridge records pre-existing state, removes only new zero-byte stubs, and atomically restores only exact scrub-mode append blocks; pre-existing or model-written content is preserved.

Configuration

Set at least CLAUDE_MCP_ALLOWED_ROOTS in the MCP server environment. Paths are separated with os.pathsep (: on POSIX) and are resolved canonically at server startup.

Variable

Default

Meaning

CLAUDE_MCP_CLAUDE_BINARY

claude

Claude Code executable

CLAUDE_MCP_MODEL

claude-opus-5

Required Opus 5 model

CLAUDE_MCP_ALLOWED_ROOTS

required for task calls

Allowed workspace roots

CLAUDE_MCP_TIMEOUT_SECONDS

7200

Total completion timeout

CLAUDE_MCP_KILL_GRACE_SECONDS

10

SIGTERM grace before SIGKILL

CLAUDE_MCP_MAX_INPUT_CHARS

500000

Maximum serialized task payload

CLAUDE_MCP_MAX_OUTPUT_BYTES

16777216

Maximum Claude stdout

CLAUDE_MCP_MAX_STDERR_BYTES

1048576

Maximum captured stderr

CLAUDE_MCP_MAX_CONCURRENT

2

Concurrent distinct workspaces

CLAUDE_MCP_HEARTBEAT_SECONDS

30

MCP heartbeat interval

CLAUDE_MCP_REQUIRE_GIT_FOR_WRITES

true

Require Git for execution

CLAUDE_MCP_EXECUTE_PERMISSION_MODE

auto

Claude execute permission mode

CLAUDE_MCP_MIN_CLAUDE_VERSION

2.1.224

Minimum supported CLI

CLAUDE_MCP_STATE_DIR

XDG state default

Session registry and lock state

All values are validated. bypassPermissions and plan mode are not accepted as execute modes.

Codex MCP configuration

Add this to ~/.codex/config.toml, using absolute paths:

[mcp_servers.opus_collaborator]
command = "/absolute/path/to/claude_mcp/.venv/bin/claude-mcp"
enabled = true
required = false
startup_timeout_sec = 20
tool_timeout_sec = 7500
default_tools_approval_mode = "approve"

[mcp_servers.opus_collaborator.env]
CLAUDE_MCP_ALLOWED_ROOTS = "/absolute/path/to/repositories"
CLAUDE_MCP_MODEL = "claude-opus-5"
CLAUDE_MCP_REQUIRE_GIT_FOR_WRITES = "true"

Codex clients share this MCP configuration. Run codex mcp list to inspect configured servers, or use /mcp in the Codex terminal UI to confirm that opus_collaborator loaded and advertises exactly three tools. See the current Codex MCP documentation for client configuration and approval-mode details.

Usage patterns

Fresh architecture plan

Call opus_consult without a session ID:

{
  "workspace_path": "/repos/service",
  "task": "Design the new durable job scheduler",
  "mode": "design",
  "focus": "crash recovery, idempotency, and migration",
  "effort": "high"
}

Resume a plan into implementation

Pass the returned session ID to opus_execute for the same canonical workspace:

{
  "workspace_path": "/repos/service",
  "task": "Implement the approved scheduler design",
  "mode": "implement",
  "session_id": "00000000-0000-4000-8000-000000000000",
  "acceptance_criteria": [
    "Existing jobs migrate without data loss",
    "Focused unit and recovery tests pass"
  ]
}

The shown UUID is illustrative; use the actual bridge-returned value.

Codex implementation, fresh Opus review

After Codex writes a substantial change, call opus_consult with mode: "review" and omit session_id. Ask for concrete, evidenced findings. Codex should evaluate each finding against the repository rather than accepting it automatically.

Opus implementation, Codex verification

Delegate a bounded change with opus_execute, then have Codex inspect git diff, the bridge's observed_changed_paths, pre-existing dirty work, and important tests. The bridge never commits or pushes the result.

Use the Opus collaborator proactively for substantial architecture, unfamiliar
repositories, difficult bugs, multi-file changes, algorithms, concurrency,
security-sensitive work, and independent review. Skip it for trivial mechanical
edits. Delegate a complementary role, never let both agents write the workspace
at once, inspect the actual diff after Opus writes, and use a fresh session for
final independent review unless continuity is specifically valuable.

Security model

Workspace paths are hostile input. The bridge expands ~, performs strict canonical resolution, rejects files and missing paths, checks path-aware allowed root containment, detects the Git top level, and rejects symlink, traversal, sibling-prefix, and Git-root escapes. Execution requires Git by default but does not require a clean tree; pre-existing tracked, staged, untracked, deleted, and renamed work is preserved as context.

Every operation acquires, in order, a per-canonical-workspace async lock, a global async semaphore, and a process-safe file lock whose filename is a SHA-256 digest. This prevents duplicate calls for one workspace from consuming global capacity needed by another workspace. Sessions are canonical UUIDs stored in an atomic, mode-0600 registry inside a mode-0700 state directory. A session is bound to one canonical workspace and one Opus model. A plan may resume into execution, but cross- workspace and cross-model resumes fail.

Successful output must prove Opus 5 through a validated authoritative model field or protocol-conformant positive Opus usage that exceeds aggregate Haiku auxiliary usage. Both modelUsage spellings are audited when present; malformed, conflicting, or unexpected model entries fail closed, and no fallback model is configured.

Before and after a call, the bridge independently captures Git HEAD/branch, NUL-safe porcelain status, tracked/staged/untracked/deleted/renamed paths, diff statistics, and a content state fingerprint. The returned snapshot explicitly notes that Git-ignored paths and .git internals are not observed; Codex must inspect those separately when they matter. Non-Git consultations receive a directory manifest with explicit entry and content-hash limits; beyond the hash budget, bounded first/last content samples plus size/mtime/ctime metadata remain observation evidence. Filenames with spaces, tabs, quotes, and newlines are supported. A failed or timed-out process still gets a post-operation observation when possible.

Claude starts in its own process session. Timeout, cancellation, output overflow, or shutdown sends SIGTERM to the full process group, waits the configured grace period, sends SIGKILL if needed, reaps the process, stops heartbeats, cleans owner-only temporary prompt/settings files outside the repository, and releases all locks. The bridge never retries a completion automatically; an ambiguous failure may already have changed files and consumed subscription usage.

Every model call uses --safe-mode, --strict-mcp-config, --no-chrome, no Web tools, a mandatory fail-closed native sandbox, an empty strict network allowlist, no local binding or Unix sockets, secret-path denies, and dangerous Git-command denies. Unsandboxed retry is disabled. Admin-managed Claude Code policy still applies and can affect the effective policy; inspect organization policy when opus_status or Claude Code reports a managed-setting conflict.

Important limitations:

  • Workspace source and submitted task context are sent to Anthropic through the locally authenticated Claude Code process and consume subscription usage.

  • opus_execute is deliberately write-capable and should be approval-gated by the MCP client.

  • Native sandboxing is a strong boundary, not magic. Repository-contained secrets remain sensitive even when common secret paths are denied.

  • Claude Code may persist normal local session transcripts in its own state. The bridge does not copy or expose transcript contents.

  • Network access from Claude tools is denied by default. The model request itself necessarily reaches Anthropic through Claude Code.

  • Common commit, push, reset, clean, restore, rebase, merge, and history-rewrite commands are denied by pattern; HEAD and workspace changes are independently observed. These are layered controls, not a substitute for Codex inspecting the actual diff and trusted manifest.

Troubleshooting

  • CLI too old: opus_status reports the parsed and minimum versions. Run claude update, then verify claude --version.

  • Authentication unavailable: run claude auth login, claude auth status, and a new claude -p call. A nonzero or malformed status fails execution preflight unless the operator deliberately supplied CLAUDE_CODE_OAUTH_TOKEN. Read-only consultation may still attempt its bounded call and reports the redacted Claude authentication error if that request also fails. opus_status reports whether the deliberate-token execution exception is active.

  • API key overrides subscription: unset ANTHROPIC_API_KEY and related provider variables. Task processes strip them regardless; status reports names.

  • Workspace outside allowed roots: add the complete canonical Git root's parent to CLAUDE_MCP_ALLOWED_ROOTS. Allowing only a nested subdirectory is rejected when the Git root would escape.

  • Native sandbox unavailable: install bwrap and socat on Linux/WSL2, or use a supported macOS host. The bridge runs a real namespace-isolation probe, not just an executable check, and never falls back to unsandboxed Bash. Ubuntu 24.04 may additionally require an administrator-provided AppArmor profile for /usr/bin/bwrap with userns, permission; prefer the distribution's purpose-built bwrap profile when available rather than disabling the global user-namespace restriction.

  • Session/workspace mismatch: omit session_id to start fresh in the new workspace. Sessions cannot move between repositories.

  • Timeout after possible edits: do not blindly call again. Inspect status, actual files, Git diff, tests, and the error's pre/post metadata first.

  • Malformed Claude result: update Claude Code if necessary and inspect the workspace. Locally invalid structured output is never trusted and execution is never automatically retried.

  • Corrupt session registry: stop bridge processes, preserve the registry for diagnosis, and move it aside only after deciding that resumable sessions are no longer needed. Corruption is not silently discarded.

Development

The test suite is fully offline. tests/fixtures/fake_claude.py emulates Claude diagnostics, structured completions, mutations, malformed output, limits, timeouts, and process descendants. No test requires Anthropic credentials, network access, subscription usage, or a real Claude invocation.

uv sync --all-groups
uv run ruff check .
uv run ruff format --check .
uv run pytest
uv build

tests/test_protocol.py launches the installed claude-mcp entry point and performs a real stdio MCP initialize/list/call sequence against the fake CLI.

Version 0.1 scope

Version 0.1 uses direct, synchronous access to one validated workspace per call. It intentionally has no PTY/TUI scraping, tmux integration, resident background agent, remote MCP transport, direct Anthropic API path, alternate provider, automatic worktree, automatic Git operation, arbitrary child MCP server, or background job that outlives an MCP call.

Possible later work includes opt-in isolated Git worktrees and richer progress streaming. Those features should preserve the writer–verifier and fail-closed security invariants established here.

Available Tools

3 tools
opus_consultConsult Claude Opus read-onlyA
Read-only

Ask a workspace-aware Opus 5 session to plan, design, diagnose, or independently review without editing files. The 24-turn minimum is a completion ceiling, not a required amount of work; omit max_turns to use the reliable default.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYes
taskYes
focusNo
effortNohigh
contextNo
max_turnsNo
session_idNo
workspace_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/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, so safety is covered. The description adds genuinely new behavioral context the annotations cannot convey: the no-edit guarantee for the consultation, and the semantics of the 24-turn minimum as a ceiling rather than a workload, plus the advice to omit max_turns for the reliable default. It stops short of disclosing cost, latency, or session reuse behavior.

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

Conciseness4/5

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

Two sentences, no filler, with the capability statement front-loaded and the parameter caveat second. Dense and earn-your-place, though the max_turns clause packs two ideas (ceiling semantics plus default advice) into one semicolon splice.

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

Completeness3/5

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

The read-only safety profile is carried by annotations and the output schema means return values need not be described, so the core job is covered. But with 8 parameters at 0% schema coverage, an agent still has no guidance on mode/effort/focus/context/session_id semantics, which is a real gap for a tool this configurable.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the full burden. It explains max_turns well (24-turn minimum is a ceiling, omit to use the default), but mode, task, focus, effort, context, session_id and workspace_path are never addressed, leaving most of the 8 parameters undocumented anywhere.

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?

Names a specific verb set (plan, design, diagnose, review) tied to a named resource (workspace-aware Opus 5 session) and pins the scope with 'without editing files'. That scope contrasts cleanly with the sibling opus_execute, so an agent can separate them without opening either schema.

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 usage through the enumerated modes and the 'without editing files' constraint, which hints that opus_execute is the alternative when edits are needed. However, it never states when to pick this tool over opus_execute or opus_status explicitly, and gives no prerequisites or exclusions beyond the read-only framing.

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

opus_executeLet Claude Opus modify a workspaceB
Destructive

Delegate bounded implementation, fixes, refactoring, tests, or documentation to Opus 5 with direct write access; inspect the returned trusted workspace manifest. The 64-turn minimum reduces accidental early truncation of editing runs.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeYes
taskYes
effortNoxhigh
contextNo
max_turnsNo
session_idNo
workspace_pathYes
acceptance_criteriaNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds useful context – direct write access, a 'trusted workspace manifest' being returned, and the rationale for the 64-turn minimum (avoiding early truncation) – but omits permissions, reversibility, and rate/limit behavior.

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

Conciseness4/5

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

Two dense sentences with the primary action front-loaded and the constraint rationale second. No filler, though the second sentence's turn-minimum note is a fairly narrow detail to spend the tail on.

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?

An output schema exists, so return values need not be explained, and the manifest mention is a bonus. Still, for a destructive 8-param write tool with zero schema descriptions, key semantics (workspace_path meaning, session_id reuse, acceptance criteria behavior) are absent.

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

Parameters3/5

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

Schema description coverage is 0% across 8 parameters, so most fields (task, context, effort, workspace_path, session_id, acceptance_criteria) are undocumented. The description only partially compensates by matching the mode values and referencing the 64-turn minimum for max_turns.

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

Purpose4/5

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

The description states a specific verb+resource: delegating bounded coding tasks to 'Opus 5 with direct write access'. The phrase 'direct write access' implicitly distinguishes it from a read-only consult sibling, but no sibling is named outright.

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?

It enumerates the task classes it handles (implementation, fixes, refactoring, tests, documentation), which maps to the mode enum and implies usage. However, it never states when to prefer this over opus_consult or opus_status, nor any exclusions or prerequisites.

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

opus_statusCheck Opus collaborator readinessA
Read-onlyIdempotent

Check Claude Code version, subscription authentication, sandbox support, bridge configuration, and an optional workspace without invoking a model completion.

ParametersJSON Schema
NameRequiredDescriptionDefault
workspace_pathNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral trait beyond them: this performs its checks without triggering a model completion, i.e. no token spend or model side effects — key information for deciding to call it first.

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

Conciseness4/5

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

A single front-loaded sentence with no filler; the enumerated checklist is dense but each item earns its place by naming a distinct check. Slightly list-heavy, but nothing is wasted.

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?

An output schema exists, so return values need no explanation, and annotations cover safety semantics. The description enumerates everything inspected, leaving only minor gaps such as how to interpret partial failures or auth prerequisites — acceptable for a status probe.

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?

One parameter (workspace_path) with 0% schema description coverage, so the description carries the burden. It partially compensates by calling the workspace "optional," matching the default of "" and zero required params, but adds no format or expected-value guidance for the path.

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?

States a concrete verb ("Check") over a specific set of readiness facets — Claude Code version, subscription auth, sandbox support, bridge config, workspace — which tells an agent exactly what this diagnostic reports. The trailing clause "without invoking a model completion" implicitly separates it from opus_consult/opus_execute, though no sibling is named.

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 phrase "without invoking a model completion" hints at the natural usage (a cheap preflight before consult/execute), but the description never states when to call this versus the siblings or what a failed check implies. Usage is implied rather than prescribed.

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

Tool Schema Changelog

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

  1. 3 tool updatesv0.1.0
    • First observedopus_consult
    • First observedopus_execute
    • First observedopus_status

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation4/5

The three tools map onto a clear read-only / non-editing / editing split: opus_status inspects configuration, opus_consult plans and reviews without writes, and opus_execute delegates with write access. opus_consult and opus_execute could still be momentarily confused since they both invoke a model session, but the descriptions explicitly distinguish edit vs. no-edit behavior.

Naming Consistency5/5

All three tools follow the same opus_<verb> pattern, with concise verbs (status, consult, execute) that consistently describe the action. No mixing of conventions or casing.

Tool Count4/5

Three tools is minimal but each serves a distinct role in the delegate-to-Opus workflow, so nothing is redundant. It sits at the thin edge of the acceptable range, with no lifecycle tooling (cancel, resume, list sessions) to round it out.

Completeness3/5

Configuration check, planning/review, and execution are covered, but the surface has notable gaps: no way to list or resume sessions, cancel or abort a long run, or retrieve results of a previously delegated task. Agents must work around these lifecycle omissions.

Related MCP Connectors

Related MCP Servers