Skip to main content
Glama
minmax

mcode-mcp

by minmax
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

mcode_reply

Destructive

Resume a paused, timed-out, or cancelled MiniMax Code session by sending a follow-up message without restarting it.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoAbsolute path override. Defaults to the directory where the session started.
modeNoACP session/set_mode: 'default' or 'plan'. Print/exec has no session mode flag — plan on print is rejected.
modelNoModel 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.
promptYesFollow-up message for this session.
sessionYesSession id from a [session: <id>] prefix, or from mcode_sessions.
transportNoUsually 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.
permissionNoHeadless --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_msNoUsually 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_effortNoACP-only session/set_config_option id=thinkingEffort. Values are model-dependent; print has no equivalent flag.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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.

Deploy Server

Other Tools