When tool calls are skipped in Qwen3.5's thinking block, first forcing the model to explain the purpose of the call may help it execute the tool, but Qwen3.5-Plus still requires separate A/B validation.
Suitable tasks: Tasks in an OpenAI-compatible interface or a self-built Agent where tools are registered but the model skips a call because it seems “obvious.”
Unsuitable tasks: Interfaces that hide reasoning content on the server, use an incompatible tool parser, or require a response to contain strict JSON only with no intermediate reasoning.
Applicable model versions: The original author explicitly mentioned Qwen3.5 35B-A3B and 27B; applying this to Qwen3.5-Plus is only an unverified transfer assumption.
Applicable clients, Agents, or APIs: The author's open code environment; the specific provider, tool parser, and reasoning parameters were not disclosed.
Recommended reasoning level and parameters: The post does not disclose Plus parameters; first keep the provider defaults, pin the model snapshot, and compare only “without the prompt” against “with the pre-tool-call reasoning prompt.”
The original post provides an English system prompt. To comply with the source quotation limit, the following is a complete, ready-to-use rewrite based on its intended meaning and is not claimed to be verbatim:
Before every tool call, briefly reason about the goal, required inputs, and why this tool is the correct next action. Do not skip this check even when the action looks obvious. Then call the tool with only validated arguments. After the result, verify whether it answers the request; if not, explain the missing input before making another call.Choose a task that triggers a function call, and keep the user message, tool schema, model snapshot, temperature, and maximum output identical.
Run a 10-trial no-prompt baseline, recording cases where the model “should have called but answered directly,” parse failures, repeated calls, and the final success rate.
Add only the system prompt above and run 10 more trials; compare tool-call success rate, time to the first tool call, and the number of invalid calls.
Test text and image tasks separately on Qwen3.5-Plus; if the server does not expose the thinking block, record the result as “unobservable” rather than interpreting it as prompt effectiveness.
Keep the original requests, tool-call JSON, tool return values, and final answers to confirm that any improvement comes from the prompt rather than randomness or a parser change.
The author says they reproduced the problem of Qwen3.5 failing to execute tool calls in the thinking block multiple times, and observed that the model may skip reasoning and call the tool immediately when the call is “obvious.”
The author reports that adding a pre-tool-call reasoning requirement in their open code environment eliminated the problem for Qwen3.5 35B-A3B and 27B; they provide no sample size, success rate, random seed, parameters, tool schema, or statistical table.
The full intent of the post is to “think before every tool call,” rather than add a particular tool or change an API parameter; this rewrite preserves that mechanism.
This is personal experience, not a controlled evaluation of Qwen3.5-Plus; it cannot directly establish that the prompt works for Plus.
If the problem comes from a server-side tool parser, message format, or the return of a reasoning field, a system prompt cannot replace a protocol fix.
Forcing reasoning before every call may increase latency and token usage; simple tasks should be measured for cost changes as well.
If the downstream system permits structured JSON only, intermediate reasoning must be hidden on the server or handled through a tool-calling protocol that does not expose reasoning.
The verifiable short quotation from the original post is “YOU MUST THINK EVERYTIME BEFORE YOU CALL THE TOOLS”; the complete prompt wording and its transferability to Qwen3.5-Plus must both be reconfirmed through the experiment above.
Qwen3.5 Plus