Native Tool Call

[NaccOll]

Issue

#4047 (comment)

What I Do

Without major refactoring of the existing workflow, the tool call based on XML-formatted text prompts was converted to tool call based on json.

Implementation Approach

• Added a toggle in the Provider settings page, allowing users to enable/disable tool call
• Designed a compatible tool call interface and migrated tools from text+XML prompts to tool call format objects
• When tool call is enabled, converted tools will remove their original descriptions and examples during prompt generation
• Designed unified post-call processing to transform the returned standard JSON into XML, seamlessly integrating with the existing function

Tools

• apply_diff (only support multiple file edit)
• insert_contnet
• list_code_definition_names
• list_files
• read_file( The file read limit may fail. )
• search_and_replace
• search_files
• write_to_file
• access_mcp_resource
• ask_followup_question
• attempt_completion
• browser_action
• codebase_search
• execute_command
• fetch_instructions
• new_task
• switch_mode
• update_todo_list
• use_mcp_tool

Provider

• OpenRouter
• OpenAI Compatible
• DeepSeek
• LmStudio
• VSCode-LM API(Flow Break)
• Copilot(feat: add GitHub Copilot Provider that support agent mode #7010 #7072)

Benefits

1. When tool information is returned via tool_call, format accuracy improves significantly—even 4B models can generate precisely formatted apply_diff outputs.
2. Prompt length is reduced.

Problem

Legacy Issues

1. Accuracy depends on tool call, but models may fail to grasp the intent and still return text instead of tool calls.
2. Not all tools have been migrated yet, which may lead the model to mimic behavior. As XML content accumulates in the chat, incorrect XML outputs may occur. ( Abandoned the need to refine parameters and strengthen control (for example, splitting the content of apply_diff into search_str and replace_str), and completely aligned the tool call parameters with the original XML description to avoid parameter errors when LLM refers to tool parameters and large amounts of user XML input for XML output. )(This has been resolved through standard tool calls)
3. Format accuracy does not guarantee content accuracy. While the model can invoke tools correctly. e.g., apply_diff requires content-matching replacements, the generated original content may still be inaccurate.

New Problem

1. Streaming processing is disrupted. Although results are still returned via streaming, the actual tool invocation requires converting JSON to XML first. For large file modifications, this causes delays where users see no feedback during processing.(Support streaming conversion of json to xml)
2. Streaming state changes after JSON completion. Due to the current duplicate call detection, the model's retry limit must be adjusted to two or more attempts; otherwise, errors will occur.(See Errors and Repeated Use Limitations #6834)
3. For a tool, you need to maintain both the XML prompt word and the tool call description object. I originally wanted to map the tool call object to an XML description, but apply_diff and read_file are more complicated. I still need to think about how to complete it.
4. When you pass the tools parameter, OpenRouter promises to route your request to providers that support tool calls. However, some providers' tool call implementations aren't flawless. For instance, DeepSeek-V3-0324 on Chunts handles tool calls normally, but Qwen3-Coder's tool functionality may fail. That said, if you select Alibaba as Qwen3-Coder's provider, the tool calls will work fine—though at a cost several times higher. This inevitably complicates tool call support for models on OpenRouter, leaving users to figure out the quirks themselves.
5. I lack the test conditions for browser_action. In addition, ask_followup_question uses xml attribute to set mode, and cannot map json stream to xml. (feat: simplify attempt_completion tool description #6888)

---

Important

This PR transitions tool calls from XML to JSON format, enhancing accuracy and efficiency, with updates to backend logic, UI, and tests.

• Behavior:
  • Converts tool calls from XML to JSON format, improving format accuracy and reducing prompt length.
  • Adds a toggle in ProviderSettingsManager to enable/disable JSON tool calls.
  • Updates Task class to handle JSON tool calls and convert them back to XML if needed.
• Tools:
  • Implements ToolRegistry to manage tool schemas and support JSON tool calls.
  • Adds schemas for tools like apply_diff, read_file, write_to_file, etc.
  • Provides conversion functions in function-call-converter.ts to handle JSON to XML transformations.
• UI:
  • Adds ToolCallSettingsControl component to manage tool call settings in the UI.
  • Updates ApiOptions.tsx to include tool call settings.
  • Localizes tool call settings in settings.json.
• Testing:
  • Adds tests for tool schema generation and conversion in base-tool-schema.test.ts and function-call-converter.test.ts.
  • Tests ToolRegistry functionality in tool-registry.test.ts.

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

[roomote]

Thank you for your contribution! I've reviewed the changes and found some issues that need attention. This PR implements a valuable feature for native tool calling, but there are some critical issues that should be addressed before merging.

[NaccOll]

@roomote-agent
Review this PR again

[roomote]

I'm starting my review of this PR now. I'll examine the Native Tool Call implementation and provide feedback shortly.

[roomote]

Review Complete ✅

I've completed my review of the Native Tool Call implementation. Here's my assessment:

✅ Strengths

1. Well-structured implementation: The conversion from XML to JSON tool calls is cleanly implemented with a proper streaming processor
2. Good test coverage: The StreamingToolCallProcessor has comprehensive tests covering various scenarios including edge cases
3. Backward compatibility: The toggle feature allows users to enable/disable tool calls, maintaining compatibility with existing workflows
4. Provider support: Successfully integrated with OpenRouter, OpenAI Compatible, and DeepSeek providers

📋 Key Components Reviewed

• ✅ StreamingToolCallProcessor - Handles JSON to XML conversion with proper state management
• ✅ ToolRegistry - Manages tool schemas and provides conversion functions
• ✅ Tool schemas for supported tools (apply_diff, read_file, write_to_file, etc.)
• ✅ UI integration with ToolCallSettingsControl component
• ✅ Localization support across all languages

🔍 Observations

1. Incomplete tool support: ask_followup_question and browser_action are not yet registered in the ToolRegistry (lines 35, 37 commented out)
2. Special handling for apply_diff: The processor has custom logic for handling apply_diff content transformation (lines 409-430 in tool-call-helper.ts)
3. Migration strategy: Proper migration added to ensure existing installations get the new setting defaulted to false

✅ Testing Results

• All tool-call-helper tests pass successfully (13/13)
• The streaming processor correctly handles:
  • Simple function calls
  • Incremental streaming
  • Nested objects and arrays
  • Multiple tool calls
  • Edge cases and error scenarios

💡 Recommendations

1. Consider completing support for ask_followup_question and browser_action tools
2. Document the provider-specific quirks mentioned in the PR description for users
3. Consider adding integration tests for the full tool call flow with actual API responses

✅ Verdict

The implementation is solid and ready for use. The streaming JSON to XML converter is well-designed, and the feature toggle provides a safe rollout path. The code quality is good with proper error handling and test coverage.

Great work on this feature! 🎉

[NaccOll]

Native tool call support is complete. I've found a way to use standard tool results to interact with LLM without major changes.

Overall, it's less common to encounter multiple rounds of conversations where subsequent responses mimic XML and abandon the return of tool_calls. I've tested the tools I frequently use in my daily work. There are still a few tools I use less frequently.

1. browser_action: I haven't used or tested them at all.
2. fetch_instructions: I've completed the tool call, but I haven't completed the entire process.
3. access_mcp_resource and use_mcp_tool: I use sequentialthinking regularly, but not as frequently as other tools.

For the other tools, I use them frequently in my daily work. Most of the problem have been resolved.