[dongtran16092006]

What happens

A tool call with more than one argument loses every argument after the first.

Reproduced with Qwen3.6-27B-UD-IQ2_XXS calling a 2-argument MCP tool
(entity_type: string, filters: array). What came back:

{
  "entity_type": "Note</parameter>\n<parameter=filters>\n[[\"updated_at\", \"between\", [\"2026-09-21T00:00:00Z\", \"2026-09-21T23:59:59Z\"]]]",
  "filters": null
}

The model's output was well-formed — the array is right there, intact. It ended up
inside entity_type because the parser never closed that argument.

Why

common/chat.cpp, the Qwen3.6 XML tool-call grammar:

auto arg_close  = p.tool_arg_close(p.literal("\n</parameter>\n"));
auto arg_string = p.rule("xml-arg-string",
    p.ac(p.tool_arg_string_value(p.until("\n</parameter>\n")) + arg_close, "\n</parameter>\n"));

The close delimiter is the exact literal "\n</parameter>\n". The template does ask for
that framing, and the model usually produces it — but not always. When it emits
Note</parameter> with no newline before the tag, until("\n</parameter>\n") does not
match at that position, so the scan continues to the next fully-framed occurrence and
swallows the <parameter=...> blocks in between. The first argument absorbs the rest of
the call and every later argument parses as null.

This is a partial failure, not a hard one: the call still returns, with silently wrong
arguments. In an agent loop the tool then errors, the model retries, emits the same
almost-right markup, and the loop does not terminate.

The change

Accept the looser spellings of the close tag as well, ordered longest first so the fully
framed form still wins wherever the model does produce it:

const std::vector<std::string> arg_close_delims = {
    "\n</parameter>\n", "\n</parameter>", "</parameter>\n", "</parameter>",
};
auto arg_close  = p.tool_arg_close(p.choice({ /* same four, as literals */ }));
auto arg_string = p.rule("xml-arg-string",
    p.ac(p.tool_arg_string_value(p.until_one_of(arg_close_delims)) + arg_close, arg_close_delims));

This matches what upstream already does for the </param> variant of the same grammar,
which closes on the bare tag with no newline requirement.

Effect

Same prompt, same model, same sampling, before and after:

	entity_type	filters
before	"Note</parameter>\n<parameter=filters>\n[[...]]"	null
after	"Note"	parsed as its own argument

Scope

Only the close delimiter is loosened. The open tag, the argument permutation and the JSON
branch are untouched. A value containing the literal text </parameter> would now close
early — that was already true for the framed form, and it is not a shape any JSON or
string argument produces on its own.

Not fixed here, and worth stating plainly: with the parser corrected, this model still
tends to write an object where the schema asks for a positional array
({"updated_at": "between", ...} instead of ["updated_at", "between", ...]). That is a
separate problem on the model side, not a parsing one.

[bri-prism]

With this change test-chat fails on prism. The generated grammar for the Qwen3.5 template no longer accepts the template's own canonical tool call: after \n</parameter> it expects < and rejects the \n before </function>. The ac rule ends at the first delimiter, so \n</parameter>\n becomes unreachable under grammar. Could you keep the canonical close reachable in the grammar (or apply the tolerant matching only in the parser), and add a test with the two-argument call from the description?

[dongtran16092006]

With this change test-chat fails on prism. The generated grammar for the Qwen3.5 template no longer accepts the template's own canonical tool call: after \n</parameter> it expects < and rejects the \n before </function>. The ac rule ends at the first delimiter, so \n</parameter>\n becomes unreachable under grammar. Could you keep the canonical close reachable in the grammar (or apply the tolerant matching only in the parser), and add a test with the two-argument call from the description?

Fixed in 0545b92: the grammar keeps the canonical close tag, and only the parser is tolerant. Added a test with the two-argument call from the description; test-chat passes.