feat: restore XML tool protocol option for OpenAI-Compatible provider

[roomote-v0]

This PR attempts to address Issue #10319 by restoring the ability for users of the OpenAI-Compatible provider to explicitly select XML tool protocol.

Problem

In v3.37+, the Tool Call Protocol selector was removed and all new tasks are forced to use native tool calling. This breaks users with OpenAI-Compatible endpoints backed by servers like SGLang or vLLM that do not support native tool calling (e.g., HarmonyParser throws NotImplementedError: structure_info not used with HarmonyParser).

Solution

This PR:

1. Modifies resolveToolProtocol.ts to respect the user's toolProtocol preference when using the OpenAI-Compatible provider (apiProvider === "openai")
2. Adds a Tool Protocol selector to the OpenAI-Compatible provider settings in OpenAICompatible.tsx
3. Adds comprehensive tests for the new behavior

Precedence Logic

The updated resolveToolProtocol() function now follows this precedence:

1. Locked Protocol (task-level lock for resumed tasks - highest priority)
2. User Preference for OpenAI-Compatible (respects toolProtocol setting only for apiProvider: "openai")
3. Native (default for all other new tasks)

This approach:

• Maintains native as the default for all providers
• Only allows explicit XML selection for OpenAI-Compatible provider where backends may not support native tools
• Is minimally invasive (only affects OpenAI-Compatible provider, not other providers)

Feedback and guidance are welcome.

---

Important

Restores XML tool protocol option for OpenAI-Compatible provider, adds UI selector, and updates tests.

• Behavior:
  • Restores XML tool protocol option for OpenAI-Compatible provider in resolveToolProtocol.ts.
  • Adds tool protocol selector to OpenAI-Compatible provider settings in OpenAICompatible.tsx.
  • Comprehensive tests added in resolveToolProtocol.spec.ts and OpenAICompatible.spec.tsx.
• Precedence Logic:
  • resolveToolProtocol() now respects user preference for XML protocol for OpenAI-Compatible provider.
  • Locked protocol takes precedence over user preference.
  • Defaults to native protocol for other providers.
• UI Changes:
  • Adds XML/native protocol selection dropdown in OpenAICompatible.tsx.

^{This description was created by for 89fd5a6. You can customize this summary. It will automatically update as commits are pushed.}

[roomote-v0]

Rooviewer   See task on Roo Cloud

Review complete. No issues found.

This PR correctly restores the XML tool protocol option for the OpenAI-Compatible provider by:

• Modifying resolveToolProtocol.ts to respect user preference for the OpenAI-Compatible provider
• Adding a Tool Protocol selector to the UI
• Including comprehensive test coverage

The implementation is clean and well-tested.

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote-v0]

Fixaroo   See task on Roo Cloud

PR marked as ready for review. All tests pass (40 tests total across backend and UI).

[roomote-v0]

Rooviewer   See task on Roo Cloud

Review complete. No issues found.

This PR correctly restores the XML tool protocol option for the OpenAI-Compatible provider by:

• Modifying resolveToolProtocol.ts to respect user preference for the OpenAI-Compatible provider (apiProvider === "openai")
• Adding a Tool Protocol selector to the UI with proper i18n support
• Including comprehensive test coverage for the new behavior
• Maintaining backward compatibility (defaults to native when no preference is set)

The implementation is clean and well-tested.

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[lgc0313]

Please merge quickly, I need it.

[tsc-awardle]

Also waiting for this to be merge to fix issues with Seed-OSS 36B hosted in VLLM. Relying on an older version for now.

[hannesrudolph]

https://blog.roocode.com/p/sorry-we-didnt-listen-sooner-native
Keeping two tool calling architectures massively increases complexity. Every fix, every feature, every tool-related issue forces Roo to reason about two completely different execution paths. That slows development, increases bugs, and makes it harder to move Roo forward. It also guarantees that XML users would slowly get stuck with an increasingly outdated experience as improvements land only in the native path.

[ApexArray]

https://blog.roocode.com/p/sorry-we-didnt-listen-sooner-native Keeping two tool calling architectures massively increases complexity. Every fix, every feature, every tool-related issue forces Roo to reason about two completely different execution paths. That slows development, increases bugs, and makes it harder to move Roo forward. It also guarantees that XML users would slowly get stuck with an increasingly outdated experience as improvements land only in the native path.

Okay, that's great and all. I agree it should be the responsibility of the inference server to ensure the model's esoteric tool calling is properly parsed into OpenAI-compatible format.

However, removing a default setting in a minor release without any sort of deprecation notice leading up to the change is not a good look.

For anyone stuck in the same boat, I think this comes down to ensuring the OpenAI-compatible server is using a proper tool calling parser. In my case, I'm using --tool-call-parser seed_oss in VLLM, but the model's tool call is still being output into the chat, so I'll try taking a look at seed_oss_tool_parser.py in VLLM and try to find out why it's not working.

In the future, can we expect any sort of deprecation notices for significant changes like this in the future?