0Pricing
Claude Architect · 课时

项目范围与用户范围

VCS 中共享的 .mcp.json 与个人的 ~/.claude.json。

项目范围与用户范围 是 CoddyKit 上的免费 Claude Architect 课时。 这是第 2 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Claude Architect 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Claude Architect 课程共包含 4 节课。

本课时的部分内容尚未翻译，以英文显示。

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.json at the repo root, committed to version control. Shared with the whole team.
  • User scope — ~/.claude.json in 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 repo

User 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.

常见问题解答

「项目范围与用户范围」课时是免费的吗？

是的 — 「项目范围与用户范围」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Claude Architect 课程的其余内容，请升级到 CoddyKit PRO。 Claude Architect 课程共包含 4 节课。

「项目范围与用户范围」这节课中我会学到什么？

VCS 中共享的 .mcp.json 与个人的 ~/.claude.json。 你通过在浏览器中直接运行的动手代码来练习 Claude Architect，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 Claude Architect 需要有经验吗？

无需任何先前经验。CoddyKit 上的 Claude Architect 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 2 节课，共 4 节。

「项目范围与用户范围」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 Claude Architect 课中编写并运行代码吗？

能。每节 Claude Architect 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

  1. 工具、资源与提示词
  2. 项目范围与用户范围
  3. 使用环境变量管理机密
  4. 社区服务器与自定义服务器
← 返回 Claude Architect