allow use five tools in one call #3840

qdaxb · 2025-05-22T16:38:39Z

Related GitHub Issue

Closes: #3839

Description

Changed didAlreadyUseTool to an integer type, and updated the corresponding logic for setting and checking it.
Modified the prompts for the system and some tools.
Made targeted changes to new_task and attempt_completion_task.

Based on my testing, the LLM generally does not overuse tool calls, and it performs well in scenarios where multiple tool calls are genuinely needed.

Test Procedure

Type of Change

🐛 Bug Fix: Non-breaking change that fixes an issue.
[x ] ✨ New Feature: Non-breaking change that adds functionality.
💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
📚 Documentation: Updates to documentation files.
⚙️ Build/CI: Changes to the build process or CI configuration.
🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

Important

Allows up to five tool uses per message, updates tool usage logic, and modifies related prompts and functions.

Behavior:
- didAlreadyUseTool changed to integer in Task class to track tool usage count.
- Allows up to five tool uses per message in presentAssistantMessage().
- Restricts attempt_completion tool from being used with others in presentAssistantMessage().
Prompts:
- Updated getSharedToolUseSection() to reflect new tool usage limit.
- Added note in getNewTaskDescription() that new_task can only be called once per message.
Tools:
- In newTaskTool(), increments didAlreadyUseTool by 5 to prevent further tool use after creating a new task.

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

ellipsis-dev · 2025-05-22T16:40:52Z

src/core/assistant-message/presentAssistantMessage.ts

 				// Ignore any content after a tool has already been used.
 				cline.userMessageContent.push({
 					type: "text",
-					text: `Tool [${block.name}] was not executed because a tool has already been used in this message. Only one tool may be used per message. You must assess the first tool's result before proceeding to use the next tool.`,
+					text: `Tool [${block.name}] was not executed because too many tools has already been used in this message. Only five tool may be used per message. You must assess the first tool's result before proceeding to use the next tool.`,


Typographical error: The phrase too many tools has already been used should be too many tools have already been used, and Only five tool may be used should be Only five tools may be used.

ellipsis-dev · 2025-05-22T16:40:53Z

src/core/prompts/tools/new-task.ts

@@ -3,6 +3,7 @@ import { ToolArgs } from "./types"
 export function getNewTaskDescription(_args: ToolArgs): string {
 	return `## new_task
 Description: This will let you create a new task instance in the chosen mode using your provided message.
+IMPORTANT: This tool could only called once per message.


Typo: In the sentence IMPORTANT: This tool could only called once per message., please change it to IMPORTANT: This tool can only be called once per message.

Suggested change

IMPORTANT: This tool could only called once per message.

IMPORTANT: This tool can only be called once per message.

ellipsis-dev · 2025-05-22T16:40:53Z

src/core/task/Task.ts

 						assistantMessage +=
-							"\n\n[Response interrupted by a tool use result. Only one tool may be used at a time and should be placed at the end of the message.]"
+							"\n\n[Response interrupted by a tool use result. Only five tool may be used at a time and should be placed at the end of the message.]"


Typo: In the message string, consider changing "Only five tool may be used" to "Only five tools may be used" for grammatical correctness.

Suggested change

"\n\n[Response interrupted by a tool use result. Only five tool may be used at a time and should be placed at the end of the message.]"

"\n\n[Response interrupted by a tool use result. Only five tools may be used at a time and should be placed at the end of the message.]"

Ruakij · 2025-05-22T23:09:45Z

Hey, i also have a version for multi-tool-calling, though yours is much cleaner.
Limiting the amount of tools used is pretty good, mine is unlimited so far :)

I also see you limited attempt_completion to be called alone, very nice.

Some things to consider maybe:

Models probably perform better when allowing their chain of through process, so explaining what they are about to do, then calling the tool, and then explaining about the next action they are about to take. So instructing it to move the tools to the bottom might hurt quality.
- The new Sonnet 4 does this alot, even on the same file
A slider in settings, how many tools to allow, instead of hard-coded could be good and easy
some models like to ignore specifics once context grows, sometimes trying attempt-completion while using other tools many times
- In some cases sonnet 3.5 tried attempt_completion and then another command to run tests, not sure if that bugs out with you too, but probably needs to be filtered if not already handled
Its probably a good idea to block writing files that were just read, specially with sonnet models i found them getting confused from previous read_files and immediately start making diffs. Blocking helped avoiding many clashes.
- This also applies to duplicated or overlapping tool-calls (though i have never observed this)
The UI code needs some update, because while waiting for user-input the response is still streaming, we should reflect that and display next know output and tools. Am unsure about the design.

You can check out my glued-together PoC version here: https://github.com/Ruakij/Roo-Code/tree/feat/multiple-tool-calls

wwicak · 2025-05-23T02:37:32Z

why limit to 5? why not make it adjustable?

samhvw8 · 2025-05-24T19:43:36Z

The current implementation has the potential to introduce bugs when tools are executed in complex sequences (e.g., read → write → read → write → search → write) or when specialized tools like attempt_completion are used. This essentially creates race conditions where the timing and order of tool execution can lead to unpredictable behavior. To mitigate these issues, tools should be categorized into functional groups that support parallel execution, enabling multiple tools to operate simultaneously without conflicts.

qdaxb · 2025-05-26T15:16:02Z

The current implementation has the potential to introduce bugs when tools are executed in complex sequences (e.g., read → write → read → write → search → write) or when specialized tools like attempt_completion are used. This essentially creates race conditions where the timing and order of tool execution can lead to unpredictable behavior. To mitigate these issues, tools should be categorized into functional groups that support parallel execution, enabling multiple tools to operate simultaneously without conflicts.

I have had similar ideas, but from the actual test results, large models will not generate read-write operations. Multiple tools will only be called when there is a real need (for example, when multiple files must be read). Therefore, I only made special treatments for new_task and attempt_completion

qdaxb · 2025-05-26T15:18:52Z

why limit to 5? why not make it adjustable?

This is just a number that I found to be effective. I don't think it's necessary to make this value adjustable, as it's a bit too detailed.

qdaxb · 2025-05-26T15:32:18Z

Models probably perform better when allowing their chain of through process, so explaining what they are about to do, then calling the tool, and then explaining about the next action they are about to take. So instructing it to move the tools to the bottom might hurt quality.

I don't quite understand "move the tools to the bottom", there doesn't seem to be such a restriction in the prompt?

The new Sonnet 4 does this alot, even on the same file

A slider in settings, how many tools to allow, instead of hard-coded could be good and easy

some models like to ignore specifics once context grows, sometimes trying attempt-completion while using other tools many times

I didn't add it because I don't think anyone will change this setting (or I haven't encountered a situation where I feel the need to change the number of tools so far in the version with 5 tools)

In some cases sonnet 3.5 tried attempt_completion and then another command to run tests, not sure if that bugs out with you too, but probably needs to be filtered if not already handled

https://github.com/RooCodeInc/Roo-Code/pull/3840/files#diff-d70cf61ca4995225bfa29e16f01ed7f7cdb85ba5c3f7e0d547151ae9433d5546R223
The condition here is used to ignore the tool after attempt_completion

Its probably a good idea to block writing files that were just read, specially with sonnet models i found them getting confused from previous read_files and immediately start making diffs. Blocking helped avoiding many clashes.

So far, I have not encountered this situation. If there is a case that can be reproduced, please share it.

This also applies to duplicated or overlapping tool-calls (though i have never observed this)

me too

The UI code needs some update, because while waiting for user-input the response is still streaming, we should reflect that and display next know output and tools. Am unsure about the design.

I agree that it would be best if all commands to be executed in the current dialogue and the steps being executed can be displayed. However, this change may be larger, and I think it is worth looking at the feedback of the current version first.

Ruakij · 2025-05-27T06:39:48Z

I don't quite understand "move the tools to the bottom", there doesn't seem to be such a restriction in the prompt?

https://github.com/RooCodeInc/Roo-Code/pull/3840/files#diff-ec3b024cdaad55c3e92c0d0d4293bbc785e69f76bf646132cb0923f44fb3df22R1265
Seems to be a leftover from the previous one-tool-use error. For Multi-Tool-Use i'd remove the mention to move it to the end.

I didn't add it because I don't think anyone will change this setting (or I haven't encountered a situation where I feel the need to change the number of tools so far in the version with 5 tools)

Had some cases where i gave the model a list of Sonar-issues of like 15 files and he would read all of them in one response, then fix all issues in the next, was pretty nice.
But i'd def. make this a slider, because not all models might work well with multi-tool-calling.

So far, I have not encountered this situation. If there is a case that can be reproduced, please share it.

Unfortunately nothing to really reproduce it reliably.
Previously i had encouraged him to work with many tools per message and that seems to have pushed him to write while reading, complete while using other tools etc. And these things consistently once he starts doing so.
This also consistently pushes the Models to hallucinate either based on previous read_file requests or from other files and who-knows-what.

See this:

Image

(This is my version of multi-tool-calling, so it blocked the write-request, otherwise he would have started editing the file without having ever seen it)

However, this change may be larger, and I think it is worth looking at the feedback of the current version first.

Agreed, we can make a nicer UI later

mrubens · 2025-05-27T15:24:54Z

Interesting exploration! Any thoughts on how auto-approval / manual approval should work with multiple tool calls?

qdaxb requested review from mrubens and cte as code owners May 22, 2025 16:38

github-project-automation bot added this to Roo Code Roadmap and Roo Code Roadmap May 22, 2025

github-project-automation bot moved this to New in Roo Code Roadmap May 22, 2025

ellipsis-dev bot reviewed May 22, 2025

View reviewed changes

hannesrudolph moved this from New to PR [Pre Approval Review] in Roo Code Roadmap May 23, 2025

wwicak mentioned this pull request May 26, 2025

Frequent tool use issues with Gemini flash 2.5 preview - 5.20 #3980

Closed

allow use five tools in one call

26aa469

qdaxb force-pushed the support_multi_tool branch from 55e6c13 to 26aa469 Compare May 26, 2025 16:23

hannesrudolph moved this from PR [Needs Review] to TEMP in Roo Code Roadmap May 26, 2025

daniel-lxs moved this from TEMP to PR [Needs Review] in Roo Code Roadmap May 27, 2025

daniel-lxs added the PR - Needs Preliminary Review label May 27, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

allow use five tools in one call #3840

allow use five tools in one call #3840

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

	IMPORTANT: This tool could only called once per message.
	IMPORTANT: This tool can only be called once per message.

	"\n\n[Response interrupted by a tool use result. Only five tool may be used at a time and should be placed at the end of the message.]"
	"\n\n[Response interrupted by a tool use result. Only five tools may be used at a time and should be placed at the end of the message.]"

allow use five tools in one call #3840

Are you sure you want to change the base?

allow use five tools in one call #3840

Conversation

Uh oh!

Related GitHub Issue

Description

Test Procedure

Type of Change

Pre-Submission Checklist

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!