allow use five tools in one call

[qdaxb]

Related GitHub Issue

Closes: #3839

Description

1. Changed didAlreadyUseTool to an integer type, and updated the corresponding logic for setting and checking it.
2. Modified the prompts for the system and some tools.
3. 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

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (npm run lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (npm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

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 55e6c1360ea94fc230ae2fa476940bfa9b304f52. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

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]

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]

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]

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]

why limit to 5? why not make it adjustable?

[samhvw8]

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]

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]

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]

• 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]

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]

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

[hannesrudolph]

stale