mcode-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCODE_MCP_BIN | No | Path to the MiniMax Code CLI script (e.g., /path/to/@minimax-ai/code/cli.js) to use instead of the default `mcode` on PATH. | |
| MCODE_MCP_WRAP | No | Path to a Node.js executable to use when spawning the CLI, without shell interpolation. The process is spawned as `node <MCODE_MCP_BIN> <args...>`. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| mcodeA | Start a NEW task in the local MiniMax Code agent ( |
| mcode_replyA | 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_modelsA | List what this MiniMax Code installation reports via |
| mcode_sendA | 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. |
| mcode_runningA | 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. |
| mcode_sessionsA | 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. |
| mcode_historyA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
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.
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.
Seven tools cover the full lifecycle of interacting with a local coding agent without redundancy. The count feels well-scoped for the stated purpose.
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.