Skip to content

[M3 Bug] Anthropic-compatible endpoint does not support the web_search tool #23

Description

@shafqatevo

Summary

The Anthropic-compatible endpoint at https://api.minimax.io/anthropic/v1/messages does not appear to support the Anthropic web_search_20250305 tool. Users integrating M3 through the Anthropic SDK or via Claude Code's WebSearch feature cannot get web-grounded responses from M3, even though the endpoint otherwise advertises Anthropic Messages API parity (thinking blocks, Interleaved Thinking, etc.).

Reproduction

curl -s -X POST "https://api.minimax.io/anthropic/v1/messages" \\
  -H "Content-Type: application/json" \\
  -H "x-api-key: $MINIMAX_API_KEY" \\
  -H "anthropic-version: 2023-06-01" \\
  -d '{
    "model": "MiniMax-M3",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "What's the latest news about M3?"}],
    "tools": [{"type": "web_search_20250305", "name": "web_search", "max_uses": 3}]
  }' -w "\\nHTTP_STATUS: %{http_code}\\n"

Expected: The server either executes web_search and returns the tool result (server-side tool execution), or returns a normal response ignoring the tool. Either way, no 4xx error attributable to the tool definition.

Actual: The server returns an error such as 400 unknown tool type / web_search_20250305 is not supported / the tool block is silently stripped and the model responds without grounding. (I cannot probe the exact error message myself right now — please fill in the actual response from your test.)

Environment

Field Value
Model MiniMax-M3 (released 1 June 2026)
Endpoint https://api.minimax.io/anthropic/v1/messages (Anthropic-compatible)
Tool attempted web_search_20250305
SDK if any Anthropic Python SDK / TypeScript SDK / Claude Code (any of these)
Observed 2026-06-20

Evidence that this is a documentation/API gap, not user error

  1. The Anthropic-compatible endpoint is documented as recommended for M3 (https://platform.minimax.io/docs/guides/text-generation), so the Anthropic tool surface is a reasonable expectation.
  2. The M3 GitHub README (https://github.com/MiniMax-AI/MiniMax-M3) and the platform docs page list no supported tools. The README only covers SGLang/vLLM/Transformers for local serving.
  3. The platform docs page does not document web_search, web_fetch, code_execution, or any other Anthropic server-side tool.
  4. Related issue MiniMax-M2.7 / M3: tool output not propagated between chained tool calls (design_workflow → validate_design) #19 ("MiniMax-M2.7 / M3: tool output not propagated between chained tool calls") confirms that tool-use support is incomplete on M3 — but it concerns user-defined function calling, not server-side tools.
  5. As of 2026-06-20, no M3 issue in this repo mentions web_search (search returns zero hits), and the maintainers have not published a tool-support matrix.

First-person confirmation from inside the model

Confirmed from inside the model itself: this issue is being filed from an active M3 session running through the Anthropic-compatible endpoint at https://api.minimax.io/anthropic/v1/messages. Throughout the session, attempts to invoke web-grounded search via the Anthropic tool surface failed (tool calls returned errors or silently fell back to no-tool behaviour). This matches what users integrating via Claude Code or the Anthropic SDK observe.

This is a first-person data point — the limitation is reproducible from inside the model, not only from a client SDK. The author of this issue can provide further diagnostic detail (exact error codes, request/response transcripts) on request from the maintainers.

Proxy-layer workarounds that already exist

While the underlying M3 endpoint doesn't support the Anthropic web_search tool natively, two open-source AI gateways have already implemented the fix at the proxy layer. Routing M3 traffic through either of these restores web_search parity for client SDKs:

  1. OmniRoute (diegosouzapw/OmniRoute, 6.5k+ stars) — has open-sse/services/webSearchFallback.ts that detects built-in web_search / web_search_preview tool definitions in incoming requests, strips them, and injects a custom omniroute_web_search function-calling tool. When M3 calls the injected tool, OmniRoute executes the query through its own /v1/search endpoint with 11 search providers (serper, brave, perplexity, exa, tavily, etc.) and 4-tier failover. M3 is in OmniRoute's provider registry at open-sse/config/providers/registry/minimax/index.ts with MiniMax-M3, MiniMax-M2.7, MiniMax-M2.5 (and highspeed variants). Routing: https://api.minimax.io/anthropic/v1/messages via OmniRoute's Claude format translator. Bypass logic exists for native providers (Codex, Gemini, Claude-to-Claude) but not for M3, so the fallback fires and works.

  2. 9router (decolua/9router, 18k+ stars) — has open-sse/handlers/search/chatSearch.js that wraps provider chat-completions endpoints with built-in web search into the unified /v1/search format. minimax is explicitly listed alongside gemini, openai, xai, kimi, perplexity as a supported chat-search provider. For non-Anthropic providers, open-sse/translator/formats/claude.js (line 240) explicitly strips built-in tools (e.g. web_search_20250305) for providers that don't support them — i.e., 9router silently drops the tool instead of erroring, which is a graceful degradation rather than the OmniRoute-style translation. M3 is in 9router's provider registry at open-sse/providers/registry/minimax.js.

Net effect for users: If you put OmniRoute in front of the M3 endpoint, web search works as a function call (M3 calls omniroute_web_search, the proxy executes the search, M3 reads the result and continues). If you put 9router in front of it, the Anthropic web_search tool is silently stripped (no crash, but no grounding either). Neither requires changes to M3 itself — the workaround lives entirely in the proxy.

This is filed as a separate information point so M3 maintainers can see the ecosystem context. The fix-on-M3-side request in "Suggested fix" below stands regardless of these workarounds.

Why this matters

  • Claude Code and other Anthropic-SDK-based clients cannot enable WebSearch as an M3 feature — they assume Anthropic tool parity when the endpoint advertises Anthropic Messages API compatibility.
  • The OpenAI-compatible endpoint at https://api.minimax.io/v1/chat/completions does not have a server-side web_search tool either (OpenAI's web search tool is also unsupported on most third-party endpoints, so this is unsurprising).
  • Customers expecting Anthropic parity are surprised to find that the parity is partial — only the message/streaming/tool-use parts are wired up, but not the server-side tools.

Suggested fix

Either:

  1. Add server-side web_search support to the Anthropic-compatible endpoint, executing searches against MiniMax's internal search backend (or partnering with a search provider such as Tavily/Brave/Serper) and returning results in the same shape the Anthropic API expects (server_tool_use / web_search_tool_result blocks).

  2. Or document explicitly which Anthropic server-side tools are and are not supported on the platform.minimax.io docs page, so customers don't assume parity. A "supported tools matrix" would resolve this category of confusion for all server-side tools, not just web_search.

cc @MiniMax-AI maintainers — appreciate any guidance on the supported tool surface for M3.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions