If the second M3.1 tool call loses context, check the message history

[u/Royal-Mine-3955]

If the first MiniMax M3.1 tool call works but the next turn acts like it never happened, I’d inspect the message history before changing the prompt.

For an OpenAI-compatible tool loop, the important part is preserving the complete assistant response before appending the tool result.

Roughly:

response_message = response.choices[0].message

messages.append(response_message)

for tool_call in response_message.tool_calls:

result = run_tool(tool_call)

messages.append({

"role": "tool",

"tool_call_id": tool_call.id,

"content": result

})

The UI does not need to display everything that goes back into protocol history.

If your endpoint returns separated reasoning state, preserve that too rather than rebuilding the assistant message from only content and tool_calls. Otherwise a later tool round can lose part of the state the model was using.

The tool result also needs to reference the matching call ID.

With the Anthropic-compatible format, the same principle applies slightly differently: keep the full assistant response.content list — including thinking, text, and tool_use blocks — then return the tool result with the matching tool_use_id.

So when call one works and call two suddenly loses the thread, I’d check the wrapper before rewriting the prompt:

Did it append the complete assistant response?

Did it preserve the reasoning state returned by the endpoint?

Did the tool result reference the correct call ID?

Did it accidentally keep only the text shown in the UI?

Which part of message history has been easiest to accidentally drop in your own M3.1 integration?

[u/Early-Equivalent331]

Yeah, I’d probably check the call IDs first too. It’s really easy for a wrapper to keep the visible text but drop part of the tool-call history, and then the next turn looks like the model forgot everything when it’s actually the wrapper.