If by “MiniMax tool” you mean a model that can call functions in your application, MiniMax’s API documentation identifies M3.1-Flash and M3 as models that can trigger tool calls. Its tool-use guide describes custom function calling for M3.1-Flash. That makes M3.1-Flash a reasonable first model to evaluate—not a proven winner for every workload. (API overview; tool-use guide)
“Tool” can also refer to MiniMax’s server-side tools. The available documentation identifies server tools as a separate feature and says the capability is in beta. Check the current server-tools documentation for its supported tools and interfaces before relying on a particular feature. (Server Tools)
Which MiniMax models support tool calling through the API?
MiniMax’s API overview names M3.1-Flash and M3 as API models that can trigger tool calls. The dedicated tool-use guide covers M3.1-Flash. These are API-capability statements, distinct from the self-hosting guide’s tool-call entry for M2.7. The cited documentation does not establish a universal quality or latency winner between M3.1-Flash and M3. (API overview; tool-use guide; self-hosting guide)
Practical shortlist:
- M3.1-Flash: Start here if you want a model with a dedicated tool-use guide.
- M3: Also listed by MiniMax as an API model that can trigger tool calls. Test it against your own tasks before choosing.
The available documentation does not establish which model will perform better for your workload. Evaluate both, if appropriate, using your actual tool definitions, expected arguments, failure cases, and multi-turn tasks.
Note on M2.7: check the migration schedule
MiniMax’s self-hosting guide lists tool calls for M2.7 and names an SGLang OpenAI-compatible Chat Completions deployment path. That supports a self-hosted use case; it does not by itself establish managed API availability or a tool-calling workflow. (Self-hosting guide)
A MiniMax model notice gives October 19, 2026, as the date M2.5 and M2.7 became unavailable to new users, and November 18, 2026, as their scheduled retirement date. The available notice details here do not establish what happens to every existing account or precisely how M Plan and Token Plan requests are handled. If an integration depends on M2.7, check the current notice for your access plan and confirm the replacement behavior before the retirement date. (Model List / notice)
How API tool calling works
With custom function calling, your application provides a list of functions and their input schemas. The model may return a tool call; your application executes the function and sends the result back so the model can continue. MiniMax’s tool-use documentation identifies function names, descriptions, and parameter schemas as parts of tool definitions. It also names response fields such as tool_calls or tool_use. (Tool-use guide)
At a high level, the exchange is:
- Send a request with the model, conversation, and function definitions.
- Check whether the model response contains a tool call; validate its proposed arguments.
- Execute the function in your application, applying your own authorization and input checks.
- Return the function result using the result-submission format for the API interface you selected.
- Continue the conversation with the model, which may return a final answer or another tool call.
This describes the control flow, not a runnable MiniMax request. The documentation text available for this revision does not provide a complete, interface-specific continuation example with the exact result-submission and conversation fields. Check the matching current API reference for those details and authentication; do not mix request formats between interfaces. MiniMax documents separate OpenAI-compatible and Anthropic-compatible API routes. (Model Invocation; Anthropic SDK)
For an order-status function, for example, your application—not the model—should authorize access to the requested order, call the order system, and return only the permitted result. Treat the model’s proposed tool call as input to validate, not as authorization to perform an action.
Custom functions versus server-side tools
Use custom function calling when the model needs to interact with systems your application controls, such as an internal database or an approved business action. Your application runs the function and handles the result.
MiniMax also documents server tools as a separate, beta capability. The available documentation here does not establish the exact tool identifier, supported API interfaces, or execution details, so check the current server-tools reference before building around a specific server-side feature. (Server Tools)
MiniMax API or self-hosting?
| Route | Consider it when | Trade-off |
|---|---|---|
| MiniMax API | You want a managed service, elastic scaling, or MiniMax Platform features. | Verify current model availability, tool support, interface, and billing for your use case. |
| Self-hosting | You want to operate open weights on infrastructure you control and can run the service. | You take responsibility for capacity, scaling, monitoring, recovery, upgrades, and security. Hardware references in a self-hosting guide are not managed-API requirements. |
MiniMax’s self-hosting guide calls for authentication, TLS, network isolation, and remote-media access restrictions before exposing a quickstart service. It also says open-weight models may have different licenses. Check the target model’s license and acceptable-use terms before deployment or commercial use. (Self-hosting guide)
API pricing: verify the current rates before estimating
The available pricing details do not establish enough context to responsibly quote a current M3.1-Flash rate here. Before budgeting, check MiniMax’s live pricing page for the currency, billing unit, input and output rates, any caching rates, and the applicable model or plan. Do not treat a rate as comparable unless its usage scope is clear. (Pricing Overview)
For a basic token-charge estimate once you have verified the applicable rates, calculate input and output separately:
- Input charge = input tokens ÷ billing-unit token count × input rate
- Output charge = output tokens ÷ billing-unit token count × output rate
- Add the two charges, then account for any separately priced usage that applies.
Selection checklist
Before choosing a MiniMax tool-using setup:
- Confirm whether you need custom API function calls, server-side tools, or a standalone product.
- For API tool calling, evaluate M3.1-Flash or M3 using current model and interface documentation.
- Follow the tool schema and result-handoff format for the specific API interface you select; the high-level flow above is not an exact request template.
- Test argument validation, tool errors, and multi-turn continuation on representative tasks.
- Verify current rates and their billing scope before making a budget.
- If self-hosting, confirm the hardware baseline, license, deployment maturity, access controls, and operational responsibilities.
- If using M2.7, check the current retirement notice and confirm account-specific migration behavior.
Bottom line: For a new API integration that needs custom tool calling, start by evaluating M3.1-Flash; M3 is also listed for API tool calls. Treat server tools as a separate beta capability, and verify the exact interface details, pricing, and any M2.7 migration conditions before committing.
Sources
API Overview - MiniMax API Docs
Tool Use & Interleaved Thinking - MiniMax API Docs
Model Invocation - MiniMax API Docs
Anthropic SDK - MiniMax API Docs
Server Tools - MiniMax API Docs