Artykuł · MCP w firmie

MCP gateway i rejestr serwerów: budować czy kupić

Rejestr serwerów MCP mówi, co wolno podłączyć, a gateway pokazuje, co się dzieje. Zacznij od polityki w klientach. Gateway kup dla logów i poświadczeń ponad klientami, a własny buduj rzadko.

Dla: Architekci, zespoły platformowe, szefowie IT · Stan na 02.11.2026 · Autor: Karol Krawczyk

Czym różni się rejestr MCP od gatewaya?

Rejestr MCP odpowiada na pytanie, co wolno podłączyć: to katalog zatwierdzonych serwerów z metadanymi, wersją i sposobem instalacji. Gateway (brama pośrednicząca w ruchu) odpowiada na pytanie, co się właśnie dzieje: stoi między klientem a serwerem, uwierzytelnia, ogranicza i loguje wywołania. Część produktów łączy jedno i drugie, na przykład IBM ContextForge, przez co zakup może wyglądać na jedną decyzję. Da się jednak mieć rejestr bez gatewaya, a gateway bez rejestru obsłuży tylko tyle, ile ktoś w nim ręcznie skonfiguruje.

Żaden z nich nie jest też egzekwowaniem polityki na komputerze pracownika. Serwer stdio startuje jako lokalny podproces i nie przechodzi przez sieciową bramę. Na poziomie MCP zablokować go może klient, ustawieniami narzuconymi przez administratora.

Czy wystarczy oficjalny rejestr MCP, czy firma potrzebuje własnego?

Oficjalny MCP Registry jest w preview i uprzedza o możliwych zmianach łamiących zgodność i resetach danych. Przechowuje wyłącznie metadane publicznych serwerów, nie przyjmuje prywatnych, nie daje gwarancji dostępności ani trwałości danych, a skanowanie bezpieczeństwa zostawia rejestrom pakietów i agregatorom. Regulamin moderacji mówi wprost, że serwerów z lukami się nie usuwa. Weryfikacja przestrzeni nazw potwierdza właściciela nazwy, o bezpieczeństwie kodu nic nie mówi. Hosty nie powinny korzystać z niego bezpośrednio, a jego kod nie jest przeznaczony do samodzielnego hostowania.

Firmowy rejestr powinien więc wdrażać publiczną specyfikację OpenAPI rejestru, bo tego interfejsu oczekują hosty. Azure API Center udostępnia punkt końcowy /v0.1/servers i obsługuje serwery zdalne oraz lokalne pakiety. Docker ma własny mechanizm: katalogi tworzone poleceniem docker mcp catalog i trzymane w rejestrach OCI. Claude Code wbudowanego rejestru nie ma: dokumentacja radzi publikować listę zatwierdzonych serwerów na wiki albo rozdawać je jako wtyczki.

Ostrożnie z rejestrem jako zaporą. GitHub podaje, że polityka Registry only w Copilocie opiera się na dopasowaniu nazwy serwera, którą można obejść edycją pliku konfiguracyjnego, a sama funkcja jest w public preview i nie jest zalecaną metodą. Do twardego ograniczenia GitHub odsyła do managed-settings.json z listą dozwolonych adresów i poleceń. Identyczny wniosek płynie z dokumentacji Claude Code: wpis po nazwie serwera nie jest zabezpieczeniem, bo nazwę nadaje użytkownik.

Co daje MCP gateway?

Rewizja MCP 2026-07-28 ułatwiła pracę gatewayom: klient ma powielać metodę i nazwę narzędzia w nagłówkach Mcp-Method i Mcp-Name, więc brama może routować i mierzyć ruch bez parsowania treści, a brak sesji upraszcza równoważenie obciążenia. Polityka oparta wyłącznie na nagłówkach ma jednak warunek: jeśli wersja protokołu jest starsza albo jej nie ma, pośrednik powinien odrzucić żądanie, bo starsze wersje nie wymagają zgodności nagłówków z treścią.

Propozycja tego tekstu: brama ma wartość w trzech sytuacjach: gdy wiele różnych klientów ma wspólną politykę, gdy potrzebny jest log per wywołanie narzędzia z tożsamością użytkownika i gdy poświadczenia do systemów docelowych mają leżeć centralnie, a nie na laptopach. DX Heroes, które samo oferuje gateway, oceniało 9 kwietnia 2026, że żaden dostawca nie domyka całości.

Brama pośrednicząca podlega tym samym regułom co inne serwery. Nie może przekazywać dalej tokenu otrzymanego od klienta: specyfikacja wymaga osobnego tokenu do API docelowego. Serwer proxy ze statycznym client ID musi ponadto pytać użytkownika o zgodę dla każdego dynamicznie rejestrowanego klienta.

Logowanie w bramie też ma pułapki. Microsoft ostrzega, że odczyt treści odpowiedzi w polityce API Management uruchamia buforowanie i może zepsuć działanie serwera MCP, a logowanie treści odpowiedzi na poziomie wszystkich API trzeba wyłączyć. W tym produkcie zapisanie wyników narzędzi wymaga więc osobnego przemyślenia, dlatego wymaganie audytowe sprawdź na testowym wdrożeniu przed zakupem.

MCP gatewaye do kupienia i z open source

MCP gateway można kupić u dostawcy chmury albo wziąć z open source, a dobór zależy głównie od tego, w jakiej chmurze firma już pracuje. Poniższe opcje sprawdzono w dokumentacji, nie obejmują całego rynku i nie są rankingiem.

  • Azure API Management: wystawia REST API jako serwer MCP albo pośredniczy w istniejącym, od poziomu Basic i Developer po Premium v2. Wymaga serwera zgodnego co najmniej z wersją 2025-06-18. Wsparcie jest niepełne: bez promptów, a strona przeglądowa i instrukcja różnią się co do zasobów.
  • Amazon Bedrock AgentCore Gateway: łączy cele w jeden wirtualny serwer, z semantycznym wyszukiwaniem narzędzi. Cennik na 2 listopada 2026: 0,005 USD za tysiąc wywołań, 0,025 USD za tysiąc wyszukiwań, 0,02 USD za 100 indeksowanych narzędzi miesięcznie.
  • Docker MCP Gateway: licencja MIT, serwery w izolowanych kontenerach, dobre dla lokalnych serwerów programistów. Repozytorium wymienia w wymaganiach Docker Desktop 4.59 lub nowszy z włączonym MCP Toolkit.
  • agentgateway: Apache 2.0, projekt przy Linux Foundation, RBAC z silnikiem polityk CEL i integracja OpenAPI. Repozytorium opisuje go jako projekt w aktywnym rozwoju.
  • IBM ContextForge: Apache 2.0, rejestr i proxy w jednym, federacja przez Redis. Przykłady w repozytorium używają obrazu 1.0.0-RC-3, więc przed wdrożeniem trzeba ustalić status wydania i warunki wsparcia.

Dlaczego budowa własnego MCP gatewaya rzadko się broni

Własny MCP gateway rzadko się opłaca, choć przy cennikach chmurowych samo przetwarzanie jest tanie. Według cennika AWS z 2 listopada 2026 milion wywołań w AgentCore Gateway to 5 USD, a indeks 500 narzędzi to 0,10 USD miesięcznie, do czego dochodzi transfer danych. Główny koszt to ludzie i nadążanie za specyfikacją. To wniosek tego tekstu, nie wynik badania kosztów. Wymagania dla proxy OAuth z dokumentu o dobrych praktykach obejmują między innymi zgodę per klient, dokładne dopasowanie redirect URI, jednorazowy parametr state i ochronę ciasteczek. Oficjalny poradnik autoryzacji odradza samodzielne pisanie walidacji tokenów. Do tego rewizja może wywrócić obsługę transportu, co pokazało usunięcie sesji w 2026.

Własny kod ma sens wokół produktu: repozytorium zatwierdzonych serwerów, przegląd w pull requeście, generowanie allowlisty dla klientów, eksport logów do SIEM. To zwykła inżynieria platformowa, mniej zależna od kolejnych rewizji protokołu. Pełną bramę buduj tylko wtedy, gdy produkty nie mogą spełnić konkretnego, zapisanego wymogu, na przykład separacji sieciowej.

Od czego zacząć i kiedy nie kupować MCP gatewaya

Propozycja tego tekstu, nie wynik badania: przy dwóch czy trzech zdalnych serwerach MCP dostawców z własnym OAuth i jednym kliencie wystarczy polityka w kliencie, bez gatewaya. Claude Code oferuje managed-mcp.json z wyłączną kontrolą oraz listy allowedMcpServers z allowManagedMcpServersOnly, a Copilot podobne klucze w managed-settings.json. Nie wymaga osobnego zakupu i działa także dla stdio, ale tylko w kliencie, który to wspiera, więc przed decyzją sprawdź resztę narzędzi w firmie.

Bramę rozważ, gdy agenci działają na serwerach bez nadzoru człowieka, gdy wielu klientów dzieli te same systemy albo gdy audyt wymaga logu wywołań, którego klient nie dostarcza. Przed podpisaniem umowy zapytaj o obsługiwane rewizje MCP, plan przejścia na 2026-07-28 i sposób przekazywania tożsamości użytkownika do systemu docelowego. Brama z jednym kontem technicznym zaciera w logach systemu docelowego, kto co zrobił.

Co zrobić w firmie

  1. Zapisz, które pytanie jest pilne: co wolno podłączyć, co się dzieje, czy gdzie leżą poświadczenia
  2. Wdróż allowlistę po adresach i poleceniach w klientach, które to wspierają
  3. Prowadź listę zatwierdzonych serwerów w repozytorium z przeglądem przez pull request
  4. Sprawdź, czy obecna chmura ma gateway spełniający zapisane wymagania
  5. Pytaj dostawców o rewizje MCP i przekazywanie tożsamości użytkownika do systemu docelowego

Chcesz przełożyć to na swój zespół?

Szkolimy zespoły z pracy z Copilotem, Claude Code i Codexem na ich własnych zadaniach.

Więcej: MCP w firmie

← Wszystkie artykuły