Jeśli chcesz współdzielić konfigurację MCP między VS Code a GitHub Copilot, przygotuj osobny plik dla każdego formatu: VS Code używa klucza servers, a konfiguracja przenośna Copilota — mcpServers. Ta różnica ma znaczenie także przy generowaniu plików ze wspólnego źródła, bo format przenośny nie obsługuje kilku funkcji dostępnych w konfiguracji VS Code.
MCP, czyli Model Context Protocol, pozwala klientom AI korzystać z narzędzi i innych możliwości udostępnianych przez serwery. Poniższe kroki pomogą zespołom dobrać formaty, wykryć funkcje, które nie przeniosą się do pliku przenośnego, i osobno sprawdzić konfigurację oraz działanie serwera.
Zacznij od wyboru formatów
Microsoft opisuje dwa odrębne formaty. VS Code korzysta z własnej konfiguracji, a harness GitHub Copilot, czyli środowisko uruchamiające sesje agentów, bezpośrednio odczytuje format przenośny. Szczegóły ścieżek, kluczy i obsługi zmiennych opisuje dokumentacja Microsoft.
| Format | Plik workspace’u | Plik użytkownika | Główny klucz JSON | Zmienne środowiskowe | Istotne ograniczenie |
| VS Code | .vscode/mcp.json | mcp.json w profilu użytkownika VS Code | servers | ${env:NAZWA} | Serwery wymagające interaktywnego ${input:...} nie są przekazywane do Copilota |
| Przenośny format Copilot | .mcp.json w katalogu głównym workspace’u | $COPILOT_HOME/mcp-config.json; domyślnie ~/.copilot/mcp-config.json | mcpServers | ${NAZWA} lub ${NAZWA:-wartość_dom yślna} | Nie obsługuje monitów wejściowych, envFile, trybu deweloperskiego ani ustawień sandboxa dla poszczególnych serwerów |
Wartości takie jak NAZWA i wartość_dom yślna w tabeli są opisowymi przykładami składni, a nie nazwami wymaganymi przez program. W plikach przenośnych VS Code traktuje zapis $NAZWA bez nawiasów jako zwykły tekst, a nie odwołanie do zmiennej środowiskowej.
Sprawdź, co stracisz przy przejściu na format przenośny
Przed migracją porównaj ustawienia serwerów z możliwościami pliku docelowego. Microsoft wymienia cztery funkcje formatu VS Code, których pliki przenośne nie obsługują: monity o dane wejściowe, envFile, tryb deweloperski oraz ustawienia sandboxa dla poszczególnych serwerów. Jeśli konfiguracja zespołu korzysta z którejś z nich, sam plik przenośny nie odtworzy jej w całości.
Jest też różnica w sposobie uruchamiania konfiguracji. Sesje harnessu Copilot czytają plik przenośny bezpośrednio. VS Code może przekazywać kwalifikujące się serwery z własnego formatu, ale pomija te, które wymagają interaktywnej wartości ${input:...}. Dlatego serwer widoczny w jednej sesji nie musi być dostępny w drugiej.
Oddziel generowanie plików od testu serwera
Wspólne źródło konfiguracji może służyć do wygenerowania osobnych plików dla różnych klientów, zamiast kopiowania jednego pliku między formatami. Sofia Lindström z Tech Insider opisała taki generator, który tworzy pliki dla Cursor, VS Code i formatu przenośnego Copilota. Jej artykuł z 2 listopada 2026 roku relacjonuje także uruchomienie generatora i kontroli w Linuksie.
Według opisu tej implementacji audyt sprawdza składnię JSON, główne klucze, zapis zmiennych, wartości przypominające sekrety oraz zgodność list serwerów. To kontrole plików, nie łączności. Poprawny JSON nie dowodzi, że serwer się uruchamia, uwierzytelnia, łączy z usługą ani udostępnia oczekiwane narzędzia.
Przy wdrażaniu wspólnego źródła przejdź przez cztery kontrole:
- Wybierz format dla każdego klienta. Zapisz osobno, które pliki mają trafić do VS Code, a które do sesji Copilota. Dzięki temu nie pomylisz kluczy
serversimcpServers. - Porównaj używane funkcje z możliwościami formatu przenośnego. Sprawdź monity wejściowe,
envFile, tryb deweloperski i ustawienia sandboxa, zanim zdecydujesz o migracji. - Uruchom kontrolę struktury i zgodności plików. Walidacja JSON i porównanie list serwerów mogą ujawnić błędy w wygenerowanych plikach, ale nie zastępują próby połączenia.
- Przetestuj serwer w docelowym kliencie. Lindström zalecała osobne użycie MCP Inspector i wykonanie przykładowego wywołania narzędzia w każdym kliencie. Taka próba sprawdza działanie, którego audyt strukturalny nie obejmuje.
Dokładny schemat konfiguracji Cursor nie jest tu częścią instrukcji. Generator opisany przez Lindström obejmował Cursor, ale szczegółów jego składni nie należy przenosić na inne formaty.
Zarządzane workspace’y Cursor mogą korzystać z osobnej metody
Coder opisuje własny moduł dla zarządzanych środowisk Cursor: przy starcie workspace’u skrypt zapisuje przekazany JSON MCP do ~/.cursor/mcp.json, a organizacja może trzymać ustawienia w wersjonowanych szablonach Terraform. To firmowy sposób provisioningu konfiguracji Cursor, odrębny od generatora wspólnych plików dla VS Code i Copilot.
