Budowa czy zakup infrastruktury MCP: przewodnik decyzyjny dla zespołów SaaS
Porównanie lokalnego serwera MCP z platformą zarządzaną: rzeczywisty obciążenie, autoryzacja, stopnie kontroli, granice dopuszczalnych wartości, hybrydowa ścieżka oraz pięć pytań do rozstrzygnięcia najpierw.
Źródła: Build or Buy: How SaaS Teams Should Approach MCP Infrastructure
Dla firmy typu SaaS pierwsza decyzja dotycząca MCP zazwyczaj przychodzi w postaci pytania technicznego: czy zespół powinien napisać własny serwer MCP, czy wynająć zarządzaną platformę? Bardziej precyzyjne pytanie brzmi, które etapy cyklu życia MCP firma chce kontrolować.
Napisanie serwera we własnym zakresie daje zespołowi pełną kontrolę nad kodem, jego zachowaniem w czasie działania, miejscem implementacji oraz aspektami bezpieczeństwa. Stwarza to również stałe obowiązki: projektowanie narzędzi, obsługa autoryzacji, hostowanie, testowanie, monitorowanie, reagowanie na incydenty, śledzenie zmian w API oraz zarządzanie wersjami. Platforma zarządzana pozwala zrezygnować z części kontroli nad implementacją w zamian za szybsze uzyskanie dostępu do serwera hostowanego i mniejszą ilość infrastruktury do utrzymania.
Żadna z opcji nie jest domyślnie poprawna. Odpowiedź zależy od istniejącej API, możliwości, które mają zostać udostępnione, rodzaju punktu końcowego oczekiwanego przez klientów oraz od ilości czasu potrzebnego na prace inżynieryjne po zakończeniu wdrożenia.
Co faktycznie obejmuje ta decyzja
Server MCP to coś więcej niż zbiór funkcji obsługujących żądania. Jest to interfejs skierowany do sztucznej inteligencji, włączony do istniejącego produktu, a pełna decyzja może obejmować:
- przekształcanie operacji API w narzędzia, zasoby lub polecenia
- tworzenie nazw, opisów oraz schematów danych wejściowych
- przekierowywanie kluczy API, tokenów Bearer lub danych uwierzytelniających w czasie wykonywania aplikacji
- wdrażanie punktu końcowego, do którego mogą uzyskać dostęp klienci
- testowanie procesu wykrywania, wywoływania funkcji, obsługi błędnych danych wejściowych oraz mechanizmów uwierzytelniania
- zbieranie logów oraz informacji o sposobie używania produktu
- radzenie sobie z błędami oraz zmianami w API dostarczanym przez podmioty trzecie
Zespół, który ocenia koszty wyłącznie pod kątem utworzenia pierwszego serwera, może nie docenić trudności związanych z jego budową. Zespół, który bierze pod uwagę tylko wygodę usług zarządzanych, może przeoczyć kontrolę oraz prawa własności produktu, które przekazuje.
Budowa we własnym zakresie: pełna kontrola, trwała własność
Pisanie własnego serwera ma sens, gdy MCP staje się kluczowym elementem strategii platformy. Wtedy zespół decyduje o:
- sposobie implementacji każdej funkcji
- tym, czy narzędzie obejmuje jedną wywołanie API, czy koordynuje kilka kroków
- sposobie egzekwowania identyfikacji i uprawnień
- wyborze odpowiedniego transportu oraz ustawień hostingu
- sposobie prezentacji błędów klientom
- tym, co ma być rejestrowane, a co maskowane
- sposobie łączenia serwera z wewnętrznymi systemami implementacji i bezpieczeństwa
Taka kontrola się opłaca, gdy warstwa MCP musi wykonywać zadania, których nie może sprostać gotowa konwersja API na MCP. Pasuje również do organizacji, które już mają zespół ds. platformy zajmujący się wspólnymi środowiskami działania, możliwościami monitorowania, zgodnością z regulacjami oraz reagowaniem na incydenty.
Jednak odpowiedzialność za taki serwer trwa długo po pierwszej implementacji – serwer musi być utrzymywany tak długo, jak długo produkt się zmienia.
Prawdziwe obciążenie pracą wewnętrznego serwera
Inżynieria
Wczesne etapy pracy mogą obejmować wybór SDK MCP, mapowanie operacji API, definiowanie schematów narzędzi, przekładanie żądań oraz pisanie testów. Trudniejsze scenariusze wymagają dodatkowo tworzenia własnych mechanizmów orkiestracji, obsługi stanu, prób ponownych, paginacji oraz kształtowania odpowiedzi.
Zapotrzebowanie na zasoby rośnie wraz ze rozmiarem API, a także wtedy, gdy proces pracy z AI nie jest dobrze skoordynowany z pojedynczymi punktami końcowymi. Napisanie prostego otoczenia jest szybkie, natomiast dobrze zaprojektowana interfejs produktu może wymagać znacznie więcej czasu.
Hosting i wdrażanie
Serwer musi działać w miejscu, do którego mogą dotrzeć klienci MCP. Zespół wybiera środek transportu, konfiguruje zmienną środowiskowe i parametry wdrażania, organizuje sieć komunikacyjną, zajmuje się skalowaniem oraz interweniuje w przypadku przerwania połączeń lub wywołań do innych systemów. Ważny jest również proces wypuszczania nowych wersji. Serwer, który działa tylko na laptopie jednego inżyniera, jest prototypem, a nie niezawodną integracją.
Autoryzacja i obsługa danych
W trakcie działania poprawny klucz API, token Bearer lub dane uwierzytelniające OAuth muszą dotrzeć do podstawowej usługi API, a te sekrety wymagają ostrożnego obsługiwania, rotacji, określania zakresu dostępu oraz zdefiniowanego zachowania w przypadku błędów. Ktoś musi również zdecydować, które metadane żądań, wyniki i szczegóły błędów mają trafiać do dzienników, co wpływa zarówno na model bezpieczeństwa, jak i koszty eksploatacji.
Testowanie i obserwowalność
Zestaw testów musi sprawdzać możliwości łączenia się, wykrywania zasobów, schematy, poprawne i błędne dane wejściowe, odrzucenie autoryzacji, błędy po stronie źródła, przekroczenie czasu oczekiwania oraz sposób obsługi odpowiedzi. Po uruchomieniu powinno istnieć wystarczająco dużo danych telemetrycznych, aby móc odpowiedzieć na takie pytania:
- Które narzędzia są używane?
- Które operacje najczęściej zawodzą?
- Czy opóźnienia pochodzą od serwera MCP czy od samej usługi API?
- Czy klienci wysyłają błędnie sformatowane dane wejściowe?
- Czy nowa wersja API zmieniła zachowanie istniejącego narzędzia?
Lub zespół buduje to sam, lub łączy kilka istniejących systemów.
Konserwacja i wersjonowanie
Używana API będzie się zmieniać. Parametry ulegają modyfikacjom, niektóre operacje są uznawane za przestarzałe, zasady bezpieczeństwa stają się bardziej restrykcyjne, a schematy odpowiedzi mogą zyskiwać lub tracić pola – konfiguracja MCP musi podążać za tymi zmianami. Dojrzała implementacja wymaga przeglądu kodu, środowisk testowych, wersjonowanych dostaw, możliwości cofnięcia zmian oraz dbałości o dokładne opisy narzędzi.
Rozwój wewnętrzny daje kontrolę, ale ceną jest konieczność podejmowania decyzji dotyczących każdego z tych aspektów przez cały okres funkcjonowania integracji.
Platformy zarządzane: mniej infrastruktury do utrzymania
Platforma MCP zarządzana wychodzi z innej premisy. Firma oferująca usługi SaaS posiada już gotową API i chce, aby dostępne były tylko wybrane funkcje dla klientów MCP, bez potrzeby budowania pełnego warstwy operacyjnej. Zazwyczaj proces realizacji przechodzi przez następujące etapy:
- imporcie definicji API
- wykrywaniu dostępnych operacji
- wyborze funkcji do udostępnienia
- konfiguracji narzędzi, zasobów i poleceń
- hostowaniu punktu końcowego MCP
- testowaniu interfejsu
- monitorowaniu i wersjonowaniu konfiguracji
Płatforma nie przejmuje kontroli nad produktem SaaS. Logika biznesowa, uprawnienia użytkowników, granice tenantów, paginacja oraz limity szybkości pozostają przy oryginalnym API. Zmniejsza się natomiast ilość pracy związanej z infrastrukturą wokół interfejsu MCP.
Odpowiedzialności
- Mapowanie API. W środowisku wewnętrznym zespół pisze i utrzymuje warstwę tłumaczenia. W przypadku platformy importuje się definicję API i sprawdza wykryte operacje.
Zatem porównanie nie dotyczy kodu kontra braku kodu. Chodzi o infrastrukturę, którą posiada zespół, kontra infrastrukturę zarządzaną przez kogoś innego.
Jeden przykład zarządzanej ścieżki: 0mcp
0mcp to platforma skierowana do zespołów SaaS posiadających już definicję API, które chcą mieć hostowany serwer MCP bez konieczności zarządzania całym stackiem MCP. Jej proces pracy obejmuje:
- imporowanie obsługiwanej definicji Swagger lub OpenAPI, albo kolekcji Postman
- wykrywanie punktów końcowych i operacji
- wybieranie dostępnych funkcji API
- tworzenie lub modyfikowanie narzędzi, zasobów i poleceń
- przekształcanie nazw i opisów funkcji
- próbowanie serwera hostowanego
- przekazywanie klucza API, tokena Bearer lub danych uwierzytelniających OAuth do oryginalnego API
- zapisywanie wersji konfiguracji, przeglądanie zmian i przywracanie wcześniejszej wersji
Serwer generowany jest udostępniany przez Streamable HTTP, a sama usługa hostingu jest realizowana automatycznie. Obecnie nie są obsługiwane lokalne serwery MCP typu stdio. Rozwiązanie to lepiej pasuje do zespołów korzystających z zdalnego punktu końcowego hostowanego niż do tych, których główną potrzebą jest lokalny proces działający obok aplikacji desktopowej.
Jaką autoryzację platforma może, a jakiej nie może zastąpić
Platforma zarządzana nigdy nie powinna zastępować modelu autoryzacji wewnątrz API SaaS. API decyduje o tym, czy dane uprawnienia są ważne, do kogo należą (do którego użytkownika lub najemcy), jakie rekordy może odczytać oraz jakie działania może wykonać.
Z użyciem 0mcp dane uprawnienia trafiają przez klienta MCP i są przekazywane do oryginalnego API przy każdej prośbie, a platforma ich nie przechowuje. Zespół nadal musi prawidłowo skonfigurować mechanizm autoryzacji API, używać uprawnień o minimalnych prawaach oraz testować odrzucane żądania.
Kontrola występuje w różnym stopniu
Zwykłym zarzutem wobec platformy zarządzanej jest utrata kontroli. To zmartwienie jest uzasadnione, ale należy je sprecyzować. W przypadku samodzielnie zbudowanego serwera zespół kontroluje szczegóły implementacji. W przypadku takiej platformy kontroluje natomiast opcje dostępne dla użytkowników, które platforma umożliwia:
- kterze operacje API są dostępne
Nie kontroluje on arbitralnego kodu w czasie wykonywania wewnątrz platformy, a platforma nie zastępuje specjalistycznej logiki biznesowej. Przepływy pracy wymagające specjalistycznej orkiestracji, której nie obejmuje istniejąca API, lepiej jest opracować wewnętrznie.
Ta granica jest przydatna sama w sobie. Możliwości oparte na API mogą trafić do usługi zarządzanej, natomiast kod dostosowany jest przeznaczony wyłącznie dla tych części produktu, które rzeczywiście go potrzebują.
Przypadki sprzyjające tworzeniu własnego rozwiązania
Należy opracować rozwiązanie wewnętrznie, gdy zachodzą kilka z następujących warunków:
- MCP jest strategiczną możliwością, którą firma chce dogłębnie opanować.
- Narzędzia muszą działać w sposób wykraczający poza mapowanie istniejących operacji API.
- Wymagany jest lokalny
stdiolub mechanizm transportu, którego brakuje platformie. - Potrzebny jest specjalistyczny silnik wykonywania, lokalizacja w sieci wewnętrznej lub dostosowana obsługa danych.
- Istnieją już zasoby inżynieryjne, bezpieczeństwa i operacyjne niezbędne do jego utrzymania.
- Polityka firmy wymaga mechanizmów kontroli lub systemów implementacji, których platforma nie może zapewnić.
- Długoterminowa wartość dostosowanych mechanizmów kontroli przewyższa koszty utrzymania.
Budowa własnego rozwiązania nie czyni go automatycznie bezpieczniejszym ani bardziej niezawodnym. Pozwala to zespołowi zaprojektować takie właściwości, ale nadal muszą one być konsekwentnie wdrażane i obsługiwane.
Sytuacje sprzyjające użyciu platformy
Zarządzana platforma taka jak ta jest praktycznym rozwiązaniem wtedy, gdy:
- produkt już oferuje przydatne możliwości API
- zespół chce jak najszybciej mieć hostowany serwer MCP
- istniejący API powinien pozostać źródłem prawdy dotyczącym zasad biznesowych i uprawnień
- bardziej opłacalne jest skupienie się na określonej grupie operacji niż ręczne tworzenie każdego narzędzia
- wolą się autoryzację typu pass-through zamiast odrębnego systemu uwierzytelniającego
- potrzebne są usługi testowania, logowanie, analiza danych oraz zarządzanie wersjami
- nie jest konieczne posiadanie pełnej kontroli nad warstwą hostingu i infrastruktury
Jego przydatność spada, jeśli potrzebny jest lokalny serwer stdio, kod w formacie dowolnym uruchamiany na serwerze lub jakikolwiek inny transport niż Streamable HTTP. Zespoły z formalną infrastrukturą, wymogami dotyczącymi zgodności lub dostępności powinny również uważnie sprawdzić obecny zakres produktu, ponieważ 0mcp nie oferuje ani formalnego SLA, ani certyfikatu bezpieczeństwa. Wytyczanie takich granic jest częścią odpowiedzialnej decyzji. Platformę należy wybrać ze względu na zadania, które rzeczywiście może rozwiązać, a nie ze względu na umiejętności, których nigdy nie było twierdzone, że posiada.
Pięć pytań do zadania najpierw
Czy istniejąca API jest już odpowiednią interfejsem produktu? Jasne operacje, schematy, mechanizmy autoryzacji oraz przydatne odpowiedzi stanowią solidny punkt wyjścia dla procesu przenoszenia funkcji z API do MCP. Jeśli w API brakuje podstawowych działań biznesowych, zmiana warstwy MCP nie uzupełni tej luki produktowej.
Ile niestandardowej funkcjonalności wymaga proces pracy z AI? Gdy każda możliwość odpowiada dokładnie operacji API, platforma zmniejsza pracę związana z implementacją. Złożona orkiestracja, nowe reguły biznesowe lub agregacja danych, których brakuje w API, mogą wymagać niestandardowego rozwoju.
Kto będzie zarządzał punktem końcowym za sześć miesięcy? Wyznacz osobę odpowiedzialną za incydenty, dane uwierzytelniające, zmiany w API, jakość narzędzi, opóźnienia i procedury cofania zmian. Bez wyraźnego odpowiedzialnego kolejna usługa samodzielnie zarządzana może przynieść więcej ryzyka niż korzyści.
Jaki model wdrażania potrzebują klienci? Jeśli lokalne stdio jest niezbędne, należy je stworzyć wewnętrznie lub rozważyć inną platformę.
Czym powinno się tutaj kierować zarządzanie? Dzieli się ono na kilka warstw: zasady biznesowe, określenie, kto może widzieć jakie dane, wybór udostępnianych funkcji, infrastruktura podstawowa oraz dowolny kod dostosowany w czasie wykonywania. Zespół może zachować pierwsze trzy warstwy i przekazać pozostałe dwa.
Dozwolony jest model hybrydowy
Wybór nie musi być ostateczny ani oparty na zasadzie albo-tak-albo-nie. Firma SaaS może udostępniać proste funkcje oparte na API za pośrednictwem platformy, jednocześnie tworząc dostosowane usługi MCP dla procesów roboczych wymagających specjalistycznej logiki. Może dowiedzieć się, jakie narzędzia faktycznie chcą użytkownicy, zanim zainwestuje w większą platformę wewnętrzną, a także może pozostawić oryginalne API i jego mechanizmy autoryzacji nietknięte, testując nowe rozwiązania w obszarze skierowanym do sztucznej inteligencji.
Najważniejsza jest jasna struktura: lista zarządzanych możliwości, lista tych dostosowanych indywidualnie, określony właściciel dla każdego środowiska działania oraz uzgodniony sposób testowania zmian.
Prawdziwym pytaniem jest własność
Wybór między budową a zakupem infrastruktury MCP sprowadza się do kwestii własności. Tworzenie serwera od zera ma sens, gdy specyficzne zachowanie, ścisła kontrola nad wdrażaniem lub strategiczna własność platformy są warte nakładu pracy inżynierskiej i operacyjnej. Wybierz platformę zarządzaną wtedy, gdy istniejąca API już zawiera funkcje wartych udostępnienia, a zespół woli poświęcić energię na ich wdrożenie niż na utrzymywanie kolejnego poziomu infrastruktury.
Pozycje pokrewne
- Praktyczne notatki: Nowy MCP jest bezstanowy – wewnątrz protokołu 2026–07–28 — Szczegółowy przewodnik po praktycznych notatkach: Nowy MCP jest bezstanowy – wewnątrz protokołu 2026–07–28: umowy, sprawdzania oraz miejsca na kod do wykorzystania przez zespoły wdrażające ten wzorzec.
- Gdy agent AI ma 1000 narzędzi MCP: wybór, kontekst i umiejętności — Łączenie agentów z wieloma serwerami MCP powoduje eksplodację liczby narzędzi, przeciążony kontekst oraz nieodpowiednie wybory. Dlaczego funkcje odkrywania, umiejętności i bramy mogą być ważniejsze niż prosty dostęp.