[FEATURE] Workspace/org-level MCP configuration hierarchy (between user-global and project-local)

Resolved 💬 3 comments Opened Mar 14, 2026 by Erick-Zanetti Closed Apr 11, 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

The current MCP scoping system has two levels:

  • User global (~/.claude.json) — applies to every project
  • Project local (.mcp.json in project root) — applies to one project

There is no intermediate level for workspace or organization-level configuration.

This is a real limitation for developers who work across multiple organizations or contexts
on the same machine. For example:

  • ~/client-a/ → uses Grafana, Graylog, specific internal tooling
  • ~/client-b/ → uses AWS tools, Datadog
  • ~/personal/ → none of the above

Today, the only options are:

  1. Add all MCPs globally (pollutes every context with irrelevant tools, wastes tokens)
  2. Add .mcp.json to every individual project (high maintenance, repetitive)

Neither is acceptable at scale.

Proposed Solution

Support directory-level MCP config resolution, similar to how Git, ESLint, and other
tools traverse upward to find the nearest config file.

When Claude Code starts, it should look for .mcp.json walking upward from the current
working directory, merging configs at each level:

~/.claude.json                    ← user global (always loaded)
~/client-a/.mcp.json              ← workspace level (loaded when cwd is inside ~/client-a/)
~/client-a/some-project/.mcp.json ← project level (loaded when cwd is this project)

Each level supplements the one above (same behavior as today between user and project).

  • Multi-client/org developers: different contexts use completely different tooling stacks
  • Context cleanliness: irrelevant MCP tools waste context window tokens on every prompt
  • Security: avoid exposing org-specific credentials to unrelated projects
  • Portability: a workspace-level .mcp.json can be version-controlled in a private

dotfiles repo per client/org

Alternative Solutions

  • Shell aliases that swap ~/.claude.json before launching — fragile and error-prone
  • Symlinking .mcp.json into every project — maintenance nightmare
  • Putting everything in global — defeats the purpose of scoping

Priority

Medium - Would be very helpful

Feature Category

Developer tools/SDK

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

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