[v3.0.48] Removed mavis CLI but did not add native tool injection — configured MCP servers unreachable from agent

[Bigzhangbig]

Summary

In MiniMax Code v3.0.48 (build 3.0.48.81, macOS Apple Silicon), the
mavis CLI binary was removed. The 12 MCP servers configured in
~/.mavis/mcp/mcp.json (all enabled: true, configured: true) are no
longer reachable from the agent:

• The previous escape hatch was mavis mcp call <server> <tool> — the
  binary itself is gone (which mavis returns nothing; the symlink
  ~/.mavis/bin/minimax is broken and points at a path that no longer
  exists in the app bundle).
• The replacement path is unclear. Only the built-in matrix server's
  ~17 tools get hot-loaded into the agent's system prompt. The other
  11 configured servers are silently absent from the agent's tool
  surface, with no error and no warning in the UI.

For a v3.0.48 user, this means the mcp.json file is effectively
write-only for any non-builtin server: it loads, parses, gets
enabled: true from the daemon, and the agent then pretends it
doesn't exist.

Reproduction — generic by transport + auth

I configured a mix of MCP servers covering the two transports and two
auth schemes the spec supports. Every one of them is reachable when I
drive the JSON-RPC protocol manually. None of them is reachable from
the agent.

1. stdio transport, no auth (e.g. npx -y <pkg>)

"<server>": {
  "command": "npx",
  "args": ["-y", "<npm-package>@<version>"],
  "enabled": true, "configured": true
}

Manual smoke test (the MCP server is fully functional):

(echo '{"jsonrpc":"2.0","id":1,"method":"initialize",...}'; sleep 1;
 echo '{"jsonrpc":"2.0","id":2,"method":"tools/list",...}'; sleep 1
) | npx -y <npm-package>@<version>
# → valid initialize response + tools/list returns N tools

The MCP server works. The agent has 0 of those tools in its context.

2. stdio transport, no auth (e.g. uvx <pkg>)

"<server>": {
  "command": "uvx",
  "args": ["<python-package>"],
  "env": { "SOME_API_KEY": "<api-key>" },
  "enabled": true, "configured": true
}

Same pattern — uvx <python-package> started in a terminal with
stdin JSON-RPC produces a valid initialize response and a populated
tools/list. The agent sees nothing.

3. streamable-http transport, bearer token auth

"<server>": {
  "url": "https://<host>/<path>",
  "auth": { "type": "bearer", "token": "<bearer-token>" },
  "enabled": true, "configured": true
}

Manual smoke test:

curl -X POST "https://<host>/<path>" \
  -H "Authorization: Bearer <bearer-token>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize",...}'
# → 200 OK, valid initialize response with serverInfo
curl ... -d '{"jsonrpc":"2.0","id":2,"method":"tools/list",...}'
# → returns the full tool list
curl ... -d '{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"<tool>",...}}'
# → 200 OK with real results

The MCP server is fully functional over the network. The agent has 0
of those tools in its context.

4. streamable-http transport, custom header / API key

"<server>": {
  "url": "https://<host>/<path>",
  "headers": { "X-API-Key": "<api-key>" },
  "enabled": true, "configured": true
}

Same story: curl with the custom header returns a valid initialize
response and a populated tools/list. The agent sees nothing.

5. streamable-http transport, OAuth2 client credentials

"<server>": {
  "url": "https://<host>/<path>",
  "auth": {
    "type": "oauth2",
    "clientId": "<oauth-client-id>"
  },
  "enabled": true, "configured": true
}

For OAuth2 servers the manual curl test obviously won't get past
the auth dance, but the server is reachable (TCP / TLS handshake
succeeds) and the agent should at minimum trigger the OAuth flow
itself. It does not — the server is silently absent.

Impact

Across the 11 non-builtin configured servers (spanning all four
patterns above), the agent has no way to invoke a single one of
their tools. There is no CLI fallback (binary removed in 3.0.48.81),
no function-definition injection for non-builtin servers, and no UI
surface that lists "configured but unreachable MCPs" as a warning.

Related

• MiniMax-AI/MiniMax-MCP issue [Bug for MCP&API]: 配置Minimax CodePlan MCP后导致openCode启动失败 #46: "Configuring MiniMax CodePlan
  MCP causes openCode startup failure" — same class of problem (MCP
  config not reflected in the agent's tool surface).
• MiniMax Agent 2.0 had a "Customize MCP" affordance (natural
  language → agent searches GitHub for an MCP wrapper). That was
  removed in 3.0.48 with no replacement.

Expected fix (any of the following would unblock us)

1. Restore the mavis CLI binary with
   mavis mcp call <server> <tool> [--args ...], so the agent (or a
   worker session) can shell out to any configured MCP without
   having to hand-roll curl / bunx JSON-RPC every time.
2. Hot-load all enabled+configured MCP servers into the agent's
   system prompt as function definitions, the same way matrix is
   loaded today. A mcp__<server>__<tool> namespace is fine; we just
   need the function definitions to show up.
3. At minimum: list the configured servers in the system prompt
   (server name + tool count + auth scheme) so the agent at least
   knows they exist, and document the manual invocation path.

Option 2 is the right fix. Option 1 is the minimum viable fix.
Option 3 is a stopgap.