MiniMax M3 Tool Calling Guide
Yes, MiniMax M3 supports tool calling.
MiniMax positions M3 specifically for coding and agentic workloads that involve autonomous task decomposition, tool invocation, and multi-step reasoning. The model also supports up to a 1M-token context window, which is designed to help with long-running agent and coding workflows.
But tool calling does not mean MiniMax M3 directly executes your APIs or functions.
The actual flow is:
Define tools
↓
Send tools to MiniMax M3
↓
M3 returns tool_calls
↓
Your application executes the function
↓
Send the result back to M3
↓
M3 continues or returns a final answer
Understanding that loop is the key to using MiniMax M3 correctly in an agent.
What Is MiniMax M3 Tool Calling?
A normal LLM request looks like this:
User → Model → Answer
The model receives text and returns text.
That works for questions the model can answer from the context it already has.
But suppose the user asks:
What’s the weather in Tokyo right now?
The model should not invent current weather data.
With tool calling, you can give M3 access to a function such as:
get_weather(city)
The workflow becomes:
User
↓
MiniMax M3
↓
get_weather(city="Tokyo")
↓
Your weather API
↓
Current weather result
↓
MiniMax M3
↓
Final answer
M3 decides which tool should be used and what arguments it needs.
Your application decides what the tool actually does.
MiniMax M3 Tool Calling API
MiniMax’s current text-generation API documentation includes MiniMax-M3 as a supported model and exposes:
tools
tool_choice
tool_calls
The documented endpoint is:
POST /v1/text/chatcompletion_v2
and the current M3 model identifier is:
MiniMax-M3
MiniMax documents two tool_choice modes:
auto
none
With auto, M3 decides whether it needs to call a tool.
With none, tool use is disabled.
Step 1: Define a Tool
Suppose we want M3 to check weather information.
We first describe the function to the model:
{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get the current weather for a city",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "The city to get weather for"
}
},
"required": ["city"]
}
}
}
MiniMax currently supports function as the tool type. Its API schema requires a function name, description, and parameter definition.
The quality of this schema matters.
If your tool description is vague, the model has less information about when it should call it.
Compare:
Bad:
Get data.
with:
Better:
Get the current weather, temperature, and conditions for a specified city.
Use this tool when the user asks about current or future weather.
The second description gives the model much clearer tool-selection guidance.
Step 2: Send the Tools to MiniMax M3
A simplified Python request looks like this:
import requests
url = "https://api.minimax.io/v1/text/chatcompletion_v2"
headers = {
"Authorization": "Bearer YOUR_MINIMAX_API_KEY",
"Content-Type": "application/json"
}
payload = {
"model": "MiniMax-M3",
"messages": [
{
"role": "user",
"content": "What's the weather in Tokyo?"
}
],
"tools": [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "Get the current weather for a city",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string"
}
},
"required": ["city"]
}
}
}
],
"tool_choice": "auto"
}
response = requests.post(
url,
headers=headers,
json=payload
)
data = response.json()
print(data)
The current MiniMax API documentation explicitly lists MiniMax-M3 and the tools and tool_choice request fields for this endpoint.
Step 3: Read M3’s Tool Call
If M3 decides that a tool is necessary, the assistant response can include a tool_calls array.
MiniMax documents each call with:
id
type
function.name
function.arguments
Conceptually, the result can look like this:
{
"tool_calls": [
{
"id": "call_123",
"type": "function",
"function": {
"name": "get_weather",
"arguments": "{\"city\":\"Tokyo\"}"
}
}
]
}
The important point is:
M3 has not executed anything yet.
It has generated a structured request saying:
Please run
get_weatherwithcity="Tokyo".
Your application now needs to parse the arguments and run the actual function.
Step 4: Execute the Tool in Your Application
For example:
import json
tool_call = data["choices"][0]["message"]["tool_calls"][0]
function_name = tool_call["function"]["name"]
arguments = json.loads(
tool_call["function"]["arguments"]
)
if function_name == "get_weather":
result = get_weather(**arguments)
Your own function might call a real weather service and return:
{
"city": "Tokyo",
"temperature": 29,
"condition": "Rain"
}
This result comes from your tool, not from MiniMax.
That distinction is essential when building production agents.
Step 5: Return the Tool Result to M3
Now the conversation needs to continue.
Your application should preserve M3’s assistant message that contained the tool call and add the result from your function to the conversation.
The model can then use the real result to generate the final answer.
MiniMax specifically documents that multi-turn function-calling conversations should preserve the complete assistant response, including its tool-call information, so reasoning continuity is not lost.
Conceptually, the history becomes:
User:
What's the weather in Tokyo?
Assistant:[tool call: get_weather(city=”Tokyo”)]
Tool: Tokyo: 29°C, Rain Assistant: It’s currently 29°C and raining in Tokyo.
This is the basic agent loop.
Why You Must Preserve the Tool-Call History
This is one of the most important implementation details in MiniMax’s documentation.
When a tool call happens, don’t keep only the visible text.
Keep the complete assistant message.
Why?
Because the next model request needs to understand:
- Which tool it requested
- What arguments it generated
- Which result belongs to which call
- What step of the task it is currently on
If you discard that state, multi-step tool workflows can become inconsistent.
This becomes increasingly important as an agent performs more calls.
Using More Than One Tool
Real agents usually expose more than one function.
A coding agent might provide:
read_file
search_code
write_file
run_command
run_tests
git_diff
A business assistant might provide:
search_customer
get_order
issue_refund
create_ticket
send_email
The user doesn’t have to specify which function should be called.
With tool_choice="auto", the model can select from the available tools based on the request.
For example:
User:
Find why the login tests are failing and fix the issue.
A coding agent could perform:
search_code
↓
read_file
↓
run_tests
↓
read_file
↓
write_file
↓
run_tests
↓
git_diff
This is where tool calling turns into an agent workflow.
Why MiniMax M3 Is Built for This
Tool calling itself is not unique to M3.
GPT, Claude, Gemini, Qwen, GLM, and many other models also support tools.
The reason M3 is interesting is how strongly MiniMax focuses the model on long-running tool execution.
MiniMax says M3 has autonomous task decomposition, tool invocation, and multi-step reasoning capabilities.
The company also published a long-running CUDA optimization experiment in which M3 completed:
147 benchmark submissions
1,959 tool calls
during an approximately 24-hour autonomous optimization workflow.
That doesn’t mean every application should run thousands of tool calls.
It demonstrates the kind of long-horizon behavior MiniMax is targeting.
MiniMax M3 Context Window
M3 supports up to 1M tokens of context.
MiniMax states that its M3 API supports up to 1M context with a guaranteed minimum infrastructure context of 512K tokens.
Why does that matter for tool calling?
Because long agents accumulate context.
After many steps, the model may need to remember:
- Original user instructions
- System instructions
- Previous tool calls
- Tool results
- Source code
- Files
- Errors
- Plans
- Intermediate decisions
For example:
Initial prompt
+ repository context
+ 20 tool calls
+ 20 tool results
+ test output
+ modified code
+ additional user instructions
All of this consumes context.
A large context window gives M3 more capacity for long-running workflows without immediately discarding earlier state.
MiniMax M3 for Coding Agents
Coding is one of the clearest use cases for M3 tool calling.
The model itself doesn’t directly edit your repository.
Instead, your agent framework exposes tools such as:
read_file(path)
write_file(path, content)
search_code(query)
run_command(command)
run_tests()
M3 can then use those tools to work through the task.
For example:
Fix the authentication bug in this project.
The workflow may become:
1. Search authentication code
2. Inspect relevant files
3. Run failing tests
4. Identify likely cause
5. Modify implementation
6. Run tests again
7. Inspect errors
8. Make another change
9. Verify the final result
This is much closer to actual software engineering than a one-shot prompt such as:
Write a login function.
MiniMax explicitly positions M3 around coding agents and automated workflows rather than simple code completion alone.
MiniMax M3 Is Also Multimodal
M3 is natively multimodal.
MiniMax says multimodal training was included from the beginning rather than added as a separate adapter later, and the model supports visual understanding as part of its agent capabilities.
This can extend tool-based agents beyond text.
For example:
Inspect screenshot
↓
Understand UI state
↓
Determine next action
↓
Call computer/tool action
↓
Inspect result
↓
Continue
That is useful for browser agents, computer-use tasks, visual QA, and multimodal development workflows.
MiniMax M3 Tool Calling vs Simple Function Calling
It’s useful to separate two concepts.
Simple Function Calling
User asks question
→ model selects one tool
→ tool returns data
→ model answers
Example:
What's the weather in Tokyo?
Agentic Tool Calling
User provides a goal
→ model plans
→ calls tool
→ evaluates result
→ calls another tool
→ changes plan
→ calls more tools
→ verifies result
→ completes goal
Example:
Find the bug in this repository, fix it, and verify the tests pass.
M3 is much more interesting in the second category.
Common MiniMax M3 Tool Calling Mistakes
1. Expecting M3 to Execute the Function
It doesn’t.
M3 generates the tool request. Your application executes it.
2. Not Preserving the Assistant Tool-Call Message
For multi-turn workflows, preserve the complete assistant response associated with the tool call. MiniMax specifically calls this out in its compatibility documentation.
3. Using Vague Tool Descriptions
Don’t define:
do_task
when you can define:
search_customer_by_email
Clear tools give the model a better chance of choosing correctly.
4. Giving Tools Too Much Permission
If you expose:
run_command
your application should still enforce permissions, validation, sandboxing, and safety rules.
The model should not be the final authority on what your infrastructure is allowed to execute.
5. Treating Long Context as Unlimited Memory
A 1M context window is large, but it is still finite.
Long agent runs should manage context deliberately rather than continually appending everything forever.
Can MiniMax M3 Work with OpenAI-Compatible Workflows?
MiniMax provides OpenAI-compatible API support for its text-model ecosystem, and its tool-calling schema follows familiar concepts such as tools, assistant tool_calls, and tool-result messages.
MiniMax’s API documentation is actively evolving around M3, so for production integrations you should always use the current M3 API documentation as the source of truth for the exact endpoint and supported fields.
Using MiniMax Models in a Multi-Model Agent Stack
If your entire agent is built around MiniMax, a direct MiniMax integration can make sense.
But many agent developers test several models.
You might want to compare:
- MiniMax
- GLM
- Qwen
- DeepSeek
- Claude
- GPT
- Gemini
Tool-calling quality can differ depending on your actual schemas and workflows.
One model may be better at selecting tools.
Another may be better at coding.
Another may be cheaper for long agent loops.
This is where a unified model gateway becomes useful.
Using TokenHub for Agent Development
TokenHub provides an OpenAI-compatible API gateway for supported models and documents integrations with tools such as Claude Code, Codex, Cursor, Cline, Aider, OpenCode, and other developer agents.
Its OpenAI-compatible Base URL is:
https://us-api.tokenhub.com/v1
Rather than rewriting your entire agent architecture for every model provider, you can keep the common API layer and select models from TokenHub’s current catalog.
This is particularly useful when evaluating tool-calling models because you can run the same agent, same tool definitions, and same tasks against different supported models.
Always use the exact model ID shown in TokenHub’s live model list.
Is MiniMax M3 Good for Tool Calling?
MiniMax M3 is clearly designed for tool-heavy agent workflows.
The strongest reasons to evaluate it are:
- Native tool invocation
- Multi-step reasoning
- Strong coding focus
- Up to 1M context
- Long-running agent design
- Native multimodal capability
Whether it is the best tool-calling model for your product still depends on your own agent.
A customer-service agent and a coding agent may prefer different models.
The right evaluation is not:
Does M3 support tools?
It does.
The better question is:
Can M3 reliably complete my actual workflow using my actual tools at an acceptable cost and latency?
FAQ
Does MiniMax M3 support tool calling?
Yes. MiniMax’s current API documentation supports tools and tool_choice for MiniMax-M3.
What is the MiniMax M3 model ID?
The current direct API model name is:
MiniMax-M3
What values does MiniMax M3 support for tool_choice?
The current text API documents:
auto
none
Does MiniMax M3 execute tools itself?
No. The model generates the tool call and arguments. Your application executes the external function.
What does MiniMax M3 return when it wants to call a tool?
The assistant response can include a tool_calls array containing a tool-call ID, function name, and JSON-formatted arguments.
Does MiniMax M3 support a 1M context window?
Yes. MiniMax says M3 supports up to 1M tokens of context.
Is MiniMax M3 suitable for coding agents?
Yes. Coding and agentic tasks are two of M3’s primary target workloads.
Build Your Agent Around the Workflow, Not One Provider
MiniMax M3’s tool calling is useful because it is part of a broader agent design: the model can decompose tasks, invoke tools, process results, and continue across long workflows.
For a production agent, however, it is still worth testing more than one model.
TokenHub provides a unified API layer for supported models, allowing you to compare different agent-capable LLMs without rebuilding your integration around every provider.
Recommended internal links
- Link TokenHub to the homepage or model catalog.
- Link OpenAI-compatible API to TokenHub API Docs.
- Later link Best Chinese LLMs for Agents and Tool Calling to the corresponding Blog.
- Link relevant GLM, Qwen, DeepSeek, or Kimi names to their TokenHub model pages when available.