What can you do with this server?

Delegate coding tasks to your locally installed MiniMax Code CLI (mcode) and manage the sessions it creates. * Run a task — mcode starts a new session (blocks until it settles, returns only the final result + stats, prefixed [session: ]). Takes prompt (required) plus optional cwd, model, permission, mode, transport, thinking_effort, timeout_ms. * Resume a session — mcode_reply sends a follow-up turn to a finished, cancelled, or timed-out session (survives server restarts). * Control a running turn — mcode_send aborts or steers an in-flight ACP run (follow_up is rejected; acp transport only). * Discover sessions — mcode_running (turns executing now) and mcode_sessions (all sessions started via this server, newest first). * Pick a model — mcode_models lists what the installation reports (optional search filter); starts no task. * Inspect a conversation — mcode_history reads the native transcript read-only (no prompting, no lock) with limit, max_chars, include_tools, and a cursor for paging. * Caution — mcode/mcode_reply/mcode_send are marked destructive and non-idempotent; with the default permission: full, mcode edits files and runs shell commands as your user inside cwd without asking. * Gap vs README — the README also advertises mcode_context, mcode_profiles, and per-profile tool sets (e.g. mcode_work), none of which appear in this schema.

How do I use mcode-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., "@mcode-mcp refactor the auth module in /repo to use async/await" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcode-mcp

by minmax

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

mcode-mcp

MCP server that delegates coding tasks to your locally installed MiniMax Code CLI (mcode, npm package @minimax-ai/code).

It wraps the real mcode binary instead of bundling its own copy of the agent, so every call inherits your MiniMax login, models and ~/.minimax config.

This is not the MiniMax M3 API provider in Pi, and not mmx-cli.

Sibling of pi-cli-mcp, qwen-cli-mcp, kimi-cli-mcp and grok-code-mcp — same architecture, same principles, MiniMax Code behind the wheel. Design: SPEC.md. Behaviour: CHANGELOG.md.

Verified against MiniMax Code 0.5.9.

Install

npx -y mcode-mcp         # no install
npm install -g mcode-mcp # or global

Requires Node ≥ 22 and MiniMax Code installed with its own installer.

The installer keeps MiniMax Code in ~/.minimax-code (or $MCODE_INSTALL_DIR) and exposes a launcher, <prefix>/bin/mcode, that follows the current release and pins a Node matching MiniMax Code's native SQLite ABI. The adapter finds and spawns that launcher by itself; there is nothing to configure.

Resolution order: MCODE_MCP_BIN → <prefix>/bin/mcode → mcode on PATH. Set MCODE_MCP_BIN only to use a different mcode. Never point it into <prefix>/releases/<version>/…: that path changes on every self-update.

Claude Code

claude mcp add-json mcode -s user '{
  "type": "stdio",
  "command": "npx",
  "args": ["-y", "mcode-mcp"],
  "timeout": 3600000
}'

Any other MCP client

{
  "mcpServers": {
    "mcode": { "command": "npx", "args": ["-y", "mcode-mcp"] }
  }
}

Keep the server name short (mcode): it becomes part of the tool names your model sees.

Related MCP server: Codex to OpenCode MCP Server

Tools

Tool	Purpose
`mcode`	Start a session. Returns `[session: <id>]`, `[session-key: mcode:<id>]`, the result, and stats.
`mcode_<profile>`, `mcode_<profile>_reply`, …	The same tools, pinned to a named account. One set per profile, so several accounts are live at once.
`mcode_reply`	Continue a finished or interrupted session — including one killed by a timeout.
`mcode_models`	List the models this installation can actually run, from the session catalog.
`mcode_context`	Read a session's context window, budget and per-component breakdown.
`mcode_send`	Deliver into a turn executing right now (`abort` / `steer`). ACP only.
`mcode_running`	List turns executing right now that `mcode_send` can reach.
`mcode_sessions`	List known sessions started through this server, newest first.
`mcode_history`	Read-only native transcript (`messages.jsonl`). Does not prompt the agent.
`mcode_profiles`	List the auth profiles on this machine and which one is the default.

`mcode`

Argument	Notes
`prompt`	Required. Must be self-contained — mcode cannot see your conversation.
`cwd`	Absolute path; defaults to this server's cwd. Passed as `--cwd` / ACP `cwd`.
`model`	`provider/model`, optionally `provider/model#variant`. On ACP the value is resolved against the session catalog automatically.
`permission`	`smart` \| `full` \| `off`. Exec `--permission`. ACP maps `smart`→`auto`, `full`→`bypassPermissions`. `off` is exec-only. Server default is `full`.
`mode`	ACP-only session mode: `default` \| `plan`.
`thinking_effort`	ACP-only `session/set_config_option` id=`thinkingEffort`. Values are model-dependent.
`context_window`	Context window in tokens (M3 / M3.1 advertise `512000` and `1000000`; the latter is marked `higher_usage`). See the note below.
`transport`	`acp` (default) or `print`. Usually omit.
`timeout_ms`	Wall clock for this run. Off unless you set it. Print also forwards `--timeout <N>ms`.

Profiles

The account is the tool's name, not an argument. There is no profile parameter. For a profile called work you get mcode_work, mcode_work_reply, mcode_work_models, mcode_work_context and mcode_work_history; the untargeted mcode and friends stay on whatever the launch parameter selected.

mcode_work({ prompt: "…" })        // this task runs on the `work` account
mcode_personal({ prompt: "…" })    // and this one on `personal`, at the same time

That is what lets several accounts be live in one agent at once: they are separate tools, so a model chooses the account by choosing what to call, and the choice survives being retried, forwarded, or read back out of a transcript. An argument cannot do that — one tool is one account per call, and every call site has to carry the choice.

You will not see any of it unless a profile is in play. The per-profile tools and mcode_profiles appear only when the server has been pointed at a profile (MCODE_MCP_PROFILE / MINIMAX_PROFILE) or one exists on disk. On a machine with neither — which includes everyone on a MiniMax Code that has never heard of a profile — the tool list and every argument schema are exactly what they were in 0.2.0, so there is nothing new to be puzzled by. Signing a profile in makes the tools appear without restarting the server.

Asking for an account that does not exist is an unknown tool, not a run: a name only resolves to a real profile, so there is no path from a typo to a directory.

A profile is a separate MiniMax account with its own data directory — ~/.minimax for the default one, ~/.minimax-<name> for a named one — holding its own credentials, sessions and settings. It is mcode's own feature; this server passes it through with the same --profile <name> flag and resolves its own paths with the same arithmetic, so a run and the transcript read back afterwards can never disagree about which account they belong to.

mcode_profiles()                    // what exists, what is signed in, and the tools that reach each
mcode_work({ prompt: "…" })         // a task on the `work` account

Names must be 1–64 letters, numbers, dots, underscores or hyphens, starting and ending with a letter or number — a name becomes a directory segment under your home, so ../../etc is refused rather than sanitised.

A profile only gets tools if its tool names are usable: they must be unique and made of letters, numbers, _ and - (so no dots, and a name short enough for 64 characters). A profile called reply would collide with mcode_reply, and work_reply next to work would both claim mcode_work_reply; such a profile gets no tools rather than a tool that could run on the wrong account. It is still listed by mcode_profiles and can still be the server's default.

A profile argument is refused (when a profile is in play) rather than ignored: the account is the tool you called, and a caller that still passes the old argument would otherwise be billed to the default account without a word.

The default account has a tool when the server default is elsewhere. With MCODE_MCP_PROFILE=work, plain mcode runs on work, so the implicit account is reached as mcode_default, mcode_default_reply, and so on.

The server's default is MCODE_MCP_PROFILE, falling back to mcode's own MINIMAX_PROFILE if that is set and ours is not. A malformed value makes the server refuse to start instead of quietly falling back to the default account — running every task on the wrong account is worse than not running. The chosen profile is pinned into the environment of every mcode this server spawns, so an inherited MINIMAX_PROFILE can never send a run to an account other than the one this server reads from.

Two things to know before using one:

A profile must have credentials first. Signing in is interactive and has no headless equivalent, so do it in a terminal with mcode login --profile <name> (or give it a Token Plan key with mcode provider set-minimax-key --profile <name>). Until then mcode_profiles reports signed out or not created, and a run against it cannot authenticate.
MINIMAX_DATA_DIR / MAVIS_DATA_DIR outranks the profile, exactly as it does in mcode: with either set, every profile resolves to that one directory and they stop being separate accounts. mcode_profiles says so when it detects this. MCODE_MCP_MINIMAX_CONFIG is likewise a single path with no profile indirection, and combining it with a named profile is refused: the run would read the profile's own config.yaml, so the edit would succeed and the context window would not move.

An answer from a non-default profile carries [profile: <name>] in its prefix.

A session keeps the profile it started under, and it cannot be changed by a reply — a session id only names a conversation inside one account, so mcode_reply refuses a different profile rather than asking another account to load an id it never issued. mcode_history and mcode_context may read a session from another account, since those are reads; mcode_history reports the profile it read, and a cursor issued for one profile is refused in another, because a byte offset means nothing across accounts. Note that a context_window edit is a real write to that profile's config.yaml.

A profile name that has no directory is refused before anything starts, rather than letting mcode create an empty account for it.

`context_window`

mcode exposes no flag and no ACP config option for the context window: the only way to reach it is the minimaxModelContextLimits entry in your own ~/.minimax/config.yaml.

It works on print and is refused on acp. On print this server writes a private copy of the config and passes --config, and the window verifiably takes effect. On acp it does not: MiniMax Code builds a session selection from the advertised model value, and that selection carries a provider, model and variant but no context limit, so the turn falls back to the window in your config however this server writes that file. Measured on 0.5.8 — asking for 512000 with an explicit model, the session still reported 1,000,000. Since mcode acp has no --config, and the config path cannot be redirected without also moving the data directory, there is no way to make it work on that transport. Asking for it there is an error that says so, and nothing is written.

Set MCODE_MCP_ALLOW_ACP_CONTEXT_WINDOW=1 to edit the shared entry anyway: the server holds it for the whole run under a cross-process lock — which is judged stale by whether its owner process is alive, never by age — and rolls it back compare-and-swap, so a change by the TUI or by you wins, another instance's start will not disturb a run in flight, and a crash is repaired on the next start. Until minimax-code#384 lands it will have no effect.

mcode silently ignores a window the model does not advertise, so confirm the result with mcode_context. Only processes this call starts are affected, and a session that already exists keeps the window it was created with.

Not supported (honest error, not a fake flag): follow_up on mcode_send, effort, allowed_tools, system_prompt_append, permission=ask.

mcode({
  prompt: "Read and execute the prompt: /abs/path/prompt.md",
  cwd: "/abs/path/to/repo",
  model: "minimax/MiniMax-M3.1-Flash-Preview"
})

// later:
mcode_reply({
  session: "<id from the prefix>",
  prompt: "Now check the error paths of those call sites."
})

Default permission is full. Delegation is only useful when the delegate can act. Headless smart can stop with INTERACTION_NOT_AVAILABLE if Runtime asks a question. ACP session/cancel is how a running turn is aborted; there is no documented mid-turn follow-up queue, so mcode_send follow_up errors instead of pretending to queue.

What comes back

Only mcode's final result plus aggregate stats — never the transcript, thinking, tool arguments or raw stdout.

A timed-out or cancelled run still returns [session: <id>] and [session-key: mcode:<id>] when mcode named the session. Resume it with mcode_reply; do not treat the deadline as a lost session.

`mcode_history`

Read-only snapshot of the native transcript. Does not prompt mcode.

mcode_history({ session: "<id from the prefix>" })

Source: <dataDir>/v2/sessions/YYYY/MM/DD/<time>-session_<base64(id)>/messages.jsonl, where <dataDir> is MINIMAX_DATA_DIR, then MAVIS_DATA_DIR, then ~/.minimax[-<profile>] for the session's own profile. The page reports the profile it read. Items are user / assistant / tool / gap. Thinking and image binaries are omitted. Pass cursor from the previous page to continue; include_tools: false hides tool calls/results but still advances the cursor.

Source

git clone https://github.com/minmax/mcode-mcp.git
cd mcode-mcp
npm ci
npm test

Releasing

Releases are published by the Publish npm package workflow when a v* tag is pushed. It authenticates through npm trusted publishing (GitHub OIDC), so there is no NPM_TOKEN secret. The tag must equal v<version> from package.json.

npm version patch   # bumps package.json and creates the vX.Y.Z tag
git push --follow-tags

Available Tools

7 tools

mcodeA

Destructive

Start a NEW task in the local MiniMax Code agent (mcode) — a separate CLI coding agent with its own file/shell tools and its own context window. Blocks until mcode settles, then returns only its final result plus stats, prefixed [session: ] and [session-key: mcode:]; continue that session later with mcode_reply. Caution: with permission 'full' (the server default) mcode edits files and runs shell commands as your user inside cwd without asking.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Usually omit to use this server's cwd. If set, must be an absolute path (relative is rejected). mcode works and edits here.
`mode`	No	ACP session/set_mode: 'default' or 'plan'. Print/exec has no session mode flag — plan on print is rejected.
`model`	No	Model as MiniMax Code expects it: provider/model, e.g. 'minimax_oauth/MiniMax-M2.5'. Defaults to mcode's own default. mcode_models lists what provider list --json reported.
`prompt`	Yes	The complete task. mcode cannot see this conversation, so include everything it needs: file paths, goal, constraints, expected output format.
`transport`	No	Usually omit. The default 'acp' keeps mcode up (`mcode acp`) so a running turn can be aborted or steered with mcode_send. 'print' is mcode exec --output-format stream-json: one process per turn that cannot be reached while it works.
`permission`	No	Headless --permission: 'smart' (auto routine, ask when needed), 'full' (bypassPermissions), 'off'. Server default is full. ACP maps smart→auto and full→bypassPermissions. 'off' is exec-only; ACP rejects it. 'ask' is not a headless option.
`timeout_ms`	No	Usually omit — there is no server default deadline. A run killed at the deadline is not lost: it still returns its session id and is resumable with mcode_reply. Print also forwards --timeout <N>ms.
`thinking_effort`	No	ACP-only session/set_config_option id=thinkingEffort. Values are model-dependent; print has no equivalent flag.

TDQS

A4.3/5.0

Behavior5/5

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

The description goes beyond the annotations by warning about the default 'full' permission that edits files and runs shell commands without asking. It also discloses that the tool blocks until mcode settles and returns only the final result plus stats with session prefixes. These details are not present in the annotations (which only have destructiveHint=true) and provide critical behavioral context.

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

Conciseness4/5

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

The description is somewhat long but well-structured: it leads with the core purpose, then explains the return format and continuation, and ends with a caution. It front-loads the most important information (new task) and avoids redundancy. The caution is useful but adds length; overall it is efficient for the complexity of the tool.

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 complex tool with 8 parameters and no output schema, the description provides essential context: return format (session id and session-key prefixes), blocking behavior, timeout handling (run killed still returns session id), and permission implications. It also explains the transport modes and model parameter. It lacks some details about the output stats structure, but overall it covers the key aspects an agent needs to call and interpret the tool correctly.

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 100%, so all 8 parameters are already documented. The description does add a small amount of context (e.g., that mcode cannot see the conversation and that cwd is usually omitted), but these are also present in the schema's parameter descriptions. The description does not significantly enhance parameter meaning beyond what the schema provides, so a baseline 3 is appropriate.

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 ('Start') and resource ('a NEW task in the local MiniMax Code agent'), and clearly differentiates from siblings by stating this starts a new task while continuing later is done with mcode_reply. It also distinguishes from other mcode tools (models, running, send, etc.) by focusing on task initiation.

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

Usage Guidelines4/5

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

The description explicitly states when to use this tool (start a new task) and implies when not to (for continuing a session, use mcode_reply). It also gives context about the separate CLI agent and its own context window, which helps the agent decide when this tool is appropriate. However, it doesn't explicitly list alternatives for other scenarios (e.g., checking running sessions).

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

mcode_historyA

Read-onlyIdempotent

Read a bounded snapshot of a MiniMax Code session's visible conversation from the native messages.jsonl under ~/.minimax/v2/sessions. Does not send anything into the run, does not take the session lock, and does not wait for mcode to finish. Returns JSON: session, state (active if this process is running it, otherwise unknown), items (user / assistant / tool / gap), an opaque cursor to resume even at the current EOF, has_more, truncated_tail. Thinking and image binaries are omitted. Caps: limit (default 50, max 200), max_chars per item (default 4000, max 16000), and 100000 chars on the whole JSON page.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Max items to return (default 50, max 200).
`cursor`	No	Opaque resume token from a previous mcode_history call for this same session and transcript. Omit to read from the start.
`session`	Yes	Session id from [session: <id>] or mcode_sessions / mcode_running.
`max_chars`	No	Max characters per item text (default 4000, max 16000).
`include_tools`	No	Include tool calls/results (default true). Filtered tool lines still advance the cursor.

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the readOnly and idempotent annotations, the description adds useful behavioral detail: no run-side effects, no lock, no waiting, exact JSON fields returned, omitted content, and precise caps. This is meaningful behavioral context that annotations alone would not convey.

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 definition is dense but concise: it front-loads the purpose and safety properties, then gives the return shape and caps. Every sentence carries information, and there is no filler 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?

With no output schema present, the description properly returns to the return shape (session, state, items, cursor, hasMore, truncatedTail), caps, and omissions. That is enough for an agent to decide when and how to invoke the tool.

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

Parameters5/5

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

Schema coverage is already high, but the description goes further by explaining the cursor can resume at current EOF, note that filtered tool lines still advance the cursor, and the whole-page 100,000-character cap. These details give an agent a more accurate mental model of pagination and limits.

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 and resource: 'Read a bounded snapshot of a MiniMax Code session's visible conversation from the native messages.jsonl'. It clearly differentiates itself from sibling tools by stating that it does not send anything into the run, does not take the session lock, and does not wait for mcode to finish.

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?

It gives clear context for when to use it: when an agent needs a non-blocking, read-only view of past conversation without interfering with the run. However, it does not name sibling tools explicitly or provide formal when-not-to-use 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.

mcode_modelsA

Read-onlyIdempotent

List what this MiniMax Code installation reports via mcode provider list --json. Use it to pick a model value for mcode / mcode_reply. Starts no task. Official OAuth providers may list zero models even when a default model is configured.

ParametersJSON Schema

Name	Required	Description	Default
`search`	No	Optional substring filter on provider or model id.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it starts no task and may report zero models even when a default model is configured, which prevents misinterpretation of results.

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 tight sentences with no filler. The first sentence states the mechanism, the second states the purpose, and the third states a critical caveat. Every sentence earns its place and key information is front-loaded.

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 list tool with one optional parameter, no output schema, and annotations covering safety, the description is complete. It tells the agent what command is run, how to use the result, that no task is started, and how to interpret an empty result from OAuth providers.

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 100% for the single optional `search` parameter, so the schema already documents its meaning. The description does not add parameter-level detail, but it also does not need to; the baseline of 3 applies because the schema carries the param semantics.

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 ('List what this MiniMax Code installation reports via `mcode provider list --json`') and clear resource (models). It also distinguishes itself from siblings by explicitly saying it is used to pick a `model` value for `mcode` / `mcode_reply`, and clarifies that it 'Starts no task.'

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 gives clear usage context: use this tool to select a `model` value for `mcode` / `mcode_reply`. It also provides a useful exclusion ('Starts no task') and a caveat about official OAuth providers listing zero models. It does not explicitly name sibling alternatives, but the intended use is well established.

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

mcode_replyA

Destructive

Send a new turn to an existing mcode session that is not executing right now — including one that timed out or was cancelled: the session survives in MiniMax Code's own store, so resume it here instead of restarting with mcode. Survives restarts of this server. For a turn still running under 'acp', use mcode_send instead.

ParametersJSON Schema

Name	Required	Description
`cwd`	No	Absolute path override. Defaults to the directory where the session started.
`mode`	No	ACP session/set_mode: 'default' or 'plan'. Print/exec has no session mode flag — plan on print is rejected.
`model`	No	Model as MiniMax Code expects it: provider/model, e.g. 'minimax_oauth/MiniMax-M2.5'. Defaults to mcode's own default. mcode_models lists what provider list --json reported.
`prompt`	Yes	Follow-up message for this session.
`session`	Yes	Session id from a [session: <id>] prefix, or from mcode_sessions.
`transport`	No	Usually omit. The default 'acp' keeps mcode up (`mcode acp`) so a running turn can be aborted or steered with mcode_send. 'print' is mcode exec --output-format stream-json: one process per turn that cannot be reached while it works.
`permission`	No	Headless --permission: 'smart' (auto routine, ask when needed), 'full' (bypassPermissions), 'off'. Server default is full. ACP maps smart→auto and full→bypassPermissions. 'off' is exec-only; ACP rejects it. 'ask' is not a headless option.
`timeout_ms`	No	Usually omit — there is no server default deadline. A run killed at the deadline is not lost: it still returns its session id and is resumable with mcode_reply. Print also forwards --timeout <N>ms.
`thinking_effort`	No	ACP-only session/set_config_option id=thinkingEffort. Values are model-dependent; print has no equivalent flag.

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already signal mutating and destructive behavior, so the description only needs to add context beyond that. It does so by disclosing that sessions survive in MiniMax Code's store, survive server restarts, and are resumable even after timeouts or cancellation. This gives the agent meaningful behavioral expectations without contradicting 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 packs the core action, persistence semantics, and sibling routing into two sentences without fluff. It front-loads the main purpose and only then adds the critical 'not executing' constraint and alternative-tool guidance. Every sentence earns its place.

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 tool with 9 parameters, no output schema, and several sibling tools, the description covers the essential selection logic and persistence behavior well. It does not explain return values or how the response arrives, but the absence of an output schema lowers that burden. It could slightly expand on side effects or output expectations, but overall it is largely complete for invoking the tool correctly.

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 100%, so the baseline is 3. The description itself adds little parameter-level detail, but that is acceptable because the schema already explains all 9 parameters, including enums and semantics for transport, permission, mode, and timeout. The description's main contribution is tool-selection context rather than parameter explanation.

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 clear verb and resource: 'Send a new turn to an existing mcode session that is not executing right now.' It also explicitly differentiates from siblings, naming both mcode_send for running turns and `mcode` for restarting sessions. This makes the tool's purpose unambiguous.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use context: use when a session is not executing, including timed-out or cancelled sessions, and use mcode_send instead for a turn still running under 'acp'. It also advises resuming rather than restarting with `mcode`, providing a clear decision rule relative to alternatives.

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

mcode_runningA

Read-onlyIdempotent

List mcode turns executing at this moment — the ones mcode_send can reach — with session id, working directory, elapsed time, and messages already sent in. Only acp-transport runs appear. For past sessions use mcode_sessions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety profile is covered. The description adds meaningful behavioral context: this is a live snapshot filter limited to acp-transport runs and reachable by mcode_send, plus which fields are included.

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 purpose and scope, followed by the key exclusion and routing to sibling. No redundant wording.

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 parameterless, read-only listing tool, the description fully enables correct selection and invocation. It states the relevant filter, the returned fields, and the sibling for past data, with output schema not needed.

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?

Tool has zero parameters and schema covers all of them, so the description has no parameter burden. Baseline 4 applies since no parameter ambiguity exists.

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

Purpose5/5

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

Description uses specific verb 'List' with clear resource 'mcode turns executing at this moment' and explicitly bounds scope to 'the ones mcode_send can reach' and 'Only acp-transport runs appear'. This distinguishes it from siblings like mcode_sessions without opening schemas.

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

Usage Guidelines5/5

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

Explicitly tells when to use: current executing turns, and names the alternative 'For past sessions use mcode_sessions'. The 'Only acp-transport runs appear' exclusion clarifies a key selection condition.

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

mcode_sendA

Destructive

Deliver a message into an mcode turn that is executing right now. Works only on runs started with transport 'acp' — a session that already finished takes mcode_reply, not mcode_send. follow_up is unsupported: MiniMax Code ACP does not document a mid-turn queue. steer cancels the current turn and submits the message as a new prompt. mcode_running lists reachable sessions.

ParametersJSON Schema

Name	Required	Description
`command`	No	'abort' (default) cancels the current turn via ACP session/cancel; 'steer' cancels and immediately submits the message as a new user turn. 'follow_up' is rejected.
`message`	No	Text to deliver. Required for 'steer', ignored by 'abort'.
`session`	Yes	Session id of the running turn (see mcode_running).

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations' destructiveHint=true, the description discloses meaningful behavior: steer cancels the current turn and submits the message as a new prompt, follow_up is rejected because MiniMax Code ACP has no documented mid-turn queue, and sessions that already finished require a different tool. This gives the agent a clear mental model of side effects and constraints without contradicting 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 compact and front-loaded, starting with the core action before moving into constraints, unsupported behavior, and related-tool pointers. Every sentence carries necessary information and there is no filler or repetition of schema details.

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 three parameters, no output schema, and destructive annotations, the description covers the key operational context: when the tool is valid, what happens with each command mode, and how to discover sessions. It does not describe the return value, but for a message-delivery/cancel tool this is a minor gap rather than a blocking one.

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 covers all three parameters with 100% description coverage, so the baseline is 3. The description adds value by clarifying that message is required for steer and ignored by abort, and that session refers to a running turn listed by mcode_running. This goes slightly beyond the schema without repeating its details.

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

Purpose5/5

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

The description clearly states the tool's action: 'Deliver a message into an mcode turn that is executing right now.' It also distinguishes itself from the sibling mcode_reply by noting that finished sessions should use mcode_reply, not mcode_send. This makes the purpose immediately disambiguated.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use context: only for runs started with transport 'acp' and only while the turn is executing. It also names the alternative for finished sessions (mcode_reply) and directs users to mcode_running for reachable sessions. This is strong, actionable guidance.

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

mcode_sessionsA

Read-onlyIdempotent

List all mcode sessions started through this server, newest first — running or finished, including runs that timed out. Each row gives the session id, when it last ran, cwd, remembered transport, and model. Use it to recover an id for mcode_reply. For turns still executing (mcode_send targets), use mcode_running.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is covered. The description adds sorting, inclusion of running/finished/timed-out sessions, and enumerates the returned fields, which is useful behavioral context beyond the annotations.

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

Conciseness5/5

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

Three compact sentences; the key scope and ordering come first, the returned fields second, and usage guidance last. Every clause adds information with no repetition of annotations or schema.

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 no-parameter read-only listing tool, it fully states scope, ordering, return-row content, and how the result should be used. It even handles the only likely ambiguity by routing executing turns to mcode_running, so nothing an agent needs to invoke it correctly is missing.

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 coverage is 100% for the empty schema, so there is no parameter description burden. The baseline for zero-parameter tools applies.

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 ('List') and identifies the exact resource ('mcode sessions started through this server'), including ordering ('newest first') and scope. It also distinguishes itself from the sibling mcode_running, so an agent can select it confidently.

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

Usage Guidelines5/5

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

Explicitly instructs when to use it: to recover a session id for mcode_reply. It also names the alternative tool (mcode_running) for currently executing turns, so the main exclusion case is clearly covered.

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.

7 tool updatesv0.1.0Sep 10, 2026
- First observedmcode
- First observedmcode_history
- First observedmcode_models
- First observedmcode_reply
- First observedmcode_running
- First observedmcode_send
- First observedmcode_sessions

Deploy Server

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

TDQS

A4.4/5.0

Scored 2026-09-10 20:47 across 7 tools

Disambiguation4/5

Each tool targets a distinct action—start, reply, send, list running, list all, list models, read history—and the descriptions explicitly cross-reference each other to clarify boundaries. However, mcode_reply vs mcode_send and mcode_running vs mcode_sessions still require careful reading to distinguish.

Naming Consistency3/5

All tools share the mcode_ prefix, but the suffixes are inconsistent: verbs (reply, send), gerunds (running), and nouns (models, sessions, history), plus the bare mcode for the primary action. There is no uniform verb_noun pattern.

Tool Count5/5

Seven tools cover the full lifecycle of interacting with a local coding agent without redundancy. The count feels well-scoped for the stated purpose.

Completeness4/5

The toolset covers starting, resuming, interrupting, listing, and inspecting mcode sessions, including model discovery. A few optional operations like an explicit stop/terminate endpoint are absent, but core workflows are complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

AI Worlds CLI Knowledge A
com.claude-world
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Command Line Developer Tools Documentation Access
121
BCD — Bridge Control Delegate A
com.snack-wrap.bcd
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
File Systems Command Line Browser Automation
611
Railway MCPOAuth
com.railway
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Cloud Platforms Developer Tools CI/CD & DevOps
2
Bring Your AI A
ai.bringyour
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Developer Tools Coding Agents
72

Related MCP Servers

MiMo Bridge MCP
Coding Agents Version Control
Ichliebedich1
A
license
Not graded
quality
C
maintenance
Enables Codex to delegate bounded coding tasks to MiMo Code through a shared local daemon, supporting task boundaries, Git Worktrees, and a collaborative review workflow.
Updated 2 months ago (2026-08-11 18:51 UTC)
3
MIT
Codex to OpenCode MCP Server
Coding Agents Autonomous Agents Developer Tools
TAO-MINGYU
A
license
A
quality
C
maintenance
Enables Codex to delegate coding tasks to an OpenCode CLI locally, returning structured results such as exit codes, session summaries, tool calls, and git diffs.
Updated a month ago (2026-08-24 13:55 UTC)
2
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 a month ago (2026-08-27 20:02 UTC)
MIT
kimi-cli-mcp
Coding Agents Code Execution Developer Tools
minmax
A
license
A
quality
C
maintenance
Delegates coding tasks to the locally installed Kimi Code CLI, reusing its auth, models, and configuration while adding tools for sessions, replies, model discovery, live turn steering, and history access.
Updated 25 days ago (2026-09-09 19:27 UTC)
7
3 npm
MIT