[BUG] Deepseek v3.2 function/tool call support is broken after upgrading to v3.37.0

[itechbear]

Problem (one or two sentences)

After I update the plugin to v3.37.0, deepseek v3.2 function/tool call is completely broken. Instead, it prints the function/tool name and arguments in XML format to me directly as replies. After I downgraded it to v3.36.16, it works again.

The reply from it looks like

I'll start by examining the open file src/app/chat.ts to understand the bug. Let's read its content.

<read_file>
<path>src/app/chat.ts</path>
</read_file>

Context (who is affected and when)

Deepseek v3.2 users

Reproduction steps

I belive it's OS-independent. I observed the same problem across my macbook and linux box.

Expected result

Deepseek v3.2 function/tool call should work without any problem.

Actual result

Deepseek v3.2 function/tool call doesn't work.

Variations tried (optional)

v3.36.16 works without any problem.

App Version

v3.37.0

API Provider (optional)

OpenAI Compatible

Model Used (optional)

Deepseek v3.2

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause Analysis

The issue is caused by PR #10281 (merged in v3.37.0) which deprecated XML tool protocol selection and forced native tool calling for all new tasks. Specifically:

1. resolveToolProtocol() in src/utils/resolveToolProtocol.ts now ignores the model's supportsNativeTools property and always returns TOOL_PROTOCOL.NATIVE for new tasks
2. For the OpenAI Compatible provider, openAiModelInfoSaneDefaults has supportsNativeTools: true, but the default value doesn't accurately represent all OpenAI-compatible models
3. Deepseek v3.2 (when accessed via the generic OpenAI Compatible provider) doesn't properly implement native function calling through the OpenAI-compatible API endpoint, so it outputs XML-formatted tool calls as plain text instead

The key problematic code in resolveToolProtocol.ts:

export function resolveToolProtocol(
  _providerSettings: ProviderSettings,
  _modelInfo?: unknown,  // <-- This is now ignored!
  lockedProtocol?: ToolProtocol,
): ToolProtocol {
  if (lockedProtocol) {
    return lockedProtocol
  }
  return TOOL_PROTOCOL.NATIVE  // Always returns native, regardless of model capability
}

Proposed Fix

Modify resolveToolProtocol() to respect the model's supportsNativeTools property:

1. Update resolveToolProtocol() to check if the model declares supportsNativeTools: true. If not, fall back to XML protocol
2. Change openAiModelInfoSaneDefaults.supportsNativeTools from true to false since the OpenAI Compatible provider is used for diverse third-party models where native tool support cannot be assumed
3. Add a checkbox in the OpenAI Compatible provider settings to allow users to explicitly enable supportsNativeTools for models that do support it

This approach:

• Fixes the issue for Deepseek v3.2 and other models that don't support native tools via OpenAI-compatible API
• Preserves native tool calling for models that properly support it
• Gives users control over the setting for their specific use case

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[semidark]

I can confirm this Problem: It happends to me using OpenAI Compatible API and a broad range of models:

• Claude Sonnet 4.5
• GPT 5
• Qwen3 235b
• Qwen3 Coder 480b

After downgrading to Roo Code Version 3.36.16 everything is back to normal.

[slamj1]

I confirm the issue: downgrading to 3.36.16 restores XML tool selection.

[rossdonald]

Same as #10304

[funnycups]

seems to be fixed in 3.37.1

[itechbear]

@hannesrudolph while I don't have permission to re-open the issue, the problem still exists in v3.37.1

I'll use the xxx MCP tool to get information about yyy. Let's start by checking what tools are available and then call the appropriate one.

First, I'll create a todo list to track the steps.

<function_calls>
<invoke name="zzz">{
"todos": "[-] Use xxx MCP to get yyy information\n[ ] Analyze and present results"
invoke>
</function_calls>