Project vs User Scope
.mcp.json shared in VCS vs personal ~/.claude.json.
Project vs User Scope is a free Claude Architect lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Claude Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Two Homes for MCP Config
When you wire an MCP server into Claude Code, the server definition has to live somewhere. There are two scopes, and choosing the wrong one is a classic architecture mistake.
- Project scope —
.mcp.jsonat the repo root, committed to version control. Shared with the whole team. - User scope —
~/.claude.jsonin your home directory. Personal, never shared via VCS.
The decision rule is simple: does everyone working on this repo need this server? If yes, it belongs in project scope.
What an MCP Server Provides
Before scoping, recall what you're actually sharing. An MCP server exposes three primitive types:
- Tools — actions the model can invoke (query a DB, open a ticket).
- Resources — read-only data and context, like schemas or catalogs.
- Prompts — reusable templates.
When you commit a server to .mcp.json, every teammate instantly gets the same Tools, Resources, and Prompts — a shared, reproducible capability surface.
Project Scope: .mcp.json in VCS
Project scope is the right home for servers the whole team relies on: the company's GitHub server, an internal database gateway, a shared design-system resource server.
Because .mcp.json is committed, a new teammate clones the repo and the tooling is already there — no manual setup, no "works on my machine" drift.
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}Secrets Never Get Committed
Sharing a server config is fine. Sharing a token is a breach. The rule: reference secrets through environment variables — never commit the raw value.
In .mcp.json you write ${GITHUB_TOKEN}, which expands from each developer's own environment at runtime. The shared file describes how to connect; each machine supplies its own credential.
# Each developer exports their own token locally
export GITHUB_TOKEN="ghp_yourPersonalTokenHere"
# .mcp.json references it as ${GITHUB_TOKEN} — the
# literal token value is NEVER written into the repoUser Scope: ~/.claude.json
User scope lives in ~/.claude.json and is personal to you. It is the right place for servers that are yours and would only get in a teammate's way if shared:
- A personal notes / second-brain server.
- An experimental server you're evaluating.
- A workflow tool tied to your individual accounts.
Crucially, user scope is not shared via VCS — new teammates never receive it.
{
"mcpServers": {
"my-notes": {
"command": "node",
"args": ["/Users/me/tools/notes-mcp/server.js"]
}
}
}The Mental Model: Mirror of CLAUDE.md
This scope split mirrors the CLAUDE.md hierarchy exactly — same principle, different file:
- Project-level (
./CLAUDE.md,.mcp.json) — shared via VCS, everyone gets it. - User-level (
~/.claude/CLAUDE.md,~/.claude.json) — personal, NOT shared, so new teammates miss it.
Same logic governs .claude/skills/ and .claude/commands/: project scope is shared via VCS, the ~/.claude/ copies are personal.
The Onboarding Test
The sharpest way to decide scope: ask "When a new teammate clones this repo, should this just work?"
- Yes → project scope (
.mcp.json). They clone, the server is configured, they're productive on day one. - No, this is mine → user scope (
~/.claude.json).
Put a team-critical server in user scope and you've created an invisible dependency: it works for you, silently fails for everyone else, and nobody knows why.
Prefer Community Servers Over Custom
For standard integrations — GitHub, Slack, Postgres, filesystem — prefer a community MCP server over building your own. Less code to maintain, well-tested behavior, and it drops cleanly into project scope.
Reserve custom servers for genuinely proprietary systems where no community option exists. Whatever you choose, the scoping decision is the same: team-wide → .mcp.json; personal → ~/.claude.json.
Resources Shine in Project Scope
An MCP Resource exposes read-only context — a DB schema, an API catalog, a coding-standards doc. These are exactly the things a team wants identical across every developer.
Ship a schema-exposing server in .mcp.json and every teammate's Claude sees the same authoritative schema. No one queries against a stale mental model, and answers stay consistent across the team.
{
"mcpServers": {
"db-schema": {
"command": "npx",
"args": ["-y", "@acme/mcp-schema-server"],
"env": {
"DATABASE_URL": "${DATABASE_URL}"
}
}
}
}Structured Errors Survive Either Scope
Scope governs where the server is defined, not how robust it is. A well-built MCP server returns structured errors regardless of scope: an isError flag plus an errorCategory (transient / validation / business / permission), isRetryable, a message, the attempted query, and any partial results.
Generic errors like "Operation failed" block intelligent recovery; structured ones let the agent route, retry, or escalate. Design this into the server — it pays off whether shared or personal.
{
"isError": true,
"errorCategory": "transient",
"isRetryable": true,
"message": "Upstream timeout contacting issues API",
"attempted_query": "list_issues(repo='acme/web')",
"partial_results": []
}A Practical Split
A realistic setup combines both scopes cleanly:
- Project (
.mcp.json, committed): GitHub server, internal DB gateway, schema resource server — everything the team needs to build this product. - User (
~/.claude.json, private): your personal notes server, an experimental tool you're trialing.
The two layers compose: Claude Code loads both, giving you the shared team surface plus your personal extras — without polluting the repo or leaking your private tooling onto teammates.
Quick Check: Choosing Scope
Apply the decision rule to a real scenario.
Recap: Project vs User Scope
Key takeaways:
- Project scope =
.mcp.json, committed to VCS, shared with the whole team. Use it when everyone needs the server on clone. - User scope =
~/.claude.json, personal, NOT shared via VCS. Use it for your private or experimental servers. - Mirrors the CLAUDE.md hierarchy: project-level is shared, user-level is personal and missed by new teammates.
- Never commit secrets — reference them via env vars like
${GITHUB_TOKEN}. - Prefer community servers for standard integrations; design structured errors regardless of scope.
Decision rule to remember: should a new teammate get this on clone? Yes → project. Mine → user.
Frequently asked questions
Is the “Project vs User Scope” lesson free?
Yes — the full text of “Project vs User Scope” is free to read here on the web, and the Claude Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Claude Architect course, upgrade to CoddyKit PRO.
What will I learn in “Project vs User Scope”?
.mcp.json shared in VCS vs personal ~/.claude.json. You practise Claude Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Claude Architect?
No prior experience is required. Claude Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Project vs User Scope” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Claude Architect lesson?
Yes. Every Claude Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.