[M3 Bug] Tool calling: array arguments always emitted as {"item": [...]} (100% reproducible, trigger independent of field name) + numeric arguments serialized as strings

Start by comparing the reported tool-call arguments with the JSON schemas in the issue, especially the array fields and numeric fields. The report does not identify repository files, tests, or an implementation entry point, so first locate where tool-call arguments are generated or validated. Done means reproducing the wrapped arrays and stringified numbers and confirming the emitted arguments match the declared schema types.

Summary

Reporting a second, always-reproducible variant of the item-wrapping bug in #29, plus a related number-serialization issue. Unlike #29 (15-35% intermittent, trigger narrowed to a property named item_ids together with a prompt that avoids the word "item"), this variant is 100% reproducible and fires on array fields whose names have nothing to do with item.

Two symptoms, both in the model's own tool-call arguments, before any client-side validation:

1. Array arguments are emitted as {"item": [...]} instead of a JSON array.
2. Numeric arguments are emitted as JSON strings ("maxCharacters": "6000").

Reproduction: 100% of calls, across three tools

Client: OpenAI-compatible chat-completions endpoint, agent harness. No sampling parameters set.

Tool / argument	Model	Shape emitted	Result
suggestions (array of objects)	MiniMax-M3.1-Flash	{"item": [...]}	schema validation rejects the call
suggestions (array of objects)	DeepSeek (same harness, same schema)	[...]	accepted
reviewed (array of strings)	MiniMax-M3.1-Flash	{"item": [...]}	schema validation rejects the call
reviewed (array of strings)	DeepSeek (same harness, same schema)	[...]	accepted
urls (array of strings)	MiniMax-M3.1-Flash	{"item": [...]}	schema validation rejects the call
urls (array of strings)	DeepSeek (same harness, same schema)	[...]	accepted

Same tool, same schema, same harness, same argument names - only the model differs. Over 1,500 MiniMax tool calls in our logs, every wrapped array used the key item; no other key ever appeared.

The trigger is not an item* property name

#29's 2026-07-28 update narrows the trigger to a property named item_ids (or similar item*) combined with a prompt that never uses the word "item", and reports that "realistic schemas with no item* property have been clean in everything I have run since - 26/26 calls on one real workload, and 56/56 on a larger schema".

That does not hold for the schemas below. None of the array fields is named item*:

{
  "type": "object",
  "properties": {
    "suggestions": { "type": "array", "items": { "type": "object", "properties": { "title": { "type": "string" } } } },
    "reviewed":    { "type": "array", "items": { "type": "string" } }
  },
  "required": ["suggestions"]
}

and:

{
  "type": "object",
  "properties": {
    "urls": { "type": "array", "items": { "type": "string" } },
    "maxCharacters": { "type": "number" }
  },
  "required": ["urls"]
}

For these, the item wrapping occurs on every single call (22/22 and 5/5 in our logs), and the field name is irrelevant. A separate card-rendering schema declaring "sections": {"type": "array"} explicitly - i.e. the shape is unambiguous - also wraps on every call.

One hypothesis worth considering: items is the JSON Schema keyword for array elements, and the model may be conflating that keyword with an output key whenever the schema uses items for element typing - which is to say, in essentially every array schema - regardless of the property's own name.

Number arguments are serialized as strings

A separate symptom in the same tool calls: numeric arguments arrive as JSON strings, so a number schema rejects them.

{ "server": "exa", "tool": "exa_web_fetch_exa",
  "arguments": { "maxCharacters": "6000", "urls": { "item": ["https://example.com/a", "https://example.com/b"] } } }

The schema declares maxCharacters as number; the client-side validator reports maxCharacters 需要 number，收到 string. A numResults: 2 argument is likewise emitted as "2".

The same harness, same tool, same argument, with DeepSeek emits "maxCharacters": 6000 as a native number and succeeds.

Why this matters beyond cosmetics

The malformed arguments are syntactically valid JSON, so nothing raises on parse. The failure surfaces only when the consumer validates against the schema, and by then the model's output has already been discarded and the call has to be retried. In an agent loop that means the tool never runs, the model sees a validation error instead of a result, and the surrounding task can fail or silently lose data. In our case one of the affected tools is the heartbeat's own log-recording call, so the patrol record was simply missing for those runs.

Questions

• Is this the same root cause as #29, and does the fix for #29 also cover the always-reproducible variant?
• Is there a supported strict / constrained-decoding mode for tool calls that would enforce the declared JSON types?
• Is the number-to-string serialization related to the same mechanism, or separate?

Notes on version

Observed with MiniMax-M3.1-Flash through an OpenAI-compatible gateway. Happy to supply raw request/response pairs and the exact schemas if useful.