[ENHANCEMENT] Per-Mode MCP Server Restrictions (Whitelist/Blacklist) to Prevent Context Bloat

[simurg79]

Problem (one or two sentences)

Currently, Roo Code lacks the ability to restrict which MCP servers are loaded on a per-mode basis. If a custom mode includes the "mcp" permission in its tool groups, Roo Code injects the descriptions and schemas for all globally and project-enabled MCP servers directly into the system prompt.

This brute-force approach causes severe issues:

Context Bloat: Dumping massive tool schemas into the prompt wastes thousands of tokens per request and degrades the model's reasoning capabilities.

Hard Tool Limits: Strict tool limits on modern models (e.g., the 128-tool limit) are easily exhausted when running multiple robust MCP servers simultaneously, causing API calls to outright fail.

Lack of Isolation: Specialized modes (e.g., a pure "Database Mode" or "Documentation Mode") get polluted with unrelated development tools, breaking the single-responsibility principle of Custom Modes.

Context (who is affected and when)

Happens for me when I want to use GPT5.4 which has a tool limit of 128.

Desired behavior (conceptual, not technical)

I would like the ability to explicitly whitelist or blacklist specific MCP servers within a custom mode's configuration (via .roomodes or the Custom Mode UI).

For example, adding an allowed_mcps or blocked_mcps array to the mode definition:

JSON
{
"customModes": [
{
"slug": "database-architect",
"name": "Database Architect",
"roleDefinition": "You manage the database schema...",
"groups": ["read", "edit", "mcp"],
"allowed_mcps": ["postgres-mcp", "redis-mcp"]
}
]
}
If allowed_mcps is defined, Roo Code should only inject the schemas for those specific servers into the system prompt for that mode, ignoring all other enabled MCPs.

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

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

Problem Summary

When a custom mode includes the mcp tool group, ALL enabled MCP server tool schemas are injected into the system prompt and tool list. This causes context bloat and can exceed model tool limits (e.g., GPT-5.4's 128-tool limit).

Proposed Approach: allowedMcpServers field on ModeConfig

Add an optional allowedMcpServers field to ModeConfig that acts as a whitelist. When defined, only the listed MCP servers' tools are injected for that mode. When omitted, all servers are included (preserving current behavior).

Changes Required

1. Type definition (packages/types/src/mode.ts)

• Add allowedMcpServers: z.array(z.string()).optional() to modeConfigSchema
• This makes ModeConfig.allowedMcpServers an optional string[]

2. MCP tool filtering (src/core/prompts/tools/native-tools/mcp_server.ts)

• Update getMcpServerTools() to accept an optional allowedMcpServers?: string[] parameter
• When provided, filter mcpHub.getServers() to only include servers whose name is in the whitelist

3. Build tools pipeline (src/core/task/build-tools.ts)

• Pass the current mode's allowedMcpServers from the ModeConfig to getMcpServerTools()

4. Filter tools for mode (src/core/prompts/tools/filter-tools-for-mode.ts)

• Update filterMcpToolsForMode() to accept and pass through allowedMcpServers
• OR apply server-level filtering before the MCP tools reach the filter function

5. System prompt (src/core/prompts/system.ts)

• When building the system prompt, pass allowedMcpServers so the capabilities section and MCP server info reflect only the allowed servers for the mode

6. UI updates (webview-ui/src/components/modes/ModesView.tsx)

• Add an MCP server selection UI in the mode editor when the mcp group is enabled
• Show available MCP servers as checkboxes; selected ones populate allowedMcpServers
• When none are selected (or the field is absent), all servers are included (backward compatible)

7. Tests

• Add tests for getMcpServerTools() with allowedMcpServers filtering
• Add tests for filterMcpToolsForMode() with server restrictions
• Add tests for modeConfigSchema with the new optional field
• Update existing tests as needed

Configuration Example

customModes:
  - slug: database-architect
    name: Database Architect
    roleDefinition: "You manage the database schema..."
    groups:
      - read
      - edit
      - mcp
    allowedMcpServers:
      - postgres-mcp
      - redis-mcp

Design Decisions

• Whitelist-only approach (no separate blocklist): Simpler to reason about, and the user's request centers on whitelisting. A blocklist could be added later if needed.
• Server-name matching: Uses the server name as it appears in MCP settings (the key in mcpServers config). This is the same name shown in the UI.
• Backward compatible: The field is optional. When absent, behavior is identical to today (all servers included).
• Applies to both native MCP tools and use_mcp_tool/access_mcp_resource: The filtering happens at the tool-building level so both code paths benefit.

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

[simurg79]

@roomote , I approve this plan. This is exactly what I need and it will be great help. Allowlisting (aka whitelisting) is enoug which mean by default value of allowedMcpServers is * or all. * or all can be interpreted as the default behavior.

[roomote-v0]

Thanks for the approval @simurg79! I've seen your comment and will proceed with the implementation. I'll open a draft PR to share progress shortly.

[roomote-v0]

Opened a draft PR with my attempt at implementing the per-mode MCP server allowlist: #12019

The PR adds an optional allowedMcpServers field to ModeConfig that filters which MCP servers are injected per mode. When omitted, all servers are included (backward compatible). Feedback welcome!