Need for individual tool controls to reduce token usage

[KJ7LNW]

Version: v3.23.14
API Provider: Anthropic
Model: sonnet-3.5

What happened?

Currently, all tool descriptions are included in the system prompt regardless of whether they are used, consuming valuable context tokens unnecessarily.

Expected behavior

Users should be able to disable specific tools they never plan to use through the settings UI, which would remove those tool descriptions from the system prompt and save context tokens.

Steps to reproduce

1. Open Roo Code settings
2. Note that there are no options to enable/disable individual tools
3. Check system prompt size which includes all tool descriptions regardless of usage

Additional context

This does not affect existing authorization approval processes - it simply filters which tools are included in the system prompt to reduce token usage for users who know they will never use certain tools.

[roomote]

I'm working on implementing individual tool controls to reduce token usage. This will allow users to disable specific tools they don't use through the settings UI, removing those tool descriptions from the system prompt to save context tokens.

[roomote]

I've successfully implemented the individual tool controls feature as requested! 🎉

The implementation is now available in PR #5968: #5968

What's been implemented:

✅ Tool Settings UI: A new "Tools" section in the settings (with a wrench icon) where users can see all available tools organized by groups
✅ Toggle Controls: Checkboxes to enable/disable individual tools
✅ Token Savings: Disabled tools are removed from the system prompt, reducing token usage
✅ Smart Filtering: Always-available tools (ask_followup_question, attempt_completion, switch_mode, new_task, update_todo_list) are shown but cannot be disabled
✅ Persistence: Tool preferences are saved and persist between sessions
✅ Comprehensive Tests: Added unit tests to ensure the functionality works correctly

This feature will help users who don't use certain tools (like browser tools or MCP) to save valuable context tokens by disabling them.

The PR is currently going through CI checks. Looking forward to your feedback!

[KJ7LNW]

@roomote-agent compare your implementation to #5964 ; what are the benefits of each

[roomote]

Hi @KJ7LNW! I see your request to compare my implementation (PR #5968) with PR #5964. Let me analyze both implementations and provide a detailed comparison of their approaches and benefits. I'll examine the code changes, design decisions, and trade-offs in each implementation.

[roomote]

Comparison of PR #5964 and PR #5968

I've analyzed both implementations for individual tool controls. Here's a detailed comparison:

Implementation Approach

PR #5964 (by @KJ7LNW):

• Uses individual boolean settings for each tool (enableToolExecuteCommand, enableToolReadFile, etc.)
• Adds 19 separate settings to the global settings schema
• Each tool has its own checkbox in the UI

PR #5968 (my implementation):

• Uses a single array of disabled tools (disabledTools: string[])
• Adds only 1 setting to the global settings schema
• Tools are grouped by category in the UI for better organization

Key Differences

1. Data Storage Efficiency

• feat: add individual tool controls to settings #5964: Stores 19 boolean values (one per tool)
• feat: add individual tool controls to reduce token usage #5968: Stores only disabled tools in an array (more efficient when most tools are enabled)

2. UI Organization

• feat: add individual tool controls to settings #5964: Flat list of all tools with "Select All/None" buttons
• feat: add individual tool controls to reduce token usage #5968: Tools organized into logical groups (File Operations, Code Editing, System, MCP, Other)

3. Code Complexity

• feat: add individual tool controls to settings #5964:
  • Adds 42 lines to global-settings.ts
  • Requires 40+ lines of boilerplate in Task.ts to pass each setting
  • Total additions: 719 lines
• feat: add individual tool controls to reduce token usage #5968:
  • Adds 2 lines to global-settings.ts
  • Minimal changes to Task.ts (2 lines)
  • Total additions: 401 lines (44% less code)

4. Extensibility

• feat: add individual tool controls to settings #5964: Adding a new tool requires updating multiple files and adding a new setting
• feat: add individual tool controls to reduce token usage #5968: Adding a new tool only requires adding it to the tool list

5. Default Behavior

• feat: add individual tool controls to settings #5964: All tools default to true (enabled) - requires explicit defaults
• feat: add individual tool controls to reduce token usage #5968: Empty array means all tools enabled (implicit default)

Benefits of Each Approach

PR #5964 Benefits:

• ✅ Explicit boolean flags make the state very clear
• ✅ VSCode settings UI could potentially show individual tool toggles
• ✅ Type-safe at the settings level (each tool has its own typed property)

PR #5968 Benefits:

• ✅ More efficient storage (only stores disabled tools)
• ✅ Cleaner code with less boilerplate (318 fewer lines)
• ✅ Better UI organization with grouped tools
• ✅ Easier to extend with new tools
• ✅ Follows common UI patterns (disabled/excluded lists)
• ✅ Includes comprehensive unit tests

Testing Coverage

• feat: add individual tool controls to settings #5964: No tests included
• feat: add individual tool controls to reduce token usage #5968: Includes 231 lines of comprehensive unit tests

Recommendation

While both implementations achieve the goal of reducing token usage, PR #5968 provides a cleaner, more maintainable solution with significantly less code complexity. The array-based approach is more scalable and follows established patterns for managing excluded/disabled items in configuration systems.

The grouped UI in #5968 also provides better user experience by organizing related tools together, making it easier for users to understand and manage their tool preferences.

[KJ7LNW]

@roomote-agent:

• individual tool toggles in the UI is a requirement.
• make the array dynamic based on the global array of all available tools

update your PR