[FEATURE] MCP Scoping by Tool (Claude Code vs Cowork)

Resolved 💬 3 comments Opened Mar 26, 2026 by arcaven Closed Mar 30, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

MCPs configured in the Claude environment are accessible to both Claude Code and Cowork with no scoping mechanism. This creates operational and security friction:

  1. Context waste: MCPs intended only for Cowork (e.g., Slack) consume tokens in Claude Code's context budget even when not needed. With MCP Tool Search now active, Claude Code may dynamically search for and load MCPs never intended for it.
  1. Unwanted autonomous behavior: Mentioning a human by name in the context of GitHub issues in Claude Code can trigger Slack searches to "learn more about them." Preventing this requires explicit negative instructions, adding behavioral overhead.
  1. Mining risk: Claude Code can autonomously mine Slack channels if it decides those tools are relevant to a task. This violates principle of least privilege—Code should not have implicit access to company communication channels.
  1. No opt-in control per tool: I want Cowork to have full Slack access for knowledge work, but Claude Code in terminal mode should have zero access. Currently impossible without manual MCP management or separate machine profiles.

Proposed Solution

Allow MCPs to be tagged/scoped as:

  • cowork-only — accessible to Cowork, not Claude Code
  • code-only — accessible to Claude Code, not Cowork
  • shared — both (default for backward compatibility)

Example configuration:

{
  "mcpServers": {
    "slack": {
      "command": "npx",
      "args": ["-y", "@anthropic/slack-mcp"],
      "scope": "cowork-only"
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@anthropic/github-mcp"],
      "scope": "shared"
    },
    "perplexity": {
      "command": "npx",
      "args": ["-y", "@perplexity-ai/mcp-server"],
      "scope": "code-only"
    }
  }
}

Alternatively: UI-level scoping in Claude Desktop where you can toggle which MCPs are visible to which tool.

Alternative Solutions

Current workarounds:

  • Setting ENABLE_CLAUDEAI_MCP_SERVERS=false to disable all cloud MCPs — kills everything, not selective
  • Adding MCPs to permissions.deny list — blocks the tool but it still loads and consumes context
  • Writing explicit negative instructions ("never use Slack") — fragile, adds prompt overhead
  • Manually editing config between Claude Code and Cowork sessions

None of these provide clean per-tool scoping.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

  1. Developer configures Slack MCP for Cowork knowledge synthesis (incident review, summarizing threads)
  2. Same developer opens Claude Code to write infrastructure code
  3. While discussing a GitHub issue, they mention a colleague's name
  4. Claude Code autonomously searches Slack for that person — unintended, potentially surfacing sensitive HR/private channels
  5. With scope: "cowork-only" on the Slack MCP, Claude Code never sees it. Cowork still has full access. Zero config editing required.

Additional Context

Refiled from #23996 (auto-closed for inactivity, locked without team engagement) and freeform #39488.

This is especially critical as MCP Tool Search gets smarter about lazy-loading — the more dynamic the loading, the more important explicit scoping becomes.

Related: the sibling request for MCP Profiles (#24000 / refiled) solves the bundling problem. This issue solves the simpler per-server scoping problem. Both are complementary.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗