Claude Architect · leksjon

Prosjektomfang kontra brukeromfang

.mcp.json delt i VCS kontra personlig ~/.claude.json.

Leksjon 2 av 413 trinn

Prosjektomfang kontra brukeromfang er en gratis leksjon i Claude Architect på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Claude Architect, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Claude Architect inneholder totalt 4 leksjoner.

To plasseringer for MCP-konfigurasjon

Når De kobler en MCP-server til Claude Code, må serverdefinisjonen ligge et sted. Det finnes to omfang, og å velge feil omfang er en klassisk arkitekturfeil.

Prosjektomfang — .mcp.json i roten av repositoriet, lagt inn i versjonskontroll. Delt med hele teamet.
Brukeromfang — ~/.claude.json i hjemmekatalogen. Personlig, aldri delt via VCS.

Beslutningsregelen er enkel: Trenger alle som arbeider med dette repositoriet denne serveren? Hvis ja, hører den hjemme i prosjektomfanget.

Hva en MCP-server tilbyr

Før De velger omfang, bør De huske hva De faktisk deler. En MCP-server eksponerer tre primitivtyper:

Tools — handlinger modellen kan påkalle (spørre en database, opprette en sak).
Resources — skrivebeskyttede data og kontekst, for eksempel skjemaer eller kataloger.
Prompts — gjenbrukbare maler.

Når De legger en server inn i .mcp.json, får alle teammedlemmer umiddelbart de samme Tools, Resources og Prompts — et delt og reproduserbart funksjonssett.

Prosjektomfang: .mcp.json i VCS

Prosjektomfang er riktig plassering for servere som hele teamet er avhengig av: selskapets GitHub-server, en intern databasegateway eller en delt ressurserver for designsystemet.

Fordi .mcp.json legges inn i versjonskontroll, kloner et nytt teammedlem repositoriet og har verktøyene klare — uten manuelt oppsett og uten at konfigurasjonen gradvis utvikler seg til «fungerer på min maskin».

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

Hemmeligheter skal aldri legges inn i repositoriet

Det er greit å dele en serverkonfigurasjon. Å dele et token er et sikkerhetsbrudd. Regeln er: referer til hemmeligheter gjennom miljøvariabler — legg aldri inn den faktiske verdien.

I .mcp.json skriver De ${GITHUB_TOKEN}, som hentes fra hver utviklers eget miljø ved kjøring. Den delte filen beskriver hvordan tilkoblingen skal opprettes; hver maskin leverer sin egen legitimasjon.

# 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

Brukeromfang: ~/.claude.json

Brukeromfanget ligger i ~/.claude.json og er personlig for Dem. Det er riktig plassering for servere som er Deres, og som bare ville vært til bry for et teammedlem dersom de ble delt:

En personlig server for notater eller et «second brain».
En eksperimentell server De evaluerer.
Et arbeidsflytverktøy knyttet til Deres personlige kontoer.

Det er avgjørende at brukeromfanget ikke deles via VCS — nye teammedlemmer mottar det aldri.

{
  "mcpServers": {
    "my-notes": {
      "command": "node",
      "args": ["/Users/me/tools/notes-mcp/server.js"]
    }
  }
}

Tankemodellen: speilbildet av CLAUDE.md

Dette skillet mellom omfang speiler hierarkiet i CLAUDE.md nøyaktig — samme prinsipp, en annen fil:

Prosjektnivå (./CLAUDE.md, .mcp.json) — delt via VCS, alle får det.
Brukernivå (~/.claude/CLAUDE.md, ~/.claude.json) — personlig, IKKE delt, slik at nye teammedlemmer ikke får det.

Den samme logikken gjelder for .claude/skills/ og .claude/commands/: prosjektomfanget deles via VCS, mens kopiene i ~/.claude/ er personlige.

Innføringstesten

Den tydeligste måten å avgjøre omfang på er å spørre: «Når et nytt teammedlem kloner dette repositoriet, skal dette bare fungere?»

Ja → prosjektomfang (.mcp.json). De kloner repositoriet, serveren er konfigurert, og de kan være produktive fra første dag.
Nei, dette er mitt → brukeromfang (~/.claude.json).

Hvis De legger en teamkritisk server i brukeromfanget, har De opprettet en usynlig avhengighet: Den fungerer for Dem, feiler i stillhet for alle andre, og ingen vet hvorfor.

Foretrekk community-servere fremfor egne

For standardintegrasjoner — GitHub, Slack, Postgres og filsystem — bør De foretrekke en community MCP-server fremfor å bygge en egen. Det blir mindre kode å vedlikeholde, atferden er godt testet, og serveren kan legges direkte i prosjektomfanget.

Reserver egne servere for genuint proprietære systemer der det ikke finnes noe community-alternativ. Uansett hva De velger, er omfangsbeslutningen den samme: hele teamet → .mcp.json; personlig → ~/.claude.json.

Ressurser gjør seg godt i prosjektomfanget

En MCP-Resource eksponerer skrivebeskyttet kontekst — et databaseskjema, en API-katalog eller et dokument med kodestandarder. Dette er nettopp den typen informasjon et team ønsker skal være identisk hos alle utviklere.

Lever en server som eksponerer skjemaet, i .mcp.json, så ser Claude hos hvert teammedlem det samme autoritative skjemaet. Ingen spør mot en utdatert mental modell, og svarene forblir konsistente på tvers av teamet.

{
  "mcpServers": {
    "db-schema": {
      "command": "npx",
      "args": ["-y", "@acme/mcp-schema-server"],
      "env": {
        "DATABASE_URL": "${DATABASE_URL}"
      }
    }
  }
}

Strukturerte feil gjelder uavhengig av omfang

Omfang styrer hvor serveren er definert, ikke hvor robust den er. En godt bygget MCP-server returnerer strukturerte feil uavhengig av omfang: et isError-flagg samt en errorCategory (transient / validation / business / permission), isRetryable, en melding, spørringen som ble forsøkt, og eventuelle delvise resultater.

Generelle feil som "Operation failed" hindrer intelligent gjenoppretting; strukturerte feil lar agenten velge handling, prøve på nytt eller eskalere. Bygg dette inn i serveren — det lønner seg enten den er delt eller personlig.

{
  "isError": true,
  "errorCategory": "transient",
  "isRetryable": true,
  "message": "Upstream timeout contacting issues API",
  "attempted_query": "list_issues(repo='acme/web')",
  "partial_results": []
}

Et praktisk skille

Et realistisk oppsett kombinerer begge omfangene på en ryddig måte:

Prosjekt (.mcp.json, lagt inn i repositoriet): GitHub-server, intern databasegateway og ressurserver for skjemaer — alt teamet trenger for å bygge dette produktet.
Bruker (~/.claude.json, privat): Deres personlige server for notater og et eksperimentelt verktøy De prøver ut.

De to lagene kombineres: Claude Code laster inn begge, slik at De får både teamets delte funksjonssett og Deres personlige tillegg — uten å forurense repositoriet eller spre Deres private verktøy til teammedlemmene.

Kort kontroll: Velge omfang

Bruk beslutningsregelen på et realistisk scenario.

Besvar den i den interaktive leksjonen

Oppsummering: Prosjektomfang kontra brukeromfang

Viktige poenger:

Prosjektomfang = .mcp.json, lagt inn i VCS og delt med hele teamet. Bruk det når alle trenger serveren etter kloning.
Brukeromfang = ~/.claude.json, personlig og IKKE delt via VCS. Bruk det for private eller eksperimentelle servere.
Dette speiler hierarkiet i CLAUDE.md: prosjektnivået er delt, mens brukernivået er personlig og ikke blir tilgjengelig for nye teammedlemmer.
Legg aldri inn hemmeligheter — referer til dem via miljøvariabler som ${GITHUB_TOKEN}.
Foretrekk community-servere for standardintegrasjoner, og utform strukturerte feil uavhengig av omfang.

Husk denne beslutningsregelen: Skal et nytt teammedlem få dette ved kloning? Ja → prosjekt. Mitt → bruker.

Gratis å komme i gang

Lær deg Python med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 26
Leksjoner: 104

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Prosjektomfang kontra brukeromfang» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Claude Architect, inkludert «Prosjektomfang kontra brukeromfang», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Claude Architect inneholder totalt 4 leksjoner.

Hva lærer jeg i «Prosjektomfang kontra brukeromfang»?

.mcp.json delt i VCS kontra personlig ~/.claude.json. Du øver på Claude Architect med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Claude Architect?

Ingen tidligere erfaring er nødvendig. Claude Architect på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Prosjektomfang kontra brukeromfang»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Claude Architect-leksjonen?

Ja. Alle Claude Architect-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Tools, Resources og Prompts
Prosjektomfang kontra brukeromfang
Hemmeligheter med miljøvariabler
Community-servere kontra egendefinerte servere

← Tilbake til Claude Architect