Claude Architect · Lektion

Projekt- vs. Benutzerbereich

.mcp.json gemeinsam in der VCS-Verwaltung vs. persönliche ~/.claude.json

Projekt- vs. Benutzerbereich ist eine kostenlose Claude Architect-Lektion auf CoddyKit. Dies ist Lektion 2 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Claude Architect-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Claude Architect-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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.

Häufig gestellte Fragen

Ist die Lektion „Projekt- vs. Benutzerbereich“ kostenlos?

Ja — der vollständige Text von „Projekt- vs. Benutzerbereich“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Claude Architect-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Claude Architect-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Projekt- vs. Benutzerbereich“?

.mcp.json gemeinsam in der VCS-Verwaltung vs. persönliche ~/.claude.json Du übst Claude Architect mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Claude Architect zu starten?

Keine Vorkenntnisse erforderlich. Claude Architect auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 2 von 4.

Wie lange dauert die Lektion „Projekt- vs. Benutzerbereich“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Claude Architect-Lektion Code schreiben und ausführen?

Ja. Jede Claude Architect-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

Tools, Ressourcen und Prompts
Projekt- vs. Benutzerbereich
Secrets mit Umgebungsvariablen
Community- vs. benutzerdefinierte Server

← Zurück zu Claude Architect