Wer MCP-Server in Visual Studio Code und GitHub Copilot nutzen will, sollte für beide Ziele getrennte Konfigurationsformate einplanen: VS Code verwendet eine Datei mit dem Schlüssel servers, das portable Format für Copilot eine Datei mit mcpServers. Eine gemeinsame Quelle kann die Serverdefinitionen bündeln; die Dateien für die einzelnen Clients müssen trotzdem zu deren Format passen. Microsofts MCP-Konfigurationsreferenz beschreibt die Pfade und Unterschiede.
Ein MCP-Server stellt KI-Clients Werkzeuge und weitere Funktionen bereit. Welche Konfiguration du brauchst, hängt davon ab, ob du VS Code, den Copilot-Harness oder beide verwendest.
Welche MCP-Datei zu VS Code und Copilot gehört
| Format | Datei im Arbeitsbereich | Benutzerdatei | Oberster Schlüssel | Variablenreferenz |
| VS Code | .vscode/mcp.json | mcp.json im VS-Code-Benutzerprofil | servers | ${env:NAME}; außerdem sind Eingabevariablen möglich |
| Portables Copilot-Format | .mcp.json | $COPILOT_HOME/mcp-config.json, ersatzweise ~/.copilot/mcp-config.json | mcpServers | ${NAME} oder ${NAME:-default} |
Der Copilot-Harness liest das portable Format direkt. VS Code kann geeignete Server aus seiner eigenen Konfiguration weiterreichen, aber keine Server, die interaktive ${input:...}-Werte benötigen. Auch die Variablenschreibweise ist wichtig: VS Code behandelt ein bloßes $NAME als wörtlichen Text.
Was beim portablen Format verloren gehen kann
Das portable Format übernimmt nicht alle Funktionen des VS-Code-Formats. Microsoft nennt Eingabeaufforderungen, envFile, den Entwicklungsmodus und Sandbox-Einstellungen pro Server als nicht unterstützte Funktionen. Wenn deine VS-Code-Konfiguration davon Gebrauch macht, bildet eine portable Datei sie nicht vollständig ab.
Prüfe deshalb vor der Umstellung, welche dieser Funktionen deine Server tatsächlich verwenden. Für eine gemeinsame Serverliste kann ein Generator getrennte Ausgabedateien erzeugen; er kann jedoch keine Funktion in ein Format übertragen, das sie nicht unterstützt.
Konfiguration und Serverbetrieb getrennt prüfen
- Lege fest, welche Clients die Konfiguration nutzen sollen. Entscheide außerdem, ob die Einstellungen für ein Projekt oder für dein Benutzerprofil gelten sollen.
- Erzeuge für jedes Ziel das passende Format. Verwende für VS Code und Copilot die jeweils dokumentierten Schlüssel und Variablenformen aus der Tabelle.
- Prüfe die erzeugten Dateien. Ein Struktur-Audit kann etwa JSON-Syntax, Schlüssel, Variablenformen und Unterschiede zwischen Serverlisten kontrollieren. Sofia Lindström beschrieb am 2. November 2026 einen Generator-Workflow mit solchen Prüfungen und einem CI-Driftcheck. Sie berichtete außerdem, den Ablauf unter Linux ausgeführt zu haben.
- Teste den Server im vorgesehenen Client. Eine formal gültige Datei belegt für sich genommen nicht, dass ein Server startet, sich authentifiziert, eine Verbindung herstellt oder die erwarteten Werkzeuge bereitstellt. Lindström empfahl zusätzlich MCP Inspector und einen repräsentativen Werkzeugaufruf im jeweiligen Client.
Cursor in verwalteten Arbeitsbereichen bereitstellen
Für Teams, die Cursor in verwalteten Entwicklungsumgebungen zentral einrichten, beschreibt Coder einen eigenen Bereitstellungsweg: Ein Modul nimmt MCP-JSON entgegen und schreibt es beim Start des Arbeitsbereichs nach ~/.cursor/mcp.json. Coder ordnet die Verwaltung dieser Konfiguration versionierten Terraform-Vorlagen zu. Das ist ein Ansatz für verwaltete Cursor-Arbeitsbereiche, nicht der Generator für die VS-Code- und Copilot-Formate.
