vllm - 💡(How to fix) Fix MiniMax-M2.1/M2.5/M2.7 tool-call arguments cannot safely contain raw </parameter> delimiters

Problem

MiniMax-M2-series models use an XML-style tool-call format internally, with parameters encoded like:

<parameter name="content">...</parameter>

When a string argument itself contains the raw delimiter text </parameter>, the argument becomes ambiguous. A common example is a file-writing tool asked to write XML content:

<parameter>
  <hello></hello>
</parameter>

The parser cannot reliably distinguish a literal </parameter> inside the argument value from the protocol delimiter closing the tool parameter. This can truncate tool-call arguments, especially for write_file-style tools.

Official MiniMax API behavior

I tested the official MiniMax API at https://api.minimaxi.com/v1, forcing a single write_file(path: string, content: string) tool call.

Expected content:

<parameter>
  <hello></hello>
</parameter>

Observed behavior by model:

Example observed MiniMax-M2.7 non-streaming tool arguments:

{"content":"<parameter>\n  <hello></hello>","path":"test.xml"}

Example observed MiniMax-M2.7 streaming joined tool-argument deltas:

{"content": "<parameter>\n  <hello></hello>\n", "path": "test.xml"}

Both official API paths lose the literal closing </parameter> from the requested file content for the affected models.

I also tested XML-escaped content with MiniMax-M2.7:

<parameter>
  <hello></hello>
</parameter>

The official API preserved that escaped text as-is in the tool argument. It did not decode it back to raw XML.

Why this is hard to fix parser-side

For streaming, the prefix can be inherently ambiguous. After receiving:

<parameter name="content"><parameter>
  <hello></hello>
</parameter>

there are at least two possible continuations with different meanings:

</invoke>

means the </parameter> already closed the tool parameter, while:

</parameter></invoke>

means the first </parameter> was literal content and the second closes the tool parameter.

A stack-aware XML scanner only works for a narrow class of well-balanced XML values. It is not sound for arbitrary text content, because literal <parameter> / </parameter> strings can appear in user data and should not necessarily be interpreted as nested protocol structure.

Suggested vLLM handling

This may not be a vLLM parser bug in the usual sense, because the official MiniMax API shows the same delimiter-collision behavior for MiniMax-M2.1, MiniMax-M2.5, and MiniMax-M2.7, while MiniMax-M2 surprisingly preserves the same raw XML content in this test. It would be useful for vLLM to document this MiniMax tool-call limitation and avoid parser-side heuristics that silently reinterpret arbitrary raw text.

Potentially safe guidance:

• Raw XML/tool-protocol delimiters inside affected MiniMax string arguments are not reliably representable.
• Users/tools should escape or encode arbitrary file content before passing it through XML-style MiniMax tool calls.
• A robust model/protocol-side fix would require an explicit escaping contract, JSON-native tool-call arguments, CDATA with a clear contract, or length-prefixed argument values.

vLLM parser context

The current vLLM MiniMax-M2 parser also uses XML-style delimiters for <invoke> and <parameter> blocks, so it has the same class of ambiguity when raw argument values contain protocol delimiter strings.