Rejestr MCP, katalog serwerów narzędzi

Rejestr MCP, czyli skąd agent bierze narzędzia

Protokół opisujący sposób podłączania narzędzi i źródeł danych do modeli językowych rozszedł się na tyle szeroko, że pojawił się problem wtórny: skąd wiadomo, jakie serwery istnieją i który z nich jest tym właściwym.

Oficjalny rejestr odpowiada na to pytanie. Jest katalogiem opisów serwerów, prowadzonym przez zespół stojący za samym protokołem, dostępnym publicznie i przez interfejs programistyczny. Ruszył jesienią 2025 roku i od tego czasu urósł do ponad dwudziestu tysięcy pozycji.

Zanim przejdziemy dalej, jedno rozróżnienie, bo bez niego cały tekst wprowadzałby w błąd. Rejestr przechowuje opisy, a nie kod, i nie prowadzi przeglądu bezpieczeństwa. To rozwinę w osobnej sekcji, bo jest to najważniejsza rzecz do zrozumienia.

Nazwy odwrócone i weryfikacja

Mechanizm nazewnictwa jest tu najlepiej przemyślaną częścią i rozwiązuje problem, który przy katalogach pakietów bywa źródłem poważnych nadużyć.

Nazwa serwera ma postać odwróconej domeny, wskazującej na osobę albo organizację publikującą. Przed opublikowaniem czegokolwiek pod daną nazwą musisz udowodnić, że masz do niej prawo.

Dowód wygląda różnie zależnie od rodzaju nazwy. Nazwa wskazująca na konto w serwisie z repozytoriami wymaga zalogowania się tym kontem. Nazwa wskazująca na domenę wymaga dodania wpisu w konfiguracji tej domeny, co potrafi zrobić wyłącznie osoba nią zarządzająca.

Skutek jest konkretny. Nikt nie opublikuje serwera pod nazwą sugerującą znaną firmę, jeśli nie kontroluje jej domeny. To odcina najprostszą drogę podszywania się, znaną z katalogów pakietów, gdzie nazwa łudząco podobna do popularnej biblioteki bywa skutecznym atakiem.

Warto natomiast rozumieć zakres tej gwarancji. Weryfikacja mówi, że publikujący kontroluje daną nazwę, i nie mówi nic o tym, co ten serwer robi. To dwie różne rzeczy i ich pomylenie jest najczęstszym błędem przy korzystaniu z takich katalogów.

Publikowanie własnego serwera

Proces jest krótszy, niż sugeruje liczba pojęć, i sprowadza się do czterech kroków.

Zaczynasz od pliku opisu, w którym podajesz nazwę zgodną z weryfikowaną domeną albo kontem, opis, sposób uruchomienia i wymagane ustawienia.

Code

JSON

{
  "name": "com.mojafirma/serwer-zamowien",
  "description": "Dostep do systemu zamowien: odczyt statusu i historii.",
  "version": "1.0.0",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@mojafirma/mcp-zamowienia",
      "version": "1.0.0",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

Drugi krok to znacznik potwierdzający, że pakiet w katalogu pakietów należy do Ciebie. Bez niego ktoś mógłby wskazać w opisie cudzy pakiet i przejąć w ten sposób zaufanie związane z Twoją nazwą.

Trzeci to zalogowanie narzędziem wiersza poleceń, przy czym sposób logowania zależy od rodzaju nazwy. Czwarty to samo opublikowanie i sprawdzenie wyniku przez interfejs rejestru.

Code

Bash

mcp-publisher login dns --domain mojafirma.com --private-key "$KLUCZ_PRYWATNY"
mcp-publisher publish

Dwie rzeczy warto przemyśleć przed publikacją. Pierwsza to opis: on trafia do klientów i to na jego podstawie model albo człowiek decyduje, czy sięgnąć po ten serwer. Zdanie mówiące wprost, do czego służy i czego nie robi, jest wart więcej niż lista funkcji.

Druga to wersjonowanie. Rejestr przechowuje kolejne wersje, więc zmiana zachowania serwera bez podniesienia numeru sprawia, że użytkownicy dostają coś innego niż to, co sprawdzili przy podłączaniu.

Czego rejestr nie zapewnia

To jest sekcja najważniejsza w całym tekście i rzecz, którą materiały o protokole mówią rzadziej, niż powinny.

Rejestr przechowuje opisy serwerów, nie ich kod. Instalując serwer, pobierasz go z katalogu pakietów albo obrazu kontenera wskazanego w opisie, a rejestr jedynie mówi, gdzie on jest.

Nie ma tu przeglądu bezpieczeństwa. Nikt nie czyta kodu przed dopuszczeniem pozycji do katalogu, więc obecność w rejestrze nie znaczy, że serwer jest bezpieczny, dobrze napisany ani że robi to, co obiecuje w opisie.

Konsekwencja jest poważniejsza niż przy zwykłej bibliotece. Serwer tej klasy dostaje dostęp do narzędzi, danych i często kluczy, a model wywołuje go samodzielnie, bez Twojego potwierdzenia przy każdej operacji. Złośliwy albo po prostu wadliwy serwer ma więc szerokie pole działania.

Trzy nawyki ograniczają to ryzyko i warto przyjąć je od początku. Pierwszy to sprawdzenie źródła: kto publikuje, czy kod jest dostępny publicznie i czy repozytorium wygląda na utrzymywane. Drugi to ograniczenie uprawnień: serwer potrzebujący dostępu do jednego systemu nie powinien dostawać klucza obejmującego wszystkie. Trzeci to zatwierdzanie operacji zmieniających stan, zamiast pozwalania modelowi na wykonywanie ich samodzielnie.

Osobno warto pamiętać o treściach wracających z serwera. Opis narzędzia i wynik jego wywołania trafiają do kontekstu modelu, więc serwer może wpłynąć na to, co model zrobi dalej. To jest wektor, którego przy zwykłej bibliotece nie ma.

Rozwińmy to, bo różnica jest zasadnicza. Zwykła biblioteka wykonuje kod, który jej zleciłeś, i tyle. Serwer tej klasy zwraca tekst trafiający wprost do rozumowania modelu, a model traktuje ten tekst jako informację, a nie jako dane do zignorowania. Wynik wywołania zawierający zdanie sformułowane jak polecenie potrafi więc wpłynąć na kolejne kroki, łącznie z wywołaniem innego narzędzia.

Dotyczy to również serwerów napisanych w dobrej wierze, jeśli pobierają treści z zewnątrz. Serwer odczytujący zgłoszenia od klientów albo strony internetowe przekazuje do modelu treść, nad którą nikt nie panuje, więc traktowanie wszystkiego, co wraca z narzędzia, jako danych, a nie instrukcji, jest zasadą wartą przyjęcia niezależnie od zaufania do samego serwera.

Podrejestry i katalogi firmowe

Rejestr został pomyślany jako warstwa podstawowa, na której budują inni, i to rozwiązanie warto znać przy wdrożeniu firmowym.

Podrejestr pobiera dane z rejestru głównego i dokłada własne reguły. Może odsiać pozycje niespełniające przyjętych kryteriów, przeprowadzić skanowanie pakietów albo dopuścić wyłącznie serwery zatwierdzone przez zespół bezpieczeństwa.

Dla organizacji to jest właściwa droga. Zamiast pozwalać każdemu podłączać dowolny serwer z publicznego katalogu, utrzymujesz własną listę dopuszczonych pozycji, a użytkownicy widzą wyłącznie ją.

Podobną rolę pełnią katalogi prowadzone przez dostawców narzędzi i platform. Bywają wygodniejsze w użyciu i węższe, bo zawierają pozycje sprawdzone albo zbudowane przez danego dostawcę.

Warto rozumieć relację między nimi. Rejestr główny jest źródłem danych, a pozostałe katalogi są nakładkami o różnych regułach. To znaczy, że ta sama pozycja może wyglądać inaczej w każdym z nich, a brak pozycji w katalogu firmowym nie oznacza, że nie istnieje.

Jak wybierać serwer z katalogu

Skoro katalog liczy dziesiątki tysięcy pozycji, a żadna nie przeszła przeglądu, wybór wymaga własnej metody. Pięć rzeczy do sprawdzenia w kilka minut.

Pierwsza to publikujący. Nazwa wskazuje na weryfikowaną domenę albo konto, więc od razu widać, czy serwer pochodzi od twórcy danej usługi, czy od osoby trzeciej. To nie przesądza jakości, natomiast serwer do systemu zgłoszeń opublikowany przez producenta tego systemu jest inną propozycją niż ten sam serwer od nieznanego konta. Pochodzenie od producenta nie oznacza jednak większych możliwości: oficjalny serwer do Dysku Google jest we wczesnej wersji dla programistów, czyta pliki i tworzy nowe, ale nie zaktualizuje istniejącego dokumentu, nie przeniesie pliku i nie zmieni uprawnień.

Druga to dostępność kodu. Zdecydowana większość pozycji ma publiczne repozytorium i warto do niego zajrzeć, choćby po to, żeby zobaczyć, ile plików obejmuje i kiedy ostatnio coś się w nim zmieniło.

Trzecia to zakres uprawnień, jakich serwer żąda. Opis wymienia potrzebne ustawienia, więc serwer proszący o klucz z pełnym dostępem do konta, żeby odczytać listę zadań, jest sygnałem ostrzegawczym niezależnie od tego, kto go opublikował.

Czwarta to lista udostępnianych narzędzi. Serwer wystawiający trzy operacje odczytu jest łatwy do ocenienia, a serwer z czterdziestoma operacjami, w tym usuwaniem i wysyłką, wymaga znacznie więcej uwagi przed podłączeniem. Sama liczba nie przesądza jednak sprawy, bo część serwerów pozwala ją przyciąć: serwer GitHuba ma kilkadziesiąt narzędzi, ale domyślnie włącza pięć zestawów i pozwala zejść niżej jedną zmienną środowiskową. Sprawdzaj więc nie tylko, ile narzędzi serwer ma, ale ile z nich włącza bez pytania.

Piąta to aktualność. Protokół zmieniał się wyraźnie w ostatnich dwóch latach, więc serwer bez żadnych zmian od roku może działać poprawnie albo nie obsługiwać rzeczy, których dziś oczekujesz.

Przy serwerach dotykających danych firmowych warto dołożyć krok szósty: uruchomienie w izolacji i sprawdzenie, dokąd faktycznie wysyła ruch. To dziesięć minut pracy, które odpowiada na pytanie, na które opis nie odpowiada wcale.

Rejestr a klienci

Sam katalog niewiele daje, dopóki nie umie z niego korzystać narzędzie, którego używasz na co dzień, więc warto rozumieć, jak wygląda ta warstwa.

Część klientów odpytuje rejestr bezpośrednio i pozwala dodać serwer z poziomu interfejsu, bez ręcznego wpisywania konfiguracji. Część korzysta z własnych katalogów, zbudowanych na tych samych danych i uzupełnionych o pozycje sprawdzone przez dostawcę.

W obu przypadkach efektem końcowym jest wpis w konfiguracji Twojego narzędzia, mówiący, jak uruchomić serwer i jakie ustawienia mu przekazać. Katalog skraca drogę do tego wpisu, a nie zastępuje go.

Warto wiedzieć, gdzie ten wpis leży i co zawiera, bo to tam trafiają klucze i ścieżki. Przy pracy zespołowej ten plik bywa współdzielony przez repozytorium, więc sekrety powinny być podawane przez zmienne środowiskowe, a nie wpisywane wprost.

Przy narzędziach takich jak Cursor czy asystenci pracujący z kodem konfiguracja bywa dwupoziomowa: osobna dla całego komputera i osobna dla projektu. Ta druga jest zwykle właściwym miejscem dla serwerów związanych z konkretnym repozytorium, bo znika razem z nim i nie wisi w tle przy pracy nad czymś innym.

Rejestr kontra alternatywy

Rozwiązanie	Mocna strona	Słabość	Kiedy wybrać
Rejestr oficjalny	Weryfikacja nazw, pełny zakres, interfejs programistyczny	Brak przeglądu bezpieczeństwa	Szukanie serwera i publikowanie własnego
Podrejestr firmowy	Własne reguły dopuszczania, skanowanie	Ktoś musi go utrzymywać	Organizacja z wymogami bezpieczeństwa
Katalog dostawcy	Pozycje sprawdzone, wygodna instalacja	Węższy zakres, powiązanie z jednym narzędziem	Praca w ekosystemie tego dostawcy
Własny serwer	Pełna kontrola nad tym, co robi	Piszesz i utrzymujesz sam	Dostęp do systemu wewnętrznego

Ostatni wiersz bywa pomijany przy takich decyzjach, a przy systemach firmowych jest zwykle właściwą odpowiedzią. Serwer udostępniający Twoją bazę zamówień i tak trzeba napisać samemu, bo nikt inny nie zna jej struktury ani reguł, a narzędzia do tego są opisane w tekstach o zestawie narzędzi protokołu oraz o FastMCP.

Typowe błędy

Pierwszy to traktowanie obecności w rejestrze jako potwierdzenia bezpieczeństwa. Rejestr przechowuje opisy i weryfikuje nazwy, nie prowadzi przeglądu kodu.

Drugi to podłączanie serwera z kluczem obejmującym więcej systemów, niż on potrzebuje. Uprawnienia warto zawęzić do jednego zastosowania.

Trzeci to pozwalanie modelowi na samodzielne wykonywanie operacji zmieniających stan. Wysyłka wiadomości albo modyfikacja danych powinna wymagać potwierdzenia.

Czwarty to publikowanie bez znacznika potwierdzającego własność pakietu. Bez niego opis może wskazywać cudzy pakiet, a zaufanie do Twojej nazwy zostaje wykorzystane przez kogoś innego.

Piąty to zmiana zachowania serwera bez podniesienia wersji. Użytkownicy dostają wtedy coś innego niż to, co sprawdzili przy podłączaniu.

Szósty to opis wyliczający funkcje zamiast mówiący wprost, kiedy z serwera korzystać. Model wybiera narzędzia wyłącznie po opisie, więc to on decyduje o trafności wywołań bardziej niż sama jakość kodu.

FAQ

Czy obecność w rejestrze oznacza, że serwer jest bezpieczny?

Nie. Rejestr przechowuje opisy serwerów i weryfikuje prawo do nazwy, a nie prowadzi przeglądu kodu. Weryfikacja mówi, że publikujący kontroluje daną domenę albo konto, i nic ponadto.

Jak działa weryfikacja nazw?

Nazwa ma postać odwróconej domeny wskazującej na publikującego. Nazwa oparta na koncie w serwisie z repozytoriami wymaga zalogowania się tym kontem, a nazwa oparta na domenie wymaga dodania wpisu w jej konfiguracji, co potrafi zrobić wyłącznie osoba nią zarządzająca.

Co trzeba zrobić, żeby opublikować serwer?

Przygotować plik opisu z nazwą, opisem i sposobem uruchomienia, dodać znacznik potwierdzający własność pakietu, zalogować się narzędziem wiersza poleceń sposobem odpowiadającym rodzajowi nazwy i opublikować. Całość zajmuje kwadrans przy gotowym serwerze.

Czym jest podrejestr?

Katalogiem budowanym na danych z rejestru głównego, z własnymi regułami dopuszczania pozycji. Organizacja może w ten sposób udostępnić użytkownikom wyłącznie serwery zatwierdzone przez zespół bezpieczeństwa, zamiast pozwalać na podłączanie dowolnych.

Czy warto napisać własny serwer zamiast szukać gotowego?

Przy dostępie do systemu wewnętrznego zwykle tak, bo nikt inny nie zna jego struktury. Przy popularnych integracjach gotowy serwer oszczędza pracę, o ile sprawdzisz źródło i ograniczysz uprawnienia.

Rejestr znajdziesz pod oficjalnym adresem, a jego opis na stronie protokołu.