MCP-server i VS Code: installera och begränsa steg för steg

Vad du har när du är klar

Tre saker, och alla tre går att kontrollera:

Guiden använder referensservern för filsystem som exempel eftersom den har en tydlig gräns mellan läs- och skrivverktyg. Samma arbetsgång gäller för andra servrar; det är bara verktygsnamnen som byts. Varför avgränsningen är själva skyddet när en agent får verktyg går guiden om agenter och automatisering igenom.

Steg 1: välj var konfigurationen ska ligga

VS Code läser MCP-konfiguration från två håll som du behöver hålla isär. Enligt VS Codes dokumentation om MCP-servrar ligger arbetsytans konfiguration i .vscode/mcp.json i projektet, och dokumentationen säger uttryckligen att du kan checka in den för att dela servrarna med teamet. Användarkonfigurationen öppnar du med kommandot MCP: Open User Configuration; den ligger i din användarprofil och servrarna där finns i alla dina arbetsytor.

Dokumentationen nämner även formatet .mcp.json i projektroten med toppnyckeln mcpServers i stället för servers. Välj ett av formaten per projekt så att ingen behöver leta efter var en server kommer ifrån.

Steg 2: välj stdio eller http

VS Code stöder serverformerna stdio, http och sse. Skillnaden mellan de två första avgör var koden körs. Enligt MCP:s arkitekturbeskrivning kommunicerar stdio via standard in och ut mellan lokala processer på samma maskin, medan Streamable HTTP används för fjärrservrar och stöder autentisering med bland annat bearer-token, API-nycklar och egna headrar.

Avvägningen är konkret. En stdio-server är ett program som VS Code startar på din dator, och VS Codes dokumentation varnar för att lokala MCP-servrar kan köra godtycklig kod på maskinen. En http-server kör hos någon annan, så frågan flyttas till vilka data du skickar dit och vilken token den får. Ingen av dem är den säkra; de har olika risker.

Steg 3: skriv mcp.json utan nycklar

Börja med den lokala servern. Argumentet ${workspaceFolder} är en av VS Codes fördefinierade variabler och begränsar servern till arbetsytan. Referensserverns README anger att alla filoperationer är begränsade till de tillåtna katalogerna.

{
  "servers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "${workspaceFolder}"]
    }
  }
}

Här är en typisk felplacering av en nyckel, följd av rättelsen. Det enda som skiljer är var värdet kommer ifrån:

// Före: nyckeln hamnar i versionshistoriken
{
  "servers": {
    "tjanst": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer sk-live-HEMLIG" }
    }
  }
}

// Efter: VS Code frågar efter värdet
{
  "inputs": [
    { "type": "promptString", "id": "api-token", "description": "API-token för tjanst", "password": true }
  ],
  "servers": {
    "tjanst": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": { "Authorization": "Bearer ${input:api-token}" }
    }
  }
}

Enligt referensen för MCP-konfiguration frågar VS Code efter värdet första gången servern startar och sparar det sedan säkert. password: true döljer det du skriver. För en stdio-server fungerar samma hänvisning i env. Har servern redan legat med en riktig nyckel i en commit räcker det inte att ändra filen – nyckeln ligger kvar i historiken och ska bytas. Mer om det i guiden om säkerhet och känsliga data.

Steg 4: förstå förtroendet innan du litar på repot

Här finns guidens minst självklara punkt. Enligt dokumentationen ärver arbetsytans MCP-servrar Workspace Trust: när du litar på en arbetsyta kan servrarna i .vscode/mcp.json starta utan någon separat förtroendefråga, även efter att deras konfiguration ändrats. I begränsat läge startar de inte alls.

Förtroendedialogen du kanske väntar dig hör i stället till servrar från andra källor, som enligt dokumentationen kan ha ett eget förtroendebeslut. För dem visar VS Code en dialog när servern startar första gången eller när konfigurationen ändras, med en länk där du kan granska konfigurationen. Litar du inte på servern startas den inte, och chatten fortsätter utan dess verktyg. Kommandot MCP: Reset Trust nollställer de separata besluten.

Konsekvensen för ett team: en ändring i .vscode/mcp.json som någon pushar kan starta en ny lokal process hos dig utan fråga, om du redan litar på repot. Granska därför diffar i filen som kod, och läs filen i ett repo du klonar innan du litar på arbetsytan. Dokumentationen ger samma råd.

Steg 5: stäng av skrivverktygen

Referensservern för filsystem har nio verktyg som läser och fyra som ändrar: create_directory, write_file, edit_file och move_file. Klicka på Configure Tools i chattens inmatningsfält, leta upp servern och avmarkera de fyra. Enligt VS Codes sida om agentverktyg styr markeringen vilka verktyg som är tillgängliga för förfrågan, och en förfrågan kan ha högst 128 verktyg aktiverade samtidigt.

Taket är ett skäl till, utöver säkerheten, att hålla listan kort. Men lägg inte hela skyddet i verktygslistan. Katalogargumentet från steg 3 är den gräns som servern själv upprätthåller, och README:n anger att en klient som stöder Roots kan ersätta serverns tillåtna kataloger. Kontrollera därför med list_allowed_directories vad servern faktiskt ser.

Steg 6: provet som visar att agenten inte kan skriva

Provet ska mäta en sak: kan agenten ändra filer via den här servern? Stäng därför under provet även av VS Codes inbyggda redigeringsverktyg i Configure Tools. Annars kan agenten skriva filen på annan väg, och då mäter du VS Code i stället för servern.

Kontrollera facit på disk, inte i agentens svar. En agent kan skriva att den skapat filen utan att ha gjort det, och tvärtom. Spara datum, VS Code-version, serverns version och resultatet i projektets anteckningar, och gör om provet när servern uppdateras eller mcp.json ändras.

Om något inte startar

Kör MCP: List Servers, välj servern och välj en åtgärd. Vid fel visar chatten en notis där Show Output öppnar serverns logg. Visar verktygslistan gamla verktyg efter en uppdatering finns MCP: Reset Cached Tools. På macOS och Linux kan lokala stdio-servrar köras i sandlåda, men då godkänns deras verktygsanrop automatiskt, och enligt dokumentationen finns sandlådan ännu inte på Windows.

Om din organisation styr MCP-servrar via Copilot-policyer gäller de utöver det du ställer in lokalt; se nyheten om Copilots standardpolicy.