</details>


### 🐛 Describe the bug

Description
When a tool schema includes an array of objects as a parameter (e.g. questions: array<object>), the qwen3xml_tool_parser delivers the argument to clients as a JSON-encoded string instead of a native JSON array. Any client that schema-validates tool call arguments receives a type error.

The model correctly constructs the array in its reasoning trace — it understands the schema and validates it internally — but the parser fails to convert the value correctly before forwarding to the client.

Root Cause
In qwen3xml_tool_parser.py, the StreamingXMLToolCallParser._end_element method handles "deferred" parameters (array and object types) by accumulating the raw parameter text and then parsing it at </parameter> time.

The parsing is done with ast.literal_eval:

# _end_element, inside `if self.defer_current_parameter:` block
parsed_value = ast.literal_eval(raw_for_parse)
output_arguments = json.dumps(parsed_value, ensure_ascii=False)
ast.literal_eval requires Python literal syntax. Qwen3.6-27B generates standard JSON, which uses lowercase true, false, and null. These are not valid Python literals:

>>> import ast
>>> ast.literal_eval('[{"multiSelect": false}]')
# ValueError: malformed node or string on line 1
When ast.literal_eval raises, the except block runs:

except Exception:
    # Fallback: output as string as-is
    output_arguments = json.dumps(raw_text, ensure_ascii=False)
    parsed_value = raw_text
json.dumps on a plain string produces a JSON-encoded string. The client receives "questions": "\n[{...}]\n" (a string) instead of "questions": [{...}] (a native array).

This affects any parameter typed as array, arr, or sequence in the tool schema — the _preprocess_xml_chunk method sets need_defer = True for all complex types, unconditionally routing them through the ast.literal_eval path.

Steps to Reproduce
Start vLLM with --tool-call-parser qwen3_xml and any Qwen3 model, then send a request with a tool whose schema includes an array-of-objects parameter:

curl http://127.0.0.1:8001/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer none" \
  -d '{
    "model": "Qwen3.6-27B",
    "messages": [{"role":"user","content":"Ask me one question about my color preference"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "AskUserQuestion",
        "parameters": {
          "type": "object",
          "properties": {
            "questions": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "question":    {"type": "string"},
                  "header":      {"type": "string"},
                  "options":     {"type": "array", "items": {"type": "object",
                                   "properties": {"label":       {"type": "string"},
                                                  "description": {"type": "string"}}}},
                  "multiSelect": {"type": "boolean"}
                },
                "required": ["question","header","options","multiSelect"]
              }
            }
          },
          "required": ["questions"]
        }
      }
    }],
    "tool_choice": "auto"
  }' | python3 -m json.tool
Inspect choices[0].message.tool_calls[0].function.arguments in the response. The value of questions is a JSON-encoded string:

{
  "questions": "\n[{\"question\": \"What is your favorite color?\", \"header\": \"Color Preference\", \"options\": [...], \"multiSelect\": false}]\n"
}
Contrast: simple array (works correctly)
A tool with a flat array<string> parameter is not affected — ast.literal_eval succeeds on ["a", "b", "c"] because Python string lists are valid Python literals:

curl http://127.0.0.1:8001/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer none" \
  -d '{
    "model": "Qwen3.6-27B",
    "messages": [{"role":"user","content":"Call get_items with items [\"a\",\"b\",\"c\"]"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "get_items",
        "parameters": {
          "type": "object",
          "properties": {
            "items": {"type":"array","items":{"type":"string"}}
          },
          "required": ["items"]
        }
      }
    }],
    "tool_choice": "auto"
  }' | python3 -m json.tool
items arrives as a native array. The bug only manifests when the array contains objects whose properties include JSON-specific literals (true, false, null).

Expected Behaviour
choices[0].message.tool_calls[0].function.arguments should be:

{"questions": [{"question": "...", "header": "...", "options": [...], "multiSelect": false}]}
Actual Behaviour
choices[0].message.tool_calls[0].function.arguments is:

{"questions": "\n[{\"question\": \"...\", \"header\": \"...\", \"options\": [...], \"multiSelect\": false}]\n"}
The questions value is a string, not an array. Any schema-validating client fails with:

SchemaError(Expected array, got "\n[{...}]\n" at ["questions"])
Proposed Fix
In _end_element, inside the if self.defer_current_parameter: block, try json.loads first and fall back to ast.literal_eval only if that fails:

# Before (line ~480 in qwen3xml_tool_parser.py):
parsed_value = ast.literal_eval(raw_for_parse)
output_arguments = json.dumps(parsed_value, ensure_ascii=False)

# After:
try:
    parsed_value = json.loads(raw_for_parse.strip())
except (json.JSONDecodeError, ValueError):
    parsed_value = ast.literal_eval(raw_for_parse)
output_arguments = json.dumps(parsed_value, ensure_ascii=False)
json.loads handles true/false/null correctly. ast.literal_eval is retained as a fallback for any non-standard model output using Python-style single-quoted strings.

Verification after applying the fix
curl http://127.0.0.1:8001/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer none" \
  -d '{
    "model": "Qwen3.6-27B",
    "messages": [{"role":"user","content":"Ask me one question about my color preference"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "AskUserQuestion",
        "parameters": {
          "type": "object",
          "properties": {
            "questions": {
              "type": "array",
              "items": {
                "type": "object",
                "properties": {
                  "question":    {"type": "string"},
                  "header":      {"type": "string"},
                  "options":     {"type": "array", "items": {"type": "object",
                                   "properties": {"label":       {"type": "string"},
                                                  "description": {"type": "string"}}}},
                  "multiSelect": {"type": "boolean"}
                },
                "required": ["question","header","options","multiSelect"]
              }
            }
          },
          "required": ["questions"]
        }
      }
    }],
    "tool_choice": "auto"
  }' | python3 -c "
import sys, json
d = json.load(sys.stdin)
args = json.loads(d['choices'][0]['message']['tool_calls'][0]['function']['arguments'])
q = args['questions']
print('type:', type(q).__name__)
print('PASS' if isinstance(q, list) else 'FAIL — still a string')
"
Expected output with fix applied: type: list / PASS.

Additional Context
The same ast.literal_eval pattern appears in the related qwen3coder_tool_parser.py. That parser also has a separate security advisory ([GHSA-79j6-g2m3-jgfw](https://github.com/vllm-project/vllm/security/advisories/GHSA-79j6-g2m3-jgfw)) for using bare eval() elsewhere — the qwen3xml parser was the recommended safer alternative, but this bug still affects it.
The issue only manifests with array-of-objects parameters. Flat array<string>, array<integer>, and scalar types are unaffected because Python and JSON syntax agree on those forms.
The model's reasoning trace shows it correctly constructs the JSON and self-validates against the schema before generating the tool call — the failure is entirely in the parser's post-processing, not in model output quality.

### Before submitting a new issue...

- [x] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the [documentation page](https://docs.vllm.ai/en/latest/), which can answer lots of frequently asked questions.