[ENHANCEMENT] Add onlyAllow support for MCP server tools (takes precedence over disabledTools)

[dmjdarshan]

Problem (one or two sentences)

Summary

Add a new optional MCP server config field: onlyAllow.

When onlyAllow is set and non-empty, Roo should enable only the listed MCP tools for prompt use (enabledForPrompt: true) and disable all other tools on that server.

This should take precedence over disabledTools.

---

Problem / Motivation

Some MCP servers expose 100+ tools.
Today, if I want to use only 3 tools, I must put all other ~97 tools in disabledTools, which is noisy, hard to maintain, and error-prone.

onlyAllow makes this scalable and cleaner:

• small allowlist for the tools I need
• no huge denylist maintenance

---

Proposed Behavior

For a server config:

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["server.js"],
      "onlyAllow": ["toolA", "toolB", "toolC"],
      "disabledTools": ["toolA"]
    }
  }
}

---

Context (who is affected and when)

Users who configure MCP servers with large tool catalogs (often dozens or 100+ tools) are affected when they only need a small subset of tools in Roo Code.

This is most visible when:

• onboarding a new MCP server with many default tools
• trying to keep model tool selection focused and reliable
• maintaining mcp.json over time as server tool lists grow/change

Today, these users must populate disabledTools with a long denylist, which is tedious and hard to maintain.

---

Desired behavior (conceptual, not technical)

Users should be able to declare only the MCP tools they want Roo Code to use, and have all other tools excluded automatically.

In simple terms:

• “Use only these few tools from this server.”
• No need to manually list every unwanted tool.
• If both allowlist and denylist are present, allowlist should win to keep behavior predictable.

---

Constraints / preferences (optional)

• Keep current behavior unchanged for users who do not use the new option.
• Keep config semantics clear and predictable (explicit precedence rules).
• Avoid performance overhead during tool list loading.
• Keep UX consistent: enabled/disabled status should match across backend validation and UI display.
• Prefer minimal, low-risk changes limited to MCP tool enablement logic.

---

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)

Given an MCP server config without onlyAllow
When tools are fetched for that server
Then tool enablement follows existing disabledTools behavior
And existing users see no behavior change.

Given an MCP server config with onlyAllow containing ["toolA", "toolB"]
When tools are fetched for that server
Then only toolA and toolB are marked enabled for prompt use
And all other tools from that server are marked disabled.

Given an MCP server config with both onlyAllow and disabledTools
When tools are fetched for that server
Then onlyAllow takes precedence over disabledTools
And a tool listed in onlyAllow remains enabled even if also listed in disabledTools.

Given an MCP server config where onlyAllow is an empty array
When tools are fetched for that server
Then behavior falls back to disabledTools logic
And tools are not globally disabled just because onlyAllow exists but is empty.

Given MCP tool execution and UI filtering that rely on enabledForPrompt
When onlyAllow is active
Then non-allowlisted tools are not available for prompt/tool selection
And validation rejects attempts to use disabled tools consistently with current error handling.

---

Proposed approach (optional)

Introduce an optional onlyAllow field in each mcpServers.<server> config block.

Behavior:

• If onlyAllow is present and non-empty, only those listed tools are enabled for prompt usage.
• All non-listed tools are treated as disabled for prompt usage.
• onlyAllow takes precedence over disabledTools when both are present.
• If onlyAllow is absent (or empty), keep current behavior based on disabledTools.

This keeps large MCP configurations manageable when a server exposes many tools but the user needs only a small subset.

---

Trade-offs / risks (optional)

Trade-offs / risks

• Config complexity: Adds one more config option, so precedence rules must be clearly documented.
• Unexpected lock-down: If users set onlyAllow and forget to include a needed tool, that tool won’t appear enabled.
• Migration confusion: Existing users familiar with only disabledTools may need guidance on when to use allowlist vs denylist.
• Validation/UX consistency: UI and backend must consistently reflect the same enabled state to avoid confusion.

Overall, the upside is strong for large MCP servers: significantly smaller, safer, and easier-to-maintain configs.

[roomote-v0]

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

Proposed Implementation Plan

1. Add onlyAllow to the server config schema (src/services/mcp/McpHub.ts)

• Add onlyAllow: z.array(z.string()).optional() to BaseConfigSchema (line 67-73)
• This keeps it optional so existing configs are unaffected

2. Update fetchToolsList to respect onlyAllow (src/services/mcp/McpHub.ts, ~line 980-1031)

• Read onlyAllow from the server config alongside alwaysAllow and disabledTools
• Update the enabledForPrompt logic:
  • If onlyAllow is present and non-empty: enabledForPrompt = onlyAllow.includes(tool.name) (takes precedence over disabledTools)
  • If onlyAllow is absent or empty: fall back to current behavior enabledForPrompt = !disabledToolsList.includes(tool.name)

3. Update toggleToolEnabledForPrompt (src/services/mcp/McpHub.ts, ~line 1880)

• When toggling a tool's enabled state, check if onlyAllow exists on the server config
• If onlyAllow is present and non-empty: add/remove from onlyAllow list instead of disabledTools
• If onlyAllow is absent or empty: use existing disabledTools behavior
• This requires adding "onlyAllow" as a valid value for the listName parameter of updateServerToolList

4. Add/update tests (src/services/mcp/__tests__/McpHub.spec.ts)

• Test: onlyAllow present and non-empty enables only listed tools
• Test: onlyAllow takes precedence over disabledTools (tool in both lists remains enabled)
• Test: Empty onlyAllow array falls back to disabledTools behavior
• Test: Absent onlyAllow keeps current behavior unchanged
• Test: toggleToolEnabledForPrompt modifies onlyAllow when it exists

Files Changed

• src/services/mcp/McpHub.ts - Schema + enablement logic + toggle logic
• src/services/mcp/__tests__/McpHub.spec.ts - New test cases

Why This Approach

• Minimal, low-risk change limited to MCP tool enablement logic
• No changes needed to the McpTool type in packages/types/src/mcp.ts (the existing enabledForPrompt boolean already handles the UI/prompt filtering)
• No changes to downstream consumers (UseMcpToolTool.ts, mcp_server.ts) since they already check enabledForPrompt
• Preserves full backward compatibility for users without onlyAllow

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