Description
FastFlowLM v1.0.6 serializes a tool argument defined as JSON Schema
boolean as a JSON string when using qwen3.5:9b.
The tool schema explicitly defines:
"accepted": {
"type": "boolean"
}
However, FastFlowLM returns:
{"accepted":"True"}
instead of:
{"accepted":true}
This causes OpenAI-compatible clients that validate tool arguments
against the supplied JSON Schema to reject the tool call.
Environment
FastFlowLM: v1.0.6
Model: qwen3.5:9b
Linux portable build: fastflowlm_1.0.6_linux.tar.gz
API: /v1/chat/completions
Minimal reproducer
curl -s http://127.0.0.1:8000/v1/chat/completions
-H 'Content-Type: application/json'
-d '{"model":"qwen3.5:9b","stream":false,"messages":[{"role":"user","content":"Call confirm_result with accepted set to true."}],"tools":[{"type":"function","function":{"name":"confirm_result","description":"Confirm the result","parameters":{"type":"object","properties":{"accepted":{"type":"boolean"}},"required":["accepted"]}}}],"tool_choice":{"type":"function","function":{"name":"confirm_result"}}}'
Actual result
FastFlowLM returns the tool arguments as:
"arguments":"{"accepted":"True"}"
Decoded:
{
"accepted": "True"
}
The value is a JSON string.
Expected result
The tool arguments should preserve the type specified by the JSON
Schema:
"arguments":"{"accepted":true}"
Decoded:
{
"accepted": true
}
The value should be a JSON boolean.
Additional information
The model's raw tool output contains:
<parameter=accepted>
True
FastFlowLM then converts this to:
{"accepted":"True"}
So it appears that the tool-call argument conversion/serialization step
does not coerce the generated value according to the parameter type
declared in the supplied tool JSON Schema.
This is reproducible with a minimal request and does not require a large
context or a multi-turn conversation.
Description
FastFlowLM v1.0.6 serializes a tool argument defined as JSON Schema
boolean as a JSON string when using qwen3.5:9b.
The tool schema explicitly defines:
"accepted": {
"type": "boolean"
}
However, FastFlowLM returns:
{"accepted":"True"}
instead of:
{"accepted":true}
This causes OpenAI-compatible clients that validate tool arguments
against the supplied JSON Schema to reject the tool call.
Environment
FastFlowLM: v1.0.6
Model: qwen3.5:9b
Linux portable build: fastflowlm_1.0.6_linux.tar.gz
API: /v1/chat/completions
Minimal reproducer
curl -s http://127.0.0.1:8000/v1/chat/completions
-H 'Content-Type: application/json'
-d '{"model":"qwen3.5:9b","stream":false,"messages":[{"role":"user","content":"Call confirm_result with accepted set to true."}],"tools":[{"type":"function","function":{"name":"confirm_result","description":"Confirm the result","parameters":{"type":"object","properties":{"accepted":{"type":"boolean"}},"required":["accepted"]}}}],"tool_choice":{"type":"function","function":{"name":"confirm_result"}}}'
Actual result
FastFlowLM returns the tool arguments as:
"arguments":"{"accepted":"True"}"
Decoded:
{
"accepted": "True"
}
The value is a JSON string.
Expected result
The tool arguments should preserve the type specified by the JSON
Schema:
"arguments":"{"accepted":true}"
Decoded:
{
"accepted": true
}
The value should be a JSON boolean.
Additional information
The model's raw tool output contains:
<parameter=accepted>
True
FastFlowLM then converts this to:
{"accepted":"True"}
So it appears that the tool-call argument conversion/serialization step
does not coerce the generated value according to the parameter type
declared in the supplied tool JSON Schema.
This is reproducible with a minimal request and does not require a large
context or a multi-turn conversation.