Support specifying available and unavailable MCP servers in custom mode

[qdaxb]

Related GitHub Issue

Discussion: #639
Closes: #5346

Description

Added whitelist and blacklist lists. When sending an MCP prompt, the system will read the MCP server list configured for the current mode, add or filter MCP servers based on the whitelist/blacklist, and then assemble the prompt. If both lists are empty, all MCP servers will be used.

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

Adds support for specifying available/unavailable MCP servers in custom mode, with UI and logic updates for server selection.

• Behavior:
  • Adds whitelist and blacklist for MCP servers in custom mode, affecting prompt assembly.
  • If both lists are empty, all MCP servers are used.
• UI Components:
  • Adds McpSelector component in McpSelector.tsx for selecting MCP servers.
  • Updates ModesView.tsx to integrate McpSelector for custom modes.
• Logic:
  • Modifies getMcpServersSection() in mcp-servers.ts to filter servers based on whitelist/blacklist.
  • Implements memoization for server filtering in mcp-servers.ts.
• Tests:
  • Updates tests in add-custom-instructions.spec.ts and system-prompt.spec.ts to reflect new server selection logic.
• Localization:
  • Updates localization files for new MCP server selection strings.

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

[daniel-lxs]

Thanks for working on this! I've left some inline comments on specific implementation details.

The main thing that stands out is that having both allowed and denied lists seems unnecessarily complex. A single exclusion list would be simpler - just let users uncheck the MCP servers they don't want for that mode. This would avoid the confusing precedence logic and make the UI more straightforward.

The i18n support looks good and the search functionality is a nice touch. With the simplification to a single list, this would be a solid addition to the custom modes feature.

[qdaxb]

Thanks for working on this! I've left some inline comments on specific implementation details.

The main thing that stands out is that having both allowed and denied lists seems unnecessarily complex. A single exclusion list would be simpler - just let users uncheck the MCP servers they don't want for that mode. This would avoid the confusing precedence logic and make the UI more straightforward.

The i18n support looks good and the search functionality is a nice touch. With the simplification to a single list, this would be a solid addition to the custom modes feature.

thanks for reviewing @daniel-lxs

The variable and translation names I used for the two lists when encoding might be a bit ambiguous. My bad.I would like to reiterate the original intention of the design

The current implementation considers two scenarios:
A certain mode requires a certain mcp
A certain mcp can be blocked in certain scenarios

In my opinion, if only one list must be kept, it should be the "require list" rather than the "block list".

mcp tools should be used as a means of "achieving goals" like system tools:

(an agent that can achieve certain requirements) = prompt + tools = prompt + (system tools + mcp tools)

On this basis, the custom mode in the marketplace can be generalized into a "custom agent": when users install the mode, in addition to adding a custom prompt, they will also install the dependent mcp server, which can better expand the capabilities of the custom mode.

Therefore, if we think the current dual list is too complicated, perhaps we can just keep the require list, or make some adjustments to the UI (such as using tab to switch between require list/blocklist)?

[qdaxb]

update new version:

• leave only one list(required list)
• code refactor
• UI fix

[qdaxb]

@daniel-lxs Another look? Thanks!

[daniel-lxs]

Thank you @qdaxb

I left a couple of suggestions, let me know what you think!

[jmolinski]

It'd be absolutely fantastic to have this feature merged. @qdaxb are you still interested in working on this?

[daniel-lxs]

Thank you @qdaxb and sorry for the delay!

[mrubens]

I think there might be an issue with the yaml generation. By checking and unchecking boxes a few times I got my yaml to look like this:

    groups:
      - read
      - edit
      - command
      - - mcp
        - mcp:
            included:
              - github
              - context7

What is the yaml supposed to look like for this?

[Evyatar108]

hey is this planned on being merged?

[daniel-lxs]

Proposing to close this PR and follow up with a version that stabilizes the schema. Two blocking issues remain:

1. Canonical YAML shape is unstable

• Current schema accepts both tuple and object forms, which leads to outputs like:

groups:
  - read
  - edit
  - command
  - - mcp
    - mcp:
        included:
          - github
          - context7

• Action: choose one canonical representation for serialization and always emit that form (parser can remain lenient for backward compatibility). Prefer the plain object form:

- mcp:
    included:
      - github
      - context7

Touchpoint: packages/types/src/mode.ts (groupEntrySchema)
https://github.com/RooCodeInc/Roo-Code/blob/1f4d3c3e7741c6787b06e5482c24cd52d8122477/packages/types/src/mode.ts

2. Empty "included" semantics must be explicit and enforced end-to-end

• If empty means "all servers", ensure this contract holds across types, UI round-trips, and prompt assembly so it never degrades into "no servers" by accident.
• Define and document the rule, and make prompt generation implement it consistently.
  Touchpoints:
• packages/types/src/mode.ts (groupOptionsSchema / data model)
  https://github.com/RooCodeInc/Roo-Code/blob/1f4d3c3e7741c6787b06e5482c24cd52d8122477/packages/types/src/mode.ts
• src/core/prompts/sections/mcp-servers.ts (prompt assembly logic)
  https://github.com/RooCodeInc/Roo-Code/blob/1f4d3c3e7741c6787b06e5482c24cd52d8122477/src/core/prompts/sections/mcp-servers.ts

Once these are addressed with a stable, canonical output and explicit empty semantics, we can proceed on a cleaner foundation.