chore: remove XML tool calling support #10841

hannesrudolph · 2026-01-20T01:12:07Z

Removes all legacy XML-based tool calling support with zero fallback.

Deletes XML protocol/types/parsers/formatters and XML-only tests/fixtures
Removes toolProtocol config plumbing and UI settings
Makes tool invocation native-only; fails fast if XML tool markup is encountered
Updates assistant message rendering to reject XML tool tags and invalid legacy tool blocks

Validation:

turbo lint
turbo check-types
turbo test

roomote · 2026-01-20T01:12:36Z

Oroocle See task on Roo Cloud

1 follow-up remaining.

Bedrock: native-only message conversion can emit toolUse/toolResult blocks even when no toolConfig is being sent (may error)

Previous reviews

8fba7fc: Review #1

725bd33: Review #2

7f4955e: Review #3

be5bcbc: Review #4

ca8a818: Review #5

2558400: Review #6

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

ellipsis-dev · 2026-01-20T01:16:55Z

⚠️ This PR is too big for Ellipsis, but support for larger PRs is coming soon. If you want us to prioritize this feature, let us know at help@ellipsis.dev

Generated with ❤️ by ellipsis.dev

src/core/tools/BaseTool.ts

roomote · 2026-01-20T01:27:31Z

src/core/assistant-message/presentAssistantMessage.ts

-					}
+				// Tool calling is native-only. If the model emits XML-style tool tags in a text block,
+				// fail fast with a clear error.
+				if (containsXmlToolMarkup(content)) {


containsXmlToolMarkup() lowercases the full text and then checks for <${toolName} / </${toolName} substrings. That will also match normal examples like \<read_file>`` inside code fences or documentation snippets, so a user pasting docs can hard-fail the turn even though it is not attempting tool execution. Consider scoping the check (e.g., ignore content inside markdown code fences, or only fail when the tag appears outside backticks) so ordinary docs/examples do not immediately break the conversation.

_{Fix it with Roo Code or mention @roomote and request a fix.}

Agreed — fixed by scoping XML-tag detection to ignore markdown code fences / inline code so docs/examples like <read_file> don't hard-fail the turn.

roomote · 2026-01-20T01:31:27Z

src/core/assistant-message/NativeToolCallParser.ts

+			// If we couldn't construct it, the model produced an invalid tool call payload.
+			if (!nativeArgs && !customToolRegistry.has(resolvedName)) {
+				throw new Error(
+					`[NativeToolCallParser] Invalid arguments for tool '${resolvedName}'. ` +


This new fail-fast is a good tightening for native-only tool execution, but there is still a fallback path in that can surface a without when returns null. In that case we end up reaching the tool layer with missing and producing tool_result payloads via error paths rather than a single consistent structured tool_result. Consider aligning the streaming fallback to emit a single for malformed args instead of attempting to execute.

_{Fix it with Roo Code or mention @roomote and request a fix.}

Aligned now: malformed/incomplete tool args no longer reach the tool layer. If a non-partial tool_use is missing nativeArgs, we emit exactly one structured tool_result error instead of attempting execution.

…allParser - Add list_files case to parseToolCall() switch with path/recursive args - Add new_task case to parseToolCall() switch with mode/message/todos args - Add list_files to NativeToolArgs type in tools.ts - Both tools were in toolNames but lacked case handlers, causing the fail-fast check on line 852 to throw 'Invalid arguments for tool'

roomote · 2026-01-20T03:13:16Z

src/core/assistant-message/NativeToolCallParser.ts

+					nativeArgs = {
+						path: partialArgs.path,
+						recursive: partialArgs.recursive,
+					}


In NativeToolCallParser.createPartialToolUse(), list_files treats recursive as-is. Since the schema is boolean, partial-json may yield a string (e.g. "true") during streaming, which can later trip the nativeArgs validation in parseToolCall() and surface as an invalid-args error for an otherwise valid call. Coercing recursive to boolean in nativeArgs (similar to ListFilesTool.handlePartial()) would make streaming progress and finalization consistent.

_{Fix it with Roo Code or mention @roomote and request a fix.}

Fixed: list_files.recursive is now coerced to boolean during streaming (partial nativeArgs) and on final parse, so validation won't reject otherwise-valid calls.

- Remove redundant pushToolResult after handleError in BaseTool.ts (handleError already emits tool_result via formatResponse.toolError) - Fix containsXmlToolMarkup to exclude content inside markdown code fences, preventing false positives when users paste docs/examples - Make 'wait for confirmation' guideline conditional on !isMultipleNativeToolCallsEnabled to avoid contradicting multiple-tools-per-message guidance - Update tests to reflect intentional behavior changes

roomote · 2026-01-20T03:25:43Z

src/core/prompts/sections/tool-use-guidelines.ts

-	// For native protocol, the footer is less relevant since multiple tools can execute in one message
-	const footer = isNativeProtocol(protocol)
+	const footer = isMultipleNativeToolCallsEnabled
 		? `\n\nBy carefully considering the user's response after tool executions, you can react accordingly and make informed decisions about how to proceed with the task. This iterative process helps ensure the overall success and accuracy of your work.`


When MULTIPLE_NATIVE_TOOL_CALLS is enabled, the footer is updated but the numbered guideline still says "After each tool use, the user will respond...", which reads inconsistent with batching multiple tool calls per message. Consider making that guideline conditional too (e.g. "After tool executions..." in the multi-call branch) so the section doesn't contradict itself.

_{Fix it with Roo Code or mention @roomote and request a fix.}

Updated: when MULTIPLE_NATIVE_TOOL_CALLS is enabled, the guidelines no longer say “After each tool use…” — that wording is now conditional to avoid contradicting batching.

mrubens · 2026-01-20T05:05:49Z

packages/types/src/tool.ts

 * Router providers (Requesty, Unbound, LiteLLM) assume all models support native tools.
 */
 export const NATIVE_TOOL_DEFAULTS = {
 	supportsNativeTools: true,


Seems like we can get rid of this too?

Removed in this PR — TOOL_PROTOCOL/ToolProtocol are now gone from packages/types/src/tool.ts.

Clarifying this thread: this inline comment was attached to the removed TOOL_PROTOCOL / ToolProtocol block above (GitHub is now showing the nearby NATIVE_TOOL_DEFAULTS lines as context).

✅ TOOL_PROTOCOL / ToolProtocol are removed.

🟦 NATIVE_TOOL_DEFAULTS is still intentionally kept because it’s referenced in multiple places to merge defaults into cached/custom model info (e.g. router providers) so supportsNativeTools doesn’t become accidentally undefined.

mrubens · 2026-01-20T05:07:29Z

src/api/providers/deepseek.ts

 			...(metadata?.tool_choice && { tool_choice: metadata.tool_choice }),
-			...(metadata?.toolProtocol === "native" && {
-				parallel_tool_calls: metadata.parallelToolCalls ?? false,
+			...(metadata?.parallelToolCalls !== undefined && {


Are we explicitly setting parallelToolCalls to false everywhere? I'm a little nervous about changing this unintentionally.

Agreed. Updated so we only send parallel_tool_calls when metadata.parallelToolCalls is explicitly provided (no implicit false). See src/api/providers/deepseek.ts.

mrubens · 2026-01-20T05:08:24Z

src/api/providers/lite-llm.ts

 		// Check if model supports native tools and tools are provided with native protocol
 		const supportsNativeTools = info.supportsNativeTools ?? false
-		const useNativeTools = supportsNativeTools && metadata?.tools && metadata.tools.length > 0 && isNativeProtocol
+		const useNativeTools = supportsNativeTools && metadata?.tools && metadata.tools.length > 0


Is this still a case we need to support?

No — with XML tool calling removed, we don't need to gate native tools on toolProtocol here anymore. useNativeTools is now purely capability + tools-present in src/api/providers/lite-llm.ts.

mrubens · 2026-01-20T05:08:48Z

src/api/providers/lm-studio.ts

 		// LM Studio always supports native tools (https://lmstudio.ai/docs/developer/core/tools)
-		const useNativeTools = metadata?.tools && metadata.tools.length > 0 && metadata?.toolProtocol !== "xml"
+		const useNativeTools = !!(metadata?.tools && metadata.tools.length > 0)


Probably remove?

Yep — removed. LM Studio now enables native tools whenever tools are present (no toolProtocol check) in src/api/providers/lm-studio.ts.

src/api/transform/bedrock-converse-format.ts

roomote · 2026-01-20T05:42:39Z

src/api/providers/bedrock.ts

-		const convertedMessages = sharedConverter(anthropicMessages as Anthropic.Messages.MessageParam[], {
-			useNativeTools,
-		})
+		const convertedMessages = sharedConverter(anthropicMessages as Anthropic.Messages.MessageParam[])


Now that Bedrock message conversion is native-only, it will emit toolUse/toolResult blocks for any historical tool_use/tool_result content, even when this request is not sending toolConfig (because useNativeTools is false when tools are omitted or tool_choice is none). Bedrock errors if toolUse/toolResult appear without toolConfig, so it may be worth either (a) failing fast here when convertedMessages contain tool blocks but toolConfig is missing, or (b) deriving the useNativeTools decision from the presence of tool blocks in the messages, not just metadata.tools.

_{Fix it with Roo Code or mention @roomote and request a fix.}

roomote · 2026-01-20T06:39:13Z

src/api/providers/bedrock.ts

-			metadata?.toolProtocol !== "xml" &&
-			metadata?.tool_choice !== "none"
+		// NOTE: tool inclusion is controlled by caller metadata, not per-model flags.
+		const useNativeTools = Boolean(metadata?.tools?.length) && metadata?.tool_choice !== "none"


In AwsBedrockHandler.createMessage(), useNativeTools is derived only from metadata.tools/tool_choice, but convertToBedrockConverseMessages() is now native-only and can still produce toolUse/toolResult blocks from historical tool_use/tool_result message content. Bedrock will reject requests that contain tool blocks when toolConfig is omitted, so this can 400 on resumed conversations that have old tool history but no tools are being sent in the current request.

_{Fix it with Roo Code or mention @roomote and request a fix.}

chore: remove XML tool calling support

2558400

hannesrudolph requested review from cte, jr and mrubens as code owners January 20, 2026 01:12

dosubot bot added the size:XL This PR changes 500-999 lines, ignoring generated files. label Jan 20, 2026

github-project-automation bot added this to Roo Code Roadmap and Roo Code Roadmap Jan 20, 2026

github-project-automation bot moved this to Triage in Roo Code Roadmap Jan 20, 2026

github-project-automation bot moved this to New in Roo Code Roadmap Jan 20, 2026

chore: remove unused prompt tool description files

ca8a818

roomote bot reviewed Jan 20, 2026

View reviewed changes

src/core/tools/BaseTool.ts Outdated Show resolved Hide resolved

roomote bot reviewed Jan 20, 2026

View reviewed changes

roomote bot approved these changes Jan 20, 2026

View reviewed changes

roomote bot reviewed Jan 20, 2026

View reviewed changes

mrubens reviewed Jan 20, 2026

View reviewed changes

fix: harden streaming tool-call finalization and list_files args

c577eca

mrubens reviewed Jan 20, 2026

View reviewed changes

src/api/transform/bedrock-converse-format.ts Outdated Show resolved Hide resolved

test: fix validateToolUse mocks for isValidToolName

725bd33

roomote bot approved these changes Jan 20, 2026

View reviewed changes

chore: remove remaining Bedrock non-native tool conversion

8fba7fc

roomote bot reviewed Jan 20, 2026

View reviewed changes

roomote bot approved these changes Jan 20, 2026

View reviewed changes

hannesrudolph added 2 commits January 19, 2026 23:28

fix: always include tools from metadata; remove supportsNativeTools

8d4472a

test: stabilize vscode-lm getModel expectations

76eff25

roomote bot reviewed Jan 20, 2026

View reviewed changes

chore: remove XML tool calling support #10841

Are you sure you want to change the base?

chore: remove XML tool calling support #10841

Conversation

hannesrudolph commented Jan 20, 2026

Uh oh!

roomote bot commented Jan 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ellipsis-dev bot commented Jan 20, 2026

Uh oh!

Uh oh!

roomote bot Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roomote bot Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roomote bot Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roomote bot Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

roomote bot Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

roomote bot Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

roomote bot commented Jan 20, 2026 •

edited

Loading