This server integrates MiniMax AI into Claude Code, offloading coding tasks to the MiniMax API to save Claude subscription quota. It provides the following tools:
minimax_agent_task: Run complete coding tasks autonomously — MiniMax reads files, writes code, runs tests, and debugs in a loop (up to 25 configurable iterations) with security sandboxing (bash whitelist, path isolation, timeouts).
minimax_generate_code: Generate code in any language with optional context, and optionally write output directly to a file.
minimax_chat: Multi-turn conversations with context preserved across calls via conversation IDs.
minimax_plan: Generate a structured JSON implementation plan for a given task, with optional codebase context.
minimax_web_search: Search the web via MiniMax AI, returning titles, links, snippets, and related suggestions.
minimax_understand_image: Analyze images (JPEG/PNG/WebP, max 20MB) from URLs, local file paths, or base64 data URLs using MiniMax VLM.
minimax_cost_report: Real-time report of token usage, API costs, and estimated savings vs. Claude for the current session.
minimax_session_tracker: Track cross-session MiniMax usage with trend analytics and self-improvement modes (Normal, Warning, Forced).
Additional features include automatic failure logging and telemetry (monthly JSONL logs with error categorization and digest analysis), support for large outputs (up to 65,536 tokens), and a model override parameter on all AI tools to choose from MiniMax-M3, M2.5, M2.7, and their highspeed variants.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@my-minimax-mcp generate a Python script to calculate fibonacci numbers"
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.
MCP server that wraps MiniMax AI as an autonomous code executor for Claude Code.
Purpose: Coding tasks consume the bulk of your Claude subscription quota on execution (writing, testing, debugging). This MCP server offloads that work to MiniMax API (~$0.04/task), so your Claude subscription handles significantly more tasks per day. Built-in savings tracking proves it with real data.
Claude Code (Opus) ─── orchestrator
│
├── minimax_generate_code → simple code generation
├── minimax_agent_task → autonomous agent loop (read → write → test → debug)
├── minimax_chat → multi-turn conversation
├── minimax_plan → structured JSON implementation plan
├── minimax_cost_report → session cost tracking
├── minimax_session_tracker → cross-session usage tracking (auto-persist on shutdown)
├── minimax_web_search → web search via MiniMax Coding Plan API
└── minimax_understand_image → image analysis via MiniMax VLMThe key feature is the agent loop: MiniMax uses function calling to autonomously read files, write code, run tests, and debug — equivalent to a Sonnet sub-agent, but without consuming Claude subscription tokens.
Related MCP server: claude-code-mcp
Tool | Description | Default Model |
| Autonomous coding: read files, write code, run tests, debug loop. Supports tools: |
|
| Generate code, optionally write to file |
|
| Multi-turn conversation with context preservation |
|
| Structured implementation plan as JSON |
|
| Session token usage and cost breakdown | — |
| Cross-session usage tracking with self-improvement modes | — |
| Search the web using MiniMax AI | — |
| Analyze images using MiniMax VLM (JPEG/PNG/WebP, max 20MB) | — |
| Text-to-speech (MiniMax Speech 2.8 T2A v2). Converts text to audio with configurable voice and speed. | — |
| Music generation (MiniMax Music 2.6). Vocal songs from | — |
| Video generation (MiniMax Hailuo 2.3). Async: submit → poll → retrieve download URL. Up to 5 min. | — |
npm install my-minimax-mcpSign up at platform.minimax.io and create an API key.
Option A: Via npm (recommended)
npm install my-minimax-mcpOption B: From source
git clone https://github.com/wongo/my-minimax-mcp.git
cd my-minimax-mcp
npm install
npm run build.envMINIMAX_API_KEY=your_api_key_hereclaude mcp add --transport stdio --scope user minimax -- bash /path/to/my-minimax-mcp/run-mcp.shOr manually edit ~/.claude/settings.json:
{
"mcpServers": {
"minimax": {
"command": "npx",
"args": ["my-minimax-mcp"],
"env": {
"MINIMAX_API_KEY": "your-api-key",
"MINIMAX_DEFAULT_MODEL": "MiniMax-M2.7"
}
}
}
}Note: Use
claude mcp addfor the simplest setup, or edit~/.claude/settings.jsondirectly.
Restart Claude Code. The 8 tools will appear automatically. Verify with claude mcp list.
npx my-minimax-mcp --initThis displays the CLAUDE.md template and creates the usage log. Copy the template to ~/.claude/CLAUDE.md to enable executor routing rules. Session tracking is automatic — the MCP server persists usage data on shutdown. See templates/setup-guide.md for details.
# Code generation
npx tsx src/cli.ts --task "fibonacci in Python" --language python
# Chat
npx tsx src/cli.ts --mode chat --task "explain async/await"
# Autonomous agent
npx tsx src/cli.ts --mode agent --task "fix the failing tests" --dir ./my-projectCLI runs also append to MINIMAX_COST_LOG, so --end-session and --savings-report include normal CLI usage in addition to MCP usage.
All settings via environment variables:
Variable | Description | Default |
| API key (required) | — |
| Default model used by all MiniMax chat/plan/code/agent tools unless a per-call override is supplied |
|
| Agent loop max iterations |
|
| Maximum input tokens per agent task (override for large tasks) |
|
| Maximum web searches per agent task |
|
| Per-task timeout |
|
| Additional allowed bash commands (comma-separated) | — |
| Base working directory for file operations; |
|
| Cost log file path |
|
| Session usage log path |
|
| Min MiniMax calls per session |
|
Usage tracking is automatic — the MCP server persists session data to ~/.claude/minimax-usage.jsonl on shutdown (SIGTERM/SIGINT). No manual start/end calls required.
Optional commands via minimax_session_tracker:
"start" — check current mode and recent trends
"status" — mid-session progress with trend analytics and streak info
"end" — explicit close with root cause notes if target was missed
Modes:
Normal: Default. Target is MINIMAX_SESSION_TARGET calls (default: 5)
Warning: Last session missed target — prioritize MiniMax
Forced: 2 consecutive misses — all code changes must use MiniMax
Trend analytics: The status command returns trend direction (improving/declining/stable), streak length, and actionable insights.
SessionEnd hook (optional, for fully automatic tracking):
npx my-minimax-mcp --end-sessionAdd to ~/.claude/settings.json hooks:
{
"hooks": {
"SessionEnd": [{
"hooks": [{
"type": "command",
"command": "npx my-minimax-mcp --end-session",
"timeout": 10
}]
}]
}
}Set MINIMAX_DEFAULT_MODEL to the highest model your Token Plan supports. All MiniMax tools inherit this value by default, and the API will reject models not available on your plan.
Every tool call outcome (success, failure, retry) is automatically recorded to the logs/ directory — no configuration needed.
File | Contents |
| Failure records (error category, fingerprint, caller project) |
| Success records (tool, duration, model, iterations) |
| Retry records (attempt count, final outcome) |
Files rotate monthly. The logs/ directory is gitignored.
path_invalid · sandbox_violation · edit_file_no_match · iteration_limit · api_5xx · network_timeout · auth_error · unknown
# This month's digest (7 sections)
node scripts/analyze-failures.mjs
# Specific month
node scripts/analyze-failures.mjs --month 2026-05
# Custom date range
node scripts/analyze-failures.mjs --from 2026-05-01 --to 2026-05-15
# JSON output (for machine processing)
node scripts/analyze-failures.mjs --jsonOutput sections: Summary (total calls / success rate), Top categories, Top fingerprints (deduplicated bugs), Per-tool, Per-caller (which project called), Retry effectiveness, Quick wins (high-frequency issues with success rate < 80%).
Variable | Description |
| Custom log directory (default: |
Every MiniMax call is tracked, and the savings are computed automatically. This includes normal CLI runs as well as MCP server usage. Use minimax_cost_report to see real-time savings per session, or run the CLI for cumulative reports.
minimax_cost_report now includes a savings section:
tokensOffloaded: Exact count of tokens MiniMax handled instead of Claude
equivalentSonnetCalls: How many Sonnet sub-agent calls that represents
avgTokensPerCall: Self-adaptive metric (auto-improves with more data)
npx my-minimax-mcp --savings-reportShows all-time, monthly, and daily breakdowns with tool-level analysis:
=== MiniMax Token Savings Report ===
Tokens offloaded to MiniMax: 426,040 in + 161,496 out = 587,536 total
Equivalent Sonnet calls saved: ~68 (avg 8,635 tokens/call)
MiniMax API cost: $0.2468 (billed separately, not your subscription)
--- By Tool ---
agent_task 400,254 tokens (68.1%) | 8 calls
generate_code 144,290 tokens (24.6%) | 37 calls
chat 28,142 tokens (4.8%) | 20 callsThe avgTokensPerCall metric adapts to your usage patterns:
< 10 data points: Uses conservative default (8,000 tokens/call)
10-100 data points: Computes from all your metered calls
100+ data points: Uses rolling window of last 100 calls
Confidence level (LOW/MEDIUM/HIGH) is reported so you know how reliable the estimate is. The more you use MiniMax, the more accurate the savings report becomes.
These tools use MiniMax's Coding Plan API (separate from the chat completions endpoint). They are included in your Token Plan subscription at no additional per-call cost.
minimax_web_search { query: "TypeScript MCP server tutorial" }Returns organic results (title, link, snippet, date) and related search suggestions.
Why keep a second web search source? Most web tools (firecrawl, tavily) are credit- or plan-capped — when the quota runs out, research stops.
minimax_web_searchis billed independently on your MiniMax monthly Token Plan, so it keeps working when your other tools hit their limit. It returns snippets (not full-page extraction), so think of it as a resilient second source rather than a 1:1 firecrawl replacement.
minimax_understand_image {
prompt: "Extract the business hours from this image",
imageSource: "https://example.com/schedule.png"
}Accepts three input types:
HTTP/HTTPS URL: Fetched and converted to base64 automatically
Local file path: Read from disk (supports @ prefix)
Base64 data URL: Passed through directly
Supported formats: JPEG, PNG, WebP (max 20MB).
Max output: 65,536 tokens per response (~10,000 Chinese characters / ~50K English words)
Think tag stripping: MiniMax <think>...</think> reasoning tags are automatically removed from all responses
The agent loop runs with strict sandboxing:
Bash whitelist: Only npm test, npx, node, tsc, eslint, pytest, go test, cargo test, etc.
Command chaining blocked: &&, ;, | operators are rejected
Path isolation: All file operations restricted to the working directory
Agent working-directory boundary: minimax_agent_task can only operate inside MINIMAX_WORKING_DIR or one of its subdirectories
Iteration cap: 25 iterations max per task (configurable via MINIMAX_MAX_ITERATIONS)
Timeout: 5 minutes per task (configurable via MINIMAX_TIMEOUT_MS)
Token budget: 500K input tokens max per task (configurable via MINIMAX_MAX_INPUT_TOKENS)
Web search budget: 10 searches max per task (configurable via MINIMAX_MAX_WEB_SEARCHES)
MiniMax API pricing (per 1M tokens):
Model | Input | Output | Best for |
M2.5 | $0.118 | $0.99 | Routine code generation |
M2.7 | $0.30 | $1.20 | Complex reasoning |
Typical task cost: ~$0.04 (agent loop with 10 iterations).
Full integration test (14 MCP calls, 13 tests):
Total cost: $0.012 (1.2 cents)
Input tokens: 38,913
Output tokens: 7,228Test | Result |
API connectivity | PASS |
Code generation | PASS |
Agent loop (autonomous bug fix) | PASS |
Structured planning (JSON) | PASS |
Multi-turn conversation | PASS |
Cost tracking | PASS |
Multi-file task (todo module) | PASS |
Security (dangerous cmd blocked) | PASS |
Routing (Opus → MiniMax, not Sonnet) | PASS |
Graceful failure (max iterations) | PASS |
Web search (Japanese query) | PASS |
Image understanding (URL) | PASS |
Image understanding (local file) | PASS |
# Run all tests (148 tests)
npm test
# Run with coverage report
npm run coverageUnit tests cover safety validation, cost tracking, file writing, server initialization, session tracking, image utilities, the Coding Plan client, the savings calculator, and the failure logging system (error classification, secrets scrubbing, telemetry, retry tracking). Coverage report uses Node.js built-in test coverage (--experimental-test-coverage).
src/
├── mcp-server.ts # MCP server entry (stdio transport)
├── cli.ts # CLI for debugging
├── client/
│ ├── minimax-client.ts # OpenAI SDK wrapper for MiniMax chat API
│ ├── coding-plan-client.ts # Native fetch client for Coding Plan API (web search, VLM)
│ └── types.ts # Shared types and pricing
├── agent/
│ ├── loop.ts # Agent loop core logic
│ ├── functions.ts # Function definitions for MiniMax
│ ├── executor.ts # Function call executor
│ └── safety.ts # Whitelist, path validation, limits
├── tools/
│ ├── agent-task.ts # minimax_agent_task
│ ├── generate-code.ts # minimax_generate_code
│ ├── chat.ts # minimax_chat
│ ├── plan.ts # minimax_plan
│ ├── web-search.ts # minimax_web_search
│ ├── understand-image.ts # minimax_understand_image
│ └── index.ts # Tool registry
├── conversation/
│ └── store.ts # In-memory conversation store
└── utils/
├── cost-tracker.ts # Token usage and cost tracking (with session ID)
├── session-tracker.ts # Cross-session usage tracking and trend analytics
├── file-writer.ts # Safe file writing
├── image.ts # Image to base64 data URL conversion
├── savings-calculator.ts # Token savings computation (self-adaptive)
├── failure-logger.ts # Failure JSONL logging (scrubbing, fingerprints, monthly rotation)
├── telemetry.ts # Success / retry telemetry recording
├── error-classifier.ts # Error classification (8 categories)
├── secrets-scrubber.ts # Sensitive data redaction
└── retry.ts # Exponential backoff retry (with onAttempt callback)
scripts/
└── analyze-failures.mjs # Monthly failure & telemetry digest analyzer
logs/ # Runtime JSONL files (gitignored)Cost accuracy, network deadlines, and agent tool robustness
minimax_cost_report was overcharging M3 by 2×. MODEL_PRICING used M3's list price ($0.60/$2.40 per 1M tokens). MiniMax applies a permanent 50% discount up to 512k input tokens — not the expiring introductory discount an out-of-date comment claimed. Since maxInputTokens defaults to 500k, every request we make bills at $0.30/$1.20. Corrected, so cost and savings reports no longer double-count M3 usage.
Every network call now has a deadline. A bare fetch() never gives up, so a stalled socket hung the MCP tool forever. Timeouts are sized per call type rather than one blunt value — synchronous music/TTS generation legitimately runs for minutes, while a status poll should not:
Call type | Timeout |
Music / TTS generation | 300 s |
Video submit, poll, retrieve; web search; image understanding | 30–60 s |
Media download | 300 s |
Agent tools.
list_files no longer walks node_modules, .git, dist, build, .next, coverage, .venv, __pycache__, .cache. On a real project it previously enumerated every dependency file — a latency and token sink.
search_content no longer reports every failure as "No matches found." A bad regex, an unreadable path, or a timeout now raise a real error. When grep errors on one file but matched others, the partial matches are returned rather than failing the whole search.
write_file and edit_file now write atomically (temp file + rename), matching edit_file_batch. A crash mid-write can no longer truncate the file being edited.
Consistency. MiniMaxClient's constructor defaulted to MiniMax-M2.5 while the env default, CodingPlanClient, and every registered tool schema used MiniMax-M2.7. All callers passed a model explicitly so nothing broke, but the mismatch was a landmine. Now M2.7 throughout.
Media output. outputFile now creates missing parent directories. It remains an unrestricted absolute path by design — these tools are invoked by the MCP client, not the sandboxed agent, and the documented contract is an absolute path. This is stated explicitly in media-shared.ts so it reads as a decision rather than an oversight.
Tests. 203 → 211.
Sandbox hardening, clearer agent diagnostics, and media tool tests
Security — run_bash sandbox escapes closed. The bash whitelist was bypassable three ways, all of which could write or execute outside the working directory:
Redirection escape: echo pwned > /home/user/.bashrc passed, because echo is whitelisted and only > /dev was blocked. Redirection to any absolute, home (~), or parent (..) path is now blocked.
Inline code execution: node -e "..." / node -p "..." passed via the ^node whitelist entry, making the whole whitelist moot. node with -e/--eval/-p/--print is now blocked; running a script file still works.
find side effects: find / -delete and -exec passed via the ^find entry. Both are now blocked; plain find still works.
Agent loop diagnostics.
Token-budget exhaustion now reports reason: "token_budget" with its own diagnostics suggesting a higher maxInputTokens (or task decomposition). It previously reported reason: "iteration_limit" and advised raising maxIterations — useless advice when the loop ran out of tokens, not turns.
timeout, no_tool_calls, and task_failed exits now report the files the agent had already modified. They previously returned an empty filesChanged, hiding exactly the information needed to clean up after a failure.
Media tools.
minimax_generate_video: a poll returning Success with no file_id now raises a malformed-response error instead of silently polling to exhaustion and reporting a misleading timeout.
New MINIMAX_MEDIA_POLL_MS env var overrides the video poll interval (default 10000 ms).
Tests. 171 → 203. Added coverage for tts, generate_music, generate_video, and media-shared (32 new tests), including the three sandbox escape vectors above. The test/coverage scripts now glob test/*.test.ts instead of a hand-maintained file list, so new test files can no longer be silently skipped.
Release hygiene fix — removes stray files from the published package
Removed dist/app/sitemap.js (a non-source artifact accidentally shipped in 1.6.0) and its committed source, plus an unrelated script that belonged to a different project.
Added clean and prepublishOnly scripts: every publish now runs a clean build + full test suite, so stale dist/ output can never ship again.
No functional changes to any tool.
Three new media tools: TTS, Music, and Video
minimax_tts: Text-to-speech using MiniMax Speech 2.8 T2A v2. Accepts text (required), voiceId (default male-qn-qingse), speed (0.5–2.0, default 1.0), and optional outputFile (absolute path, saves as mp3). Returns { success, outputFile?, audioSizeBytes, message }.
minimax_generate_music: Music generation using MiniMax Music 2.6 (/music_generation, synchronous). Provide lyrics for a vocal song (lines separated by \n, supports [Verse]/[Chorus] tags), or prompt alone for instrumental (instrumental: true). Optional outputFile. Audio returned hex-encoded and decoded to mp3. Returns { success, audioSizeBytes, outputFile?, message }.
minimax_generate_video: Video generation using MiniMax Hailuo 2.3. Accepts prompt (required), duration (6 or 10 s, default 6), resolution (768P|1080P, default 1080P), model (default MiniMax-Hailuo-2.3), and optional outputFile. Async three-step flow: submit → poll query/video_generation for status: "Success" → files/retrieve to get the download URL (polls every 10 s, up to 5 minutes). Returns { success, taskId, fileId, videoUrl, outputFile?, message }.
Plan requirement: API video generation needs a Token Plan Max tier or available Credits. On Plus and lower tiers the API returns error 2056 (Token Plan usage limit reached) for any video model/resolution — TTS and music are included on Plus, but video is not. The tool surfaces this error directly rather than hanging.
minimax_agent_task — web_search tool + maxInputTokens override
Added web_search tool to agent loop, enabling autonomous web research during coding tasks. Agent can now search the web when it needs up-to-date external info (docs, fact-checks). Budget limited to MINIMAX_MAX_WEB_SEARCHES (default: 10 searches per task).
Added maxInputTokens configurable option via MINIMAX_MAX_INPUT_TOKENS env var (default: 500,000) and per-call maxInputTokens parameter override. Allows handling large tasks that exceed default token budget.
Bug fix: Corrected web search budget exhausted error message — was showing (max/max) instead of (count/max), misleading users about actual search usage.
Updated documentation: README.md now documents web_search in agent loop tool list, plus MINIMAX_MAX_INPUT_TOKENS and MINIMAX_MAX_WEB_SEARCHES env vars.
Code review: 1 bug fixed, 4 altitude issues logged as tech debt (non-blocking):
Reactive budget check (medium priority — saves tokens by checking before API call)
Tool registration boilerplate (low priority — reduce duplication)
Tool-wrapping closure pattern (low priority — 3 cases exist)
Web search diagnostics (low priority — improve UX)
session_tracker — fix project attribution on shutdown and manual end
auto-persist on shutdown (SIGTERM/SIGINT) always wrote project: MINIMAX_WORKING_DIR regardless of which project the Claude session was in, causing all usage data to be misattributed to the server base directory.
Manual minimax_session_tracker end had the same bug.
Fix: CostTracker now tracks a per-session project frequency counter via notifyProject(). Both the auto-persist and the manual end paths use getTopProject() to resolve the most-called project, falling back to the server base dir only when no workingDirectory was passed (e.g. sessions that only called web_search / chat).
notifyProject() is called from generate_code and agent_task handlers immediately after resolving workingDirectory.
minimax_generate_code — workingDirectory parameter
Added optional workingDirectory parameter. Previously the tool always resolved filePath relative to the MCP server's base directory (MINIMAX_WORKING_DIR), causing files to land in the wrong location when called from project sub-directories (e.g. taiwan-in-japan-portal). Callers can now pass an absolute project path; falls back to the server base if omitted.
analyze-savings.mjs — fix MiniMax token double-count
MiniMax sub-agent tokens (model names containing minimax) were being bucketed as "other" Claude tokens and priced at Sonnet rates, inflating the estimated Claude spend by ~$1,765 / month. Fixed: modelBucket() now returns null for MiniMax models and the aggregation loop skips null buckets entirely.
Model selection
MiniMax-M3 is now a selectable model on every tool that accepts a model override (agent_task, chat, generate_code, plan, understand_image). Predefined M2.7 / M2.5 / *-highspeed variants unchanged. Default remains M2.7.
MODEL_PRICING adds an M3 entry at the standard PAYG rate of $0.60 / $2.40 per 1M tokens (introductory 50% discount of $0.30 / $1.20 runs through 2026-06-07).
understand_image per-call model override
The minimax_understand_image MCP tool now accepts an optional model parameter (same enum as the other tools), so callers can choose M3 for native multimodal analysis instead of inheriting the client default.
CodingPlanClient constructor now takes a defaultModel argument and exposes getDefaultModel(); mcp-server.ts threads MINIMAX_DEFAULT_MODEL into it. Previously the env var had no effect on image calls (latent bug, now fixed).
Tests
162 tests (up from 161): 1 new test in tool-default-models.test.ts covering default + override model selection for understand_image.
Observability improvements
analyze-failures.mjs re-classifies stored records at read time using current rules — historical logs update automatically when classifier patterns improve
New Section 8 "Re-classification Deltas" in digest output shows how many records were corrected vs. stored category
network_timeout pattern extended to match "Request timed out." and "read timeout" variants (previously fell through to unknown)
Retry telemetry now actually fires — all 5 tools (web-search, chat, generate-code, understand-image, plan) pass onAttempt to withRetry() and log failed attempts via telemetry.recordRetry(); retries-YYYY-MM.jsonl will now have data
iteration_limit diagnostics
AgentTaskResult now includes diagnostics when reason === "iteration_limit": last 3 actions, unique files modified, stillProgressing heuristic, and a human-readable suggestion ("Retry with maxIterations=N" vs "decompose the task")
filesChanged in iteration_limit returns is now populated from tracked writes instead of always being []
mcp-server.ts warns to stderr when caller sets maxIterations < 10
Iteration_limit failure log entries now include diagnostics payload for future analysis
Tests
161 tests (up from 152): 8 new agent-loop tests for diagnostic helpers, 1 safety regression test for cross-project resolveWorkingDirectory
Failure Logging & Telemetry
Every tool call (success, failure, retry) is now recorded to monthly JSONL logs in logs/
8 error categories: path_invalid, sandbox_violation, edit_file_no_match, iteration_limit, api_5xx, network_timeout, auth_error, unknown
Secrets scrubbing — API keys, Bearer tokens, JWTs never reach logs
Deduplication fingerprints — identical bugs collapse into one entry
Per-caller attribution — failures attributed to the calling project by working directory
New scripts/analyze-failures.mjs digest with 7 sections: summary, categories, fingerprints, per-tool, per-caller, retry effectiveness, quick wins
Bug Fixes
Fixed sandbox_violation not being captured by failure logger (validation now inside try block)
Fixed callerProject showing as (unknown) for sandbox violations — falls back to raw input path
Fixed MINIMAX_WORKING_DIR defaulting to minimax project dir, blocking all cross-project agent_task calls; run-mcp.sh now sets it to ~/Projects
Internals
retry.ts: added onAttempt callback for retry telemetry
agent/loop.ts: added reason field to AgentTaskResult (iteration_limit, timeout, task_complete, task_failed, no_tool_calls)
148 tests (up from 96)
Guaranteed tokensOffloaded in every session cost report
Added savings analyzer (scripts/analyze-savings.mjs) with --diagnose and date range flags
Hardened launcher script; failure logging foundation
edit_file fuzzy match (CRLF / trailing-space tolerant) with closest-3-lines hints on failure
edit_file_batch for atomic multi-point edits in a single iteration
Routing calibration: raised Sonnet threshold from 5-file to cross-cutting refactor only
minimax_session_tracker auto-persists on shutdown (no manual end required)
MIT
Execute a complete coding task autonomously. MiniMax AI will read files, write code, run tests, and debug in an autonomous loop until the task is complete.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Full description of the task for the agent to complete | |
| workingDirectory | Yes | Absolute path to the working directory for file operations | |
| model | No | Model override (default: MINIMAX_DEFAULT_MODEL env var, typically M2.7) | |
| maxIterations | No | Maximum agent loop iterations (default: 25) | |
| systemPrompt | No | Custom system prompt for the agent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the full burden. It discloses the tool's autonomous loop behavior: reading files, writing code, running tests, debugging. This provides good transparency for an autonomous agent tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. The first sentence front-loads the purpose, and the second adds behavioral detail. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a clear autonomous loop and fully described parameters, the description covers the main behavior and scope. It could mention error handling or cancellation, but is sufficiently complete for an agent to understand its primary function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description does not add significant meaning beyond the schema descriptions. All parameters are described in the schema, so with 100% coverage, the baseline is 3. The description provides context but no parameter-specific enhancements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'execute a complete coding task autonomously', using a specific verb and resource. It distinguishes from siblings like minimax_generate_code by emphasizing the autonomous loop that includes reading, writing, testing, and debugging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for full coding tasks, but does not explicitly state when to use it versus alternatives like minimax_chat or minimax_plan. No when-not or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-turn chat with MiniMax AI. Supports conversation context preservation across multiple calls.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message to send to MiniMax | |
| conversationId | No | ID of existing conversation to continue | |
| model | No | Model override (default: MINIMAX_DEFAULT_MODEL env var, typically M2.7) | |
| systemPrompt | No | System prompt (only for new conversations) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses multi-turn capability and context preservation, but lacks details on auth, rate limits, or any 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose and key feature without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 4-parameter chat tool with no output schema, the description covers the core functionality but does not explain return format, error handling, or advanced usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for multi-turn chat with MiniMax AI and emphasizes conversation context preservation, which distinguishes it from sibling tools like minimax_agent_task or minimax_generate_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for chat with context preservation but does not explicitly contrast with alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a cost, token usage, and savings report for this session. Shows tokens offloaded to MiniMax that would have consumed Claude subscription quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool provides a report and mentions offloaded tokens, but does not disclose whether it is read-only, any required permissions, or rate limits. The description is adequate but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the core purpose. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description should hint at return format. It mentions what is shown (cost, token usage, savings, offloaded tokens) but does not specify if the report is text or structured. Given the tool's simplicity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is trivially 100%. The description adds no parameter information, but none is needed. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: 'Get a cost, token usage, and savings report for this session.' It specifies the verb 'Get' and the resource 'cost, token usage, and savings report', and further distinguishes from siblings by highlighting MiniMax offloading context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool. The sibling tools are all generative/action-oriented, so it's implicitly used for reporting, but no exclusions or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate code using MiniMax AI. Returns generated code and optionally writes it to a file.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Description of the code to generate | |
| language | Yes | Programming language (e.g., typescript, python, go) | |
| filePath | No | If provided, write generated code to this file path | |
| model | No | Model override (default: MINIMAX_DEFAULT_MODEL env var, typically M2.7) | |
| context | No | Additional context about the codebase or requirements |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses the main behavioral traits: code generation and optional file writing. It doesn't mention authentication, rate limits, or error handling, but the core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and optional behavior, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description fails to explain the return format or structure of the generated code beyond 'returns generated code'. This is a gap for a code generation tool that might return complex objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond what the input schema already provides for each parameter. The baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource 'code using MiniMax AI', and distinguishes from sibling tools like minimax_chat and minimax_agent_task which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for code generation but provides no explicit guidance on when to use this tool versus alternatives like minimax_agent_task or minimax_chat, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a structured implementation plan as JSON using MiniMax AI.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Description of the task to plan | |
| codebaseContext | No | Context about the codebase | |
| model | No | Model override (default: MINIMAX_DEFAULT_MODEL env var, typically M2.7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It fails to mention whether the plan is purely text-based, any constraints (e.g., token limits, speed), or side effects like modifications to the codebase. The description is too terse for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could include more essential information (e.g., output format, usage note) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should describe the structure of the generated plan. It does not, leaving agents uninformed about return values. For a planning tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all three parameters (task, codebaseContext, model). The description adds no additional meaning beyond 'Generate...plan as JSON', which aligns with the task parameter but does not augment parameter understanding. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a structured implementation plan as JSON, using a specific verb (Generate) and resource (implementation plan). It is distinguishable from siblings like minimax_generate_code, which focuses on code generation, but the description could be more explicit about what kind of plan is produced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as minimax_generate_code or minimax_chat. The description lacks context about prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track MiniMax usage across sessions for self-improvement. 'start': check mode (auto-called on first tool use if not explicit). 'end': record session + optional root cause notes. 'status': mid-session progress with trend analytics.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | start: check mode; end: record session; status: progress + trend | |
| notes | No | For 'end': root cause if target missed (required when missing) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that 'start' is auto-called on first use and 'end' records optional notes, which are behavioral traits. However, it does not mention data persistence, rate limits, or any side effects beyond logging.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the main purpose and briefly listing commands with context. It is efficient and avoids redundancy, though a more structured format (e.g., bullet points) could enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains commands but does not describe return values or output format, which is important for an agent to interpret results (e.g., what trend analytics look like). No output schema exists, so the description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already describes parameters. The description adds value by explaining 'start' is auto-called and 'status' provides trend analytics, going beyond the schema's brief descriptions. The 'notes' parameter's purpose for root cause is reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool tracks MiniMax usage across sessions, with three specific commands (start, end, status) and brief explanations of each. It distinguishes itself from sibling tools by focusing on session tracking for self-improvement, not general tasks or chat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each command (start auto-called, end for recording, status for progress), but does not explicitly provide guidance on when to use this tool vs alternatives or when not to use it. Sibling tools are distinct, so implied usage is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze an image using MiniMax AI vision. Supports URLs, local file paths, or base64 data URLs (JPEG/PNG/WebP, max 20MB).
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Question or instruction about the image | |
| imageSource | Yes | Image URL (HTTP/HTTPS), local file path, or base64 data URL | |
| model | No | Model override (default: MINIMAX_DEFAULT_MODEL env var, typically M2.7) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses supported image formats and size limits, and mentions the model override capability. However, it does not state whether the operation is read-only, what the output type is (e.g., text), or behavioral nuances like error handling or idempotence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two essential sentences: the first states the core purpose, and the second provides key constraints on inputs. No redundant text. It is front-loaded with the main action and uses efficient wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description omits any mention of what the tool returns (e.g., a text description, analysis results, or error messages). It also does not address prerequisites, potential errors, or limitations beyond format and size. This gap is significant for an image analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by specifying valid input formats for imageSource (URLs, local paths, base64, with format and size constraints), which goes beyond the schema's generic 'Image URL' description. For prompt and model, the description adds little beyond the schema, but the extra detail on imageSource justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze an image using MiniMax AI vision.' It distinguishes from sibling tools like minimax_chat and minimax_generate_code by specifically focusing on image analysis, and the mention of supported input formats further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as minimax_agent_task or minimax_chat. It does not specify use cases, prerequisites, or exclusions, leaving the agent to infer suitability from the tool's name and basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web using MiniMax AI. Returns results with titles, links, snippets, and related searches.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full burden. It mentions output fields but omits critical behavioral traits such as rate limits, authentication needs, handling of empty results, or whether the operation is read-only. The description is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences with no wasted words. Every sentence conveys distinct information: the tool's purpose and its output structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description covers purpose and basic output. However, it fails to specify result count, pagination, possible errors, or behavioral constraints. Given no output schema or annotations, more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single 'query' parameter described as 'Search query'). The description adds value by listing output fields but does not further elaborate on the query parameter itself. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (search the web using MiniMax AI) and what it returns (titles, links, snippets, related searches). It sufficiently distinguishes from sibling tools like minimax_chat or minimax_understand_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. No explicit context on when not to use it, prerequisites, or comparisons with sibling tools like minimax_plan or minimax_generate_code.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.5.1minimax_agent_task1 field changedInput schema / properties / model / enumPrevious value: -[
- "MiniMax-M2.5",
- "MiniMax-M2.7",
- "MiniMax-M2.5-highspeed",
- "MiniMax-M2.7-highspeed"
-]New value: +[
+ "MiniMax-M3",
+ "MiniMax-M2.5",
+ "MiniMax-M2.7",
+ "MiniMax-M2.5-highspeed",
+ "MiniMax-M2.7-highspeed"
+]minimax_chat1 field changedInput schema / properties / model / enumPrevious value: -[
- "MiniMax-M2.5",
- "MiniMax-M2.7",
- "MiniMax-M2.5-highspeed",
- "MiniMax-M2.7-highspeed"
-]New value: +[
+ "MiniMax-M3",
+ "MiniMax-M2.5",
+ "MiniMax-M2.7",
+ "MiniMax-M2.5-highspeed",
+ "MiniMax-M2.7-highspeed"
+]minimax_generate_code1 field changedInput schema / properties / model / enumPrevious value: -[
- "MiniMax-M2.5",
- "MiniMax-M2.7",
- "MiniMax-M2.5-highspeed",
- "MiniMax-M2.7-highspeed"
-]New value: +[
+ "MiniMax-M3",
+ "MiniMax-M2.5",
+ "MiniMax-M2.7",
+ "MiniMax-M2.5-highspeed",
+ "MiniMax-M2.7-highspeed"
+]minimax_plan1 field changedInput schema / properties / model / enumPrevious value: -[
- "MiniMax-M2.5",
- "MiniMax-M2.7",
- "MiniMax-M2.5-highspeed",
- "MiniMax-M2.7-highspeed"
-]New value: +[
+ "MiniMax-M3",
+ "MiniMax-M2.5",
+ "MiniMax-M2.7",
+ "MiniMax-M2.5-highspeed",
+ "MiniMax-M2.7-highspeed"
+]minimax_understand_image1 field changedInput schema / properties / modelAdded value: +{
+ "description": "Model override (default: MINIMAX_DEFAULT_MODEL env var, typically M2.7)",
+ "enum": [
+ "MiniMax-M3",
+ "MiniMax-M2.5",
+ "MiniMax-M2.7",
+ "MiniMax-M2.5-highspeed",
+ "MiniMax-M2.7-highspeed"
+ ],
+ "type": "string"
+}v1.5.0minimax_agent_taskminimax_chatminimax_cost_reportminimax_generate_codeminimax_planminimax_session_trackerminimax_understand_imageminimax_web_searchEach tool has a clearly distinct purpose: autonomous coding, chat, cost reporting, code generation, planning, session tracking, image analysis, and web search. No overlaps or ambiguity.
All tools follow the consistent pattern 'minimax_<descriptive_name>', using snake_case and a clear verb-noun structure throughout.
8 tools is well-scoped for a server providing multiple MiniMax AI capabilities. It covers a broad range of functionalities without being overwhelming or too sparse.
The tool set covers the major use cases of the MiniMax MCP server: autonomous task execution, chat, code generation, planning, cost tracking, session monitoring, image analysis, and web search. No obvious gaps given the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
No-data MCP handoff for local Claude Code to Codex harness moves. $49 lifetime.
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
AI LLM with Gemini, MiniMax, Replicate, OpenRouter. Vision, search, code review. USDC on Base.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wongo/my-minimax-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
