[ENHANCEMENT] Option to override the tool descriptions provided by MCP services.

[ksze]

Problem (one or two sentences)

Some MCP services are nice to have, but have rather questionable tool descriptions that attempt to actively steer the client agent. For example, MiniMax's MCP provides tool descriptions that say the client agent MUST (!!!) use the MiniMax MCP's tools.

Context (who is affected and when)

People who want to have some nice MCPs available but don't completely agree with the directives in the MCPs' tool descriptions.

Desired behavior (conceptual, not technical)

Upon successful activation, the MCP panel would show the tool description in an editable text box. The user may edit that tool description to make it more to the user's liking.

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Overview

Add the ability for users to override MCP tool descriptions. This follows the existing patterns for per-tool settings like alwaysAllow and disabledTools.

Implementation Plan

1. Add descriptionOverride to the McpTool type (packages/types/src/mcp.ts)

• Add an optional descriptionOverride?: string field to the McpTool type

2. Store overrides in MCP settings config (alongside alwaysAllow, disabledTools)

• Add a toolDescriptions map (Record<string, string>) to the server config in the MCP settings JSON file (e.g., { "mcpServers": { "server-name": { ..., "toolDescriptions": { "tool-name": "custom description" } } } })

3. Load overrides in McpHub.fetchToolsList() (src/services/mcp/McpHub.ts)

• When building the tools list from MCP server responses, read toolDescriptions from the config and apply any overrides as descriptionOverride on each tool

4. Add McpHub.updateToolDescription() method (src/services/mcp/McpHub.ts)

• New method to persist a custom description override for a specific tool to the settings file
• Add a corresponding McpHub.resetToolDescription() or pass undefined/empty string to clear the override

5. Use override in tool generation (src/core/prompts/tools/native-tools/mcp_server.ts)

• In getMcpServerTools(), use tool.descriptionOverride || tool.description when building the tool definition sent to the LLM

6. Add webview message handler (src/core/webview/webviewMessageHandler.ts)

• Handle a new updateMcpToolDescription message type that calls McpHub.updateToolDescription()

7. Update the UI (webview-ui/src/components/mcp/McpToolRow.tsx)

• Show the tool description in an editable text area (or make it click-to-edit)
• When the description differs from the original, show a "reset" button to restore the original
• Display a visual indicator when a description has been overridden
• Send the updateMcpToolDescription message on save

8. Add WebviewMessage type for the new message

9. Tests

• Unit tests for McpHub.updateToolDescription()
• Unit tests for the override logic in fetchToolsList()
• Unit tests for getMcpServerTools() using descriptionOverride
• UI component tests for the editable description in McpToolRow

Design Notes

• This follows the exact same pattern as the existing alwaysAllow and disabledTools per-tool settings
• The original description from the MCP server is always preserved; the override is a separate field
• Users can always reset to the original description
• The override is stored in the MCP settings JSON file, so it persists across restarts

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.