- Zdalny serwer dodasz poleceniem claude mcp add z transportem http i adresem.
- Zasięg lokalny jest prywatny, projektowy trafia do .mcp.json w repozytorium, a użytkownika działa w każdym projekcie.
- Przed podłączeniem oceń autora, kod, uprawnienia i zakres danych.
Skoro wiesz już, czym jest MCP, czas na praktykę: jak podłączyć pierwszy serwer do Claude Code i jak nie narobić sobie kłopotów. Kroki są proste, ale kilka decyzji, zwłaszcza o zasięgu konfiguracji i zaufaniu, zostaje po stronie człowieka. Podstawą tego tekstu jest dokumentacja MCP w Claude Code.
Dodanie zdalnego serwera
Dokumentacja nazywa serwery HTTP zalecaną opcją dla usług zdalnych, bo ten transport jest najszerzej wspierany w chmurze. Składnia jest taka: claude mcp add --transport http <nazwa> <adres>. Jeśli serwer wymaga nagłówka z tokenem, dodajesz go parametrem --header. W plikach JSON typ streamable-http jest akceptowany jako alias http, bo tak nazywa ten transport specyfikacja MCP; wpis z adresem, ale bez typu, jest traktowany jako serwer lokalny i zostanie pominięty z komunikatem o błędzie.
Serwer lokalny (uruchamiany jako proces na twoim komputerze) dodajesz z transportem stdio, podając polecenie startowe. Starsze serwery bywają jeszcze udostępniane przez SSE, ale dokumentacja traktuje HTTP jako rozwiązanie preferowane. Po dodaniu użyj polecenia /mcp w sesji, żeby zobaczyć stan serwera i w razie potrzeby przejść uwierzytelnianie.
Trzy zasięgi konfiguracji
Najważniejsza decyzja to zasięg, bo od niego zależy, kto dostanie serwer i gdzie leżą ewentualne sekrety.
| Lokalny | Projektowy | Użytkownika | |
|---|---|---|---|
| Gdzie działa | Tylko w tym projekcie | W projekcie, dla zespołu | We wszystkich twoich projektach |
| Kto widzi | Tylko ty | Cały zespół przez repozytorium | Tylko ty |
| Plik | ~/.claude.json | .mcp.json w katalogu głównym | ~/.claude.json |
| Kiedy wybrać | Eksperymenty i dane z hasłami | Wspólne narzędzia zespołu | Twoje stałe narzędzia osobiste |
Zasięg lokalny jest domyślny. Warto zapamiętać pułapkę nazewniczą: „lokalny” w MCP oznacza wpis w ~/.claude.json, a nie plik .claude/settings.local.json, którego używają zwykłe ustawienia. Zasięg projektowy tworzy plik .mcp.json, który powinien trafić do kontroli wersji, żeby zespół miał te same narzędzia. W sesji interaktywnej Claude Code prosi o zatwierdzenie takich serwerów, a wcześniejsze decyzje można wyzerować poleceniem claude mcp reset-project-choices. W trybach, w których nie ma kogo zapytać, serwery projektowe ładują się bez pytania, więc cudzy .mcp.json czytaj, zanim uruchomisz agenta w skopiowanym repozytorium.
Pięć pytań przed zaufaniem serwerowi
Specyfikacja MCP wskazuje wśród zasad bezpieczeństwa zgodę użytkownika, ochronę prywatności danych i ostrożność wobec wywoływania narzędzi. Przełóż to na pytania, które zadajesz przed podłączeniem.
- Kto jest autorem i czy kod jest otwarty? Serwer bez znanego autora i bez kodu to czarna skrzynka z dostępem do twoich danych.
- Co dokładnie potrafi? Przeczytaj listę narzędzi: czy są tylko do odczytu, czy też zapisują, kasują lub wysyłają?
- Jakie uprawnienia dostaje? Jeśli serwer prosi o token, nadaj najmniejszy możliwy zakres i osobne konto zamiast głównego.
- Dokąd trafiają dane? Serwer zdalny widzi to, co mu wyślesz; przeczytaj politykę prywatności usługi.
- Co się stanie, gdy zawiedzie? Narzędzia o skutkach nieodwracalnych zostaw z wymaganym potwierdzeniem.
W uprawnieniach Claude Code możesz dla narzędzi MCP ustawić reguły zakazu lub pytania, tak samo jak dla wbudowanych. To sensowny domyślny wybór: zezwalaj tylko na odczyt, a zapis zostaw z pytaniem. Szerszy kontekst takiego podejścia opisuję w hubie Człowiek w pętli.
Typowe problemy i jak je diagnozować
Gdy serwer się nie pojawia, zacznij od /mcp i sprawdź jego status. Najczęstsze przyczyny są proste: wpis w pliku JSON ma adres, ale nie ma pola typu, serwer wymaga uwierzytelnienia, którego jeszcze nie przeszedłeś, albo został dodany w innym zasięgu, niż zakładasz, i dlatego nie widać go w bieżącym projekcie. Jeśli ten sam serwer jest zdefiniowany w kilku miejscach, Claude Code łączy się z nim raz i bierze definicję z źródła o najwyższym pierwszeństwie, bez scalania pól między zasięgami. Dokumentacja opisuje też rozwijanie zmiennych środowiskowych w .mcp.json, dzięki czemu tokeny nie muszą leżeć w pliku wprost, tylko w środowisku każdego członka zespołu.
Pamiętaj też, że uwierzytelnianie zdalnych serwerów często odbywa się przez przeglądarkę i zapisuje token po twojej stronie. Wylogowanie z usługi, zmiana hasła albo wygaśnięcie tokenu sprawi, że serwer przestanie działać, choć konfiguracja się nie zmieniła; wtedy wystarczy przejść uwierzytelnienie ponownie. Nie wklejaj tokenów do czatu ani do plików, które trafiają do repozytorium. Jeżeli token jednak wyciekł, odwołaj go w panelu usługi od razu, zanim zaczniesz szukać przyczyny, a dopiero potem wygeneruj nowy z mniejszym zakresem uprawnień. Przy serwerach używanych przez cały zespół ustal, kto je aktualizuje i kto przegląda zmiany w pliku konfiguracji, tak jak przy każdej innej zależności projektu. Dobrze jest też zapisać w CLAUDE.md krótką informację, które serwery są w projekcie wymagane i do czego służą.
Dobrą praktyką jest też krótki test po podłączeniu: poproś o operację tylko do odczytu, sprawdź, co faktycznie zostało wywołane, i dopiero potem pozwól na więcej.
Gdzie szukać serwerów
Punktem wyjścia jest oficjalne repozytorium modelcontextprotocol/servers z przykładami referencyjnymi oraz rejestr MCP. Wpis w rejestrze mówi, że serwer istnieje, a nie że jest bezpieczny, więc pięć pytań powyżej obowiązuje zawsze. Dobrą praktyką jest dodawanie serwerów pojedynczo i sprawdzanie po każdym, czy faktycznie rozwiązał problem, dla którego go dodałeś, zamiast zbierania ich „na zapas”. Każdy serwer powiększa kontekst modelu o opisy swoich narzędzi i zwiększa powierzchnię ryzyka.
Stan wiedzy: 20 października 2026. Polecenia i nazwy plików mogą się zmienić; potwierdź je w dokumentacji z listy źródeł.