What can you do with this server?

This server lets an MCP client such as Codex create and manage CodeBuddy Code ACP sessions, send prompts, handle permission requests, cancel turns, close sessions, and switch models. * Create isolated CodeBuddy bridge sessions, locally or over SSH, with configurable working directory, model, launch/permission/approval settings, environment, auth method, codebuddy command/args, and startup timeout; sessions can be resumed with resume_session_id. * Prompt a bound CodeBuddy session and get completed turn results or permission requests; large results can be externalized to a temp file. * Respond to permission requests using request_id and option_id to continue the same turn. * Switch the model for an existing bridge session over ACP between turns. * Cancel an active CodeBuddy turn while keeping the session available. * Close and remove bridge sessions, cleaning up local processes, SSH channels, and temporary output files.

How do I use codex-codebuddy-mcp?

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., "@codex-codebuddy-mcp Start a CodeBuddy session in my repo and ask it to fix the failing tests" 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.

codex-codebuddy-mcp

by black-94

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

codex-codebuddy-mcp

A minimal Python MCP server that lets Codex control CodeBuddy Code through its Agent Client Protocol (ACP) interface.

Features

Session creation starts CodeBuddy and establishes the ACP session.
One CodeBuddy process and ACP session per bridge session.
Local launch and remote launch over OpenSSH stdio.
Explicit bridge session IDs with MCP client ownership checks.
Per-session model switching through ACP.
At most two active CodeBuddy turns by default across the MCP server.
Explicit permission approval modes: MCP elicitation or compatible two-step flow.
Cancellation and deterministic child-process cleanup.

Related MCP server: cursor-agent-bridge

Requirements

Python 3.11 or newer
uv
CodeBuddy Code with ACP support (codebuddy --acp)
OpenSSH when using remote launch

Install and run

uv sync
uv run codex-codebuddy-mcp

The bridge has built-in defaults. In a source checkout, the repository-level config.yaml can override them:

max_read: 1048576 # 1 MiB, one ACP stdout/stderr line
max_output: 65536 # 64 KiB, one MCP result
max_concurrency: 2 # simultaneous active prompt turns
approval_mode: elicitation
timeout_seconds: 900 # default prompt/permission-turn timeout
startup_timeout_seconds: 60 # ACP initialize/session startup timeout
turn_cancel_timeout_seconds: 5 # wait for ACP turn cancellation
local_process_terminate_timeout_seconds: 5 # wait before local SIGKILL
remote_ssh_cleanup_timeout_seconds: 10 # wait for remote cleanup SSH command
stdout_overflow_retry_tolerance: 1 # oversized stdout turns tolerated before termination
stderr_tail_buffer_size: 80 # stderr lines retained for diagnostics

Installed wheels use the built-in defaults unless CODEX_CODEBUDDY_MCP_CONFIG names a YAML file. The KB, MB, and GB suffixes are accepted as binary multiples for backward compatibility; max_concurrency must be a unitless integer. The values can be overridden for an individual session by passing max_read and/or max_output to create_codebuddy_session. Timeout values are seconds. stdout_overflow_retry_tolerance is the number of oversized stdout responses that may be discarded while keeping the process available; 0 terminates the process on the first overflow. stderr_tail_buffer_size is measured in stderr lines. The prompt tools' timeout_seconds and the session creation tool's startup_timeout_seconds also accept per-call overrides. max_concurrency applies globally to all bridge sessions and is loaded when the MCP server starts.

Example Codex MCP configuration:

[mcp_servers.codebuddy]
command = "uv"
args = [
  "run",
  "--project",
  "/absolute/path/to/codex-codebuddy-mcp",
  "codex-codebuddy-mcp",
]

The MCP server writes protocol data to stdout and diagnostics to stderr.

Tools

`create_codebuddy_session`

Starts CodeBuddy, establishes the ACP session, and returns both a bridge_session_id and the codebuddy_session_id, along with the ACP-reported model_id and model_name. The model fields are returned when the session is created, not repeated on every prompt result. The bridge does not maintain a model allowlist. If CodeBuddy does not report model metadata, those two fields are null, rather than echoing an unverified model argument. If startup or session recovery fails, this call returns an error and does not leave a usable bridge session behind.

cwd and model_id are required. cwd sets the working directory for the CodeBuddy session. If it is present but empty or contains only whitespace, the bridge asks the user to enter a working directory through MCP elicitation. Clients without elicitation support receive an error that asks the caller to retry with a non-empty cwd. model_id must be non-empty and is passed to CodeBuddy as --model; do not repeat --model in codebuddy_args.

Local example arguments:

{
  "cwd": "/path/to/project",
  "model_id": "deepseek-v4.1-flash",
  "launch_mode": "local",
  "permission_mode": "auto",
  "approval_mode": "elicitation",
  "max_read": 4194304,
  "max_output": 65536
}

SSH example arguments:

{
  "cwd": "/home/dev/project",
  "model_id": "deepseek-v4.1-flash",
  "launch_mode": "ssh",
  "ssh_host": "dev-box",
  "ssh_args": ["-T"],
  "codebuddy_command": "/usr/local/bin/codebuddy"
}

SSH authentication uses the system ssh command, SSH config, and agent. Passwords are not accepted by this bridge. Values supplied through env are forwarded to CodeBuddy but should be treated as MCP tool input; prefer parent-process or remote host configuration for secrets.

approval_mode controls the bridge-to-MCP permission path. elicitation is the default and requires the MCP client to support elicitation; failures are returned as errors. compatible explicitly uses the two-step permission_required plus respond_codebuddy_permission flow. It does not silently fall back between modes.

By default the bridge reuses the CodeBuddy login already present on the target machine. If no login is available it returns an authentication-required error. auth_method_id can explicitly request external, internal, iOA, or selfhosted authentication; CodeBuddy may open or wait for its normal login flow, so use this only when interactive authentication is intended.

permission_mode defaults to auto and is passed to CodeBuddy as --permission-mode auto. The supported values are acceptEdits, bypassPermissions, default, plan, dontAsk, and auto. The bridge allows max_concurrency active turns at the same time across sessions; turns in one ACP session remain serialized. max_read controls the asyncio subprocess stream limit used for reading each ACP stdout/stderr line. Its YAML default is 1048576 bytes (1 MiB). Increase it when a single ACP JSON line can be larger; it must be a positive integer. On the first stdout overrun, the bridge discards that response, cancels the current turn, and keeps the process available so the caller can request a compressed answer. Changing max_read requires creating a new bridge session. A successful turn clears the overrun count; once stdout_overflow_retry_tolerance is exceeded, the process is terminated. Oversized stderr lines are discarded without stopping the session. max_output controls the MCP result threshold and defaults to 65536 bytes (64 KiB).

The concurrency limit applies to active session/prompt turns, including turns waiting for a permission decision. It does not limit the number of started CodeBuddy processes. A third session may be created and remain ready, but its prompt waits for a turn slot and fails when its timeout expires. In compatible approval mode, an unanswered permission request is cancelled after the calling tool's timeout_seconds, which releases its global turn slot. Operations within one bridge session are serialized by that session's lock.

The registry is in memory. Restarting the MCP server loses bridge session IDs, owner bindings, locks, pending permissions, in-flight buffers, and process handles. Persist the returned codebuddy_session_id if recovery is needed; a new bridge session can pass it as resume_session_id. The bridge cannot discover old CodeBuddy sessions automatically.

`switch_codebuddy_model`

Switches the model for an existing bridge session between turns:

{
  "bridge_session_id": "...",
  "model_id": "deepseek-v4.1-flash"
}

The bridge sends ACP session/set_model with the bound CodeBuddy session. CodeBuddy must acknowledge the change; ACP errors are returned directly and do not change the bridge's recorded model. A successful call returns model_id and model_name once, together with both session IDs. Switching while a prompt or permission request is active is rejected; finish or cancel that turn first.

`prompt_codebuddy`

Sends a text prompt to the already-started CodeBuddy session. A completed turn returns the final text, stop reason, tool summaries, and CodeBuddy session ID.

max_output controls the maximum UTF-8 byte size of every prompt result and defaults to 65536. When the serialized result is larger, the bridge writes the complete JSON result to a 0600 file in the local temporary directory and returns output_path, output_bytes, and text_available_in_file=true instead of embedding the large text in the MCP response. Permission metadata remains in the compact response so the caller can continue the same turn; the caller can read the complete result from that path with its local file tools. MCP/JSON-RPC does not define one universal maximum, but the calling Codex or harness may enforce a per-message limit, so a conservative max_output is useful for long reports. The bridge removes tracked output files when their bridge session closes or the server shuts down.

For reports that exceed the file threshold, the same bridge session remains available for follow-up prompts and additional sections.

With approval_mode="compatible", the tool returns:

{
  "status": "permission_required",
  "permission": {
    "request_id": "...",
    "tool_name": "Bash",
    "raw_input": {"command": "..."},
    "options": [
      {"kind": "allow", "name": "Allow", "optionId": "allow"},
      {"kind": "reject", "name": "Deny", "optionId": "deny"}
    ]
  }
}

`respond_codebuddy_permission`

Pass the exact request_id and one of the returned optionId values. The call continues the same CodeBuddy turn and may complete or return another permission request. It also accepts max_output with the same file externalization behavior.

`cancel_codebuddy_turn` and `close_codebuddy_session`

Completing a prompt does not close CodeBuddy. Cancellation keeps the CodeBuddy process available. Closing cancels active work, terminates the local process or SSH channel, and removes the bridge session. On SSH, the bridge records a unique remote PID file and performs a second SSH cleanup command that terminates that process group. The remote shell uses set -m, starts CodeBuddy as a monitored job, and waits for it so the SSH stdio channel stays connected for ACP responses. This handles CodeBuddy processes that outlive the SSH channel; abrupt network loss or a remote process that ignores termination cannot be guaranteed by the local client.

Tests

Run the default suite, including a real installed CodeBuddy ACP handshake:

uv run pytest

The handshake starts the actual codebuddy-code binary, validates ACP initialization and login state handling, and creates an ACP session when the installed CLI is already authenticated. It does not send a model prompt or consume model quota. A second real startup test verifies that the default permission mode passed to CodeBuddy is auto, rather than plan. These tests skip only when codebuddy is not installed.

An opt-in end-to-end model test is also provided. It sends a real prompt and may consume quota:

RUN_CODEBUDDY_MODEL_TEST=1 uv run pytest -m model

The real permission-forwarding test is parameterized over both supported forwarding modes. It prompts CodeBuddy to request approval for a harmless printf through Bash, verifies either the compatible two-step response or MCP elicitation, selects an allow option, and checks that the same turn completes. It is separately opt-in because each mode sends a model prompt and executes the approved command:

RUN_CODEBUDDY_PERMISSION_TEST=1 uv run pytest \
  tests/test_server.py::test_real_codebuddy_permission_request_is_forwarded

Run static checks:

uv run ruff check .

Available Tools

5 tools

cancel_codebuddy_turnA

Cancel the active turn while keeping the CodeBuddy session available.

ParametersJSON Schema

Name	Required	Description	Default
`bridge_session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/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 burden of behavioral disclosure. It usefully reveals that the session remains available after cancellation. However, it does not mention what happens if there is no active turn, whether cancellation is immediate or asynchronous, or other 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?

One tight sentence, front-loaded with the action and followed by the key qualifier about session availability. Every word earns its place; no filler or redundancy.

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?

This is a simple one-parameter tool with an output schema, which reduces the need to document return values. However, the lack of parameter semantics and any cancellation edge-case behavior leaves the description adequate but not fully complete.

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

Parameters1/5

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

Schema description coverage is 0%, and the description never mentions bridge_session_id, its purpose, or how to obtain it. The description adds no parameter meaning beyond the raw schema, so the agent gets no guidance on supplying this required argument.

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 states a specific action ('Cancel'), a clear resource ('the active turn'), and an important qualifier that distinguishes this tool from closing the session. It is immediately clear what the tool does and how it differs from close_codebuddy_session.

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 phrase 'active turn' establishes the intended context, and 'keeping the CodeBuddy session available' implies this is not the tool to use when ending the session entirely. It provides clear context but does not explicitly name alternatives or when-not-to-use conditions.

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

close_codebuddy_sessionC

Close and remove a CodeBuddy bridge session.

ParametersJSON Schema

Name	Required	Description	Default
`bridge_session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.7/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 the full burden. 'Close and remove' implies destructive/irreversible behavior, but the description doesn't disclose whether it terminates active turns, requires permissions, or has side effects on related sessions.

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?

The description is a single concise sentence that front-loads the action. It earns its place, though it could add a bit more context without becoming bloated.

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

Completeness2/5

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

For a destructive lifecycle tool with no annotations and no parameter documentation, the description is too thin. It doesn't cover prerequisites, side effects, or relationship to sibling tools, leaving an agent to guess when and how to invoke it.

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%, and the description adds no meaning beyond the parameter name 'bridge_session_id'. The description doesn't explain what a bridge session ID is, how to obtain it, or any format expectations.

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 ('Close and remove') and resource ('CodeBuddy bridge session'), which clearly identifies the tool's action. It distinguishes from siblings like create_codebuddy_session and prompt_codebuddy, though it doesn't explicitly name them.

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?

No guidance on when to use this tool versus alternatives. The sibling tools suggest a lifecycle (create, prompt, respond, cancel), but the description doesn't explain when closing is appropriate or what happens to pending turns.

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

create_codebuddy_sessionA

Configure an isolated CodeBuddy ACP session without starting its process.

Use launch_mode="ssh" to run CodeBuddy remotely over an existing OpenSSH configuration. The CodeBuddy process starts lazily on the first prompt.

ParametersJSON Schema

Name	Required	Default
`cwd`	Yes
`env`	No
`ssh_args`	No
`ssh_host`	No
`launch_mode`	No	local
`ssh_command`	No	ssh
`auth_method_id`	No
`codebuddy_args`	No
`codebuddy_command`	No	codebuddy
`resume_session_id`	No
`startup_timeout_seconds`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It discloses that the process is not started and starts lazily on the first prompt, which is useful. However, it does not mention side effects, persistence, or what the return value is (though an output schema exists), leaving gaps in behavior disclosure.

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 three sentences long, front-loads the primary purpose, and includes a specific usage tip for ssh mode. There is no redundant wording, and every sentence adds value.

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

Completeness2/5

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

For a tool with 11 parameters and no schema descriptions, this description is far too sparse. It does not explain the required cwd parameter, the meaning of most parameters, or how this tool fits into the session lifecycle (e.g., that it must be called before prompt_codebuddy). The output schema exists but the description does not guide the agent on constructing a valid call.

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?

With schema description coverage at 0%, the description must explain parameters, but it only touches on launch_mode, providing context for the 'ssh' value. The other 10 parameters (cwd, env, ssh_args, ssh_host, etc.) are left unexplained, so the agent has no semantic guidance for them.

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

Purpose5/5

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

The description clearly states it configures an isolated CodeBuddy ACP session without starting the process, a distinct action from siblings (close, prompt, respond, cancel). The verb 'configure' and resource 'session' are specific, and the clarification about not starting the process adds precision.

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 guidance for the ssh launch mode, telling the agent to use launch_mode='ssh' for remote execution. However, it does not explicitly state when to use this tool versus its alternatives, though its role as a creation/configuration step is implied by the name and sibling lifecycle actions.

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

prompt_codebuddyA

Send a text prompt to the bound CodeBuddy session.

This lazily starts CodeBuddy. The result either completes the turn or returns a permission request for respond_codebuddy_permission.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes
`timeout_seconds`	No
`bridge_session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses two important behaviors: 'lazily starts CodeBuddy' and the result either completes the turn or returns a permission request. It does not mention timeout behavior or cancellation, but it does reveal the key side effect and the permission flow.

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 short, front-loaded sentences with no filler. The first states the action, and the second adds the lazy-start and permission-request behaviors, both of which earn their 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?

The description covers the main call flow and output shape, especially since an output schema exists. However, it omits timeout_seconds semantics and does not fully explain what a 'bound' session requires or how to obtain one, leaving moderate gaps for a tool without annotations.

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 must compensate for the parameters, but it only implicitly clarifies 'prompt' as a text prompt and 'bridge_session_id' as the bound CodeBuddy session. The 'timeout_seconds' parameter is entirely undocumented in the description, leaving a meaningful gap.

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 a specific verb and resource: 'Send a text prompt to the bound CodeBuddy session.' This distinguishes it from the sibling tools, which create, close, cancel, or respond to permission requests rather than send prompts.

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 clear usage context: it sends a prompt to an existing bound session, may lazily start CodeBuddy, and can return a permission request that routes to respond_codebuddy_permission. It does not explicitly state when not to use it or compare alternatives, but the context is sufficient for selecting this tool.

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

respond_codebuddy_permissionC

Resolve a pending CodeBuddy permission request and continue the turn.

ParametersJSON Schema

Name	Required	Description	Default
`option_id`	Yes
`request_id`	Yes
`timeout_seconds`	No
`bridge_session_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.8/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 the full burden. It discloses that the turn continues after resolution, but it does not explain blocking behavior, timeout semantics, authentication needs, or what happens on invalid or expired requests. For a state-changing tool, this is a significant gap.

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?

The description is a single front-loaded sentence with no wasted words. It states the action and the result efficiently, though its brevity contributes to the lack of semantic detail penalized in other dimensions.

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

Completeness2/5

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

For a tool with four parameters, zero schema descriptions, and no annotations, the description is too thin to support correct invocation. Even though an output schema exists, the description omits essential workflow context such as how to obtain the request_id and option_id and what timeout_seconds controls.

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

Parameters1/5

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

Schema description coverage is 0%, and the description explains none of the four parameters. It does not clarify what option_id represents, where request_id comes from, how timeout_seconds is used, or what bridge_session_id refers to. The agent is left to guess the roles of required fields.

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 uses a specific verb ('Resolve') and identifies a precise resource ('pending CodeBuddy permission request') plus the outcome ('continue the turn'). It is clearly distinguishable from siblings like cancel_codebuddy_turn and prompt_codebuddy, though it does not explicitly name them.

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 'pending permission request' implies a clear trigger condition, but the description gives no explicit guidance on when to choose this tool over cancel_codebuddy_turn or prompt_codebuddy. Usage context is implied rather than spelled out.

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.

5 tool updatesv0.1.0Sep 17, 2026
- First observedcancel_codebuddy_turn
- First observedclose_codebuddy_session
- First observedcreate_codebuddy_session
- First observedprompt_codebuddy
- First observedrespond_codebuddy_permission

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

A3.7/5.0

Scored 2026-09-17 20:16 across 5 tools

Disambiguation5/5

Each tool targets a clearly distinct action: session creation, session teardown, sending a prompt, resolving a permission request, and cancelling a turn. There is no overlap or ambiguity between these operations.

Naming Consistency5/5

All tool names follow a predictable snake_case verb_noun pattern: create_, close_, prompt_, respond_, cancel_. The shared 'codebuddy' anchor makes the set easy to scan and understand.

Tool Count5/5

Five tools cover the full interaction lifecycle without redundancy. Each tool corresponds to a distinct phase of using a CodeBuddy session, so the count is well-scoped for the server's purpose.

Completeness5/5

The tool surface covers the complete workflow: create a session, prompt it, handle permission requests, cancel turns, and close the session. There are no obvious dead ends or missing operations needed for the advertised functionality.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
28
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
aethereum
io.github.br9704
The team layer for AI coding agents: shared contracts, collision alerts, E2EE sessions.
Coding Agents Blockchain Version Control
2
Railway MCPOAuth
com.railway
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Cloud Platforms Developer Tools CI/CD & DevOps
2

Related MCP Servers

pokeclaw
Coding Agents Code Execution Command Line
madebydia
A
license
Not graded
quality
D
maintenance
Enables MCP clients to spawn and control Codex CLI and Claude Code sessions on the host machine, with session management and filesystem access.
Updated 3 months ago (2026-06-08 12:59 UTC)
4
MIT
cursor-agent-bridge
Coding Agents Developer Tools Code Execution
cybas
A
license
Not graded
quality
B
maintenance
Enables MCP clients like Claude Code to delegate coding tasks to the local Cursor Agent CLI, with persistent per-workspace sessions that resume across calls.
Updated a month ago (2026-08-11 08:15 UTC)
12 npm
MIT
Claude Code Bridge
Coding Agents Autonomous Agents Developer Tools
Cyruskraad
A
license
Not graded
quality
A
maintenance
Lets Codex delegate coding and repository work to an installed Claude Code CLI with permission-aware inspect/write access, model and effort selection, resumable and cloud-attached sessions, and durable synchronous or asynchronous jobs.
Updated 23 days ago (2026-08-27 20:02 UTC)
MIT
cross_yapper
Autonomous Agents Communication Developer Tools
adrianvalentim
F
license
Not graded
quality
B
maintenance
Enables Codex agents to discover projects, read existing conversation histories, and send messages to specific conversations across trusted machines using a lightweight local bridge over SSH.
Updated 11 days ago (2026-09-08 15:31 UTC)
-

codex-codebuddy-mcp

Features

Requirements

Install and run

Tools

create_codebuddy_session

switch_codebuddy_model

prompt_codebuddy

respond_codebuddy_permission

cancel_codebuddy_turn and close_codebuddy_session

Tests

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`create_codebuddy_session`

`switch_codebuddy_model`

`prompt_codebuddy`

`respond_codebuddy_permission`

`cancel_codebuddy_turn` and `close_codebuddy_session`