Zdalny serwer MCP w akcji: nowy punkt wejścia dla produktów SaaS w erze AI

Produkty SaaS mają jeden odwieczny problem: czas do uzyskania wartości jest zbyt długi. Wielu użytkowników rezygnuje, zanim osiągną moment "aha".

Wielokrotnie iterowaliśmy proces onboardingu Logto. Pomogło to, ale wąskie gardło nie zniknęło. Nadal kończysz czytając dokumentację, przeglądając samouczki, instalując SDK, konfigurując ustawienia, pisząc kod, a potem debugując ostatnie 10%, zanim wszystko zadziała.

Spróbowaliśmy więc innego podejścia: zdalny serwer MCP jako natywna płaszczyzna kontrolna Logto w IDE. Zamiast klikać po konsoli administratora, konfigurujesz Logto i generujesz kod integracyjny podczas rozmowy, dokładnie tam, gdzie budujesz aplikację.

Jedna podpowiedź może przeprowadzić cię od zera do działającej integracji. Agent nie tylko generuje kod, ale także tworzy i konfiguruje aplikację Logto w twoim tenantcie. Wszystko z poziomu twojego IDE. (Wypróbuj Logto MCP Server)

W tym artykule podzielę się naszym doświadczeniem oraz przemyśleniami dotyczącymi budowy serwera Logto MCP, w tym:

• MCP vs. Agent Skills: dlaczego wybraliśmy MCP
• Problemy, które napotkaliśmy podczas wdrażania serwera MCP, i jak je rozwiązaliśmy
• Jak projektujemy narzędzia MCP i jak ty powinieneś projektować swoje
• Nasze oczekiwania wobec przyszłości MCP

MCP vs. Agent Skills: dlaczego wybraliśmy MCP#

Zanim zdecydowaliśmy, jak AI ma uzyskiwać dostęp do Logto, rozważyliśmy dwie opcje: serwery MCP i Agent Skills.

Serwery MCP występują w dwóch formach: lokalnej i zdalnej.

Lokalny serwer MCP działa na komputerze użytkownika. Wymaga instalacji usługi, konfiguracji środowiska, poświadczeń albo specjalnych procesów logowania. Pod względem użytkowania i wdrożenia jest bardzo podobny do skills.

Zdalny serwer MCP jest hostowany po stronie serwera. Użytkownicy łączą się przez URL i autoryzują za pomocą OAuth. Ten model jest bliższy rozszerzaniu usług SaaS.

Z perspektywy struktury, Agent Skill to połączenie "logiki biznesowej + podstawowych możliwości". Te możliwości mogą być narzędziami, CLI albo wywołaniami API. Narzędzia MCP mogą przenosić tę warstwę w jednolity sposób.

Kluczowym pytaniem nie jest więc to, jak możliwości są zaimplementowane, ale jak są dostarczane użytkownikom.

• Agent Skills dostarczają: pełny lokalny toolchain (pakiet Skill + lokalne środowisko uruchomieniowe + klucze API lub poświadczenia platformowe + narzędzia CLI + instalacja, konfiguracja, aktualizacja i utrzymanie).
  W istocie dajesz użytkownikom możliwość uruchamiania wszystkiego samodzielnie.

• Zdalne serwery MCP dają: zdalne wejście do usługi (URL + login OAuth).
  W istocie przekazujesz możliwość jako usługę.

Poniżej porównujemy je pod kątem doświadczenia użytkownika, zasięgu ekosystemu oraz kosztów dostarczenia i utrzymania.

Doświadczenie użytkownika#

Agent Skills zazwyczaj zależą od API platformy lub CLI. Użytkownicy muszą najpierw utworzyć klucze API lub zainstalować i zalogować się do CLI. Te kroki nie są trudne, ale podwyższają próg wejścia.

Serwery MCP obsługują OAuth. Użytkownicy logują się swoim kontem SaaS. Doświadczenie jest jak podczas "Zaloguj się przez Google".

Dla użytkowników korzystanie z serwera MCP jest proste: wpisz URL, zaloguj się, połącz. To jest doświadczenie, które chcemy zapewnić.

Zasięg ekosystemu#

Na stronie MCP jest już 104 aplikacji AI obsługujących MCP, w tym narzędzia jak VS Code, Cursor i Windsurf.

Agent Skills nadal są specyficzne dla platform. Nawet jeśli wiele platform zacznie je obsługiwać, gdy wypuścimy serwer MCP, użytkownicy mogą z niego korzystać od razu. Gdy udostępniamy Skill, tylko użytkownicy danej platformy mogą go używać.

MCP jest również częścią Agentic AI Foundation (AAIF). To standard na poziomie protokołu. Ekosystem będzie nadal rósł. Dla nas to czyni MCP wartym długoterminowej inwestycji.

Koszt dostarczenia i utrzymania#

Agent Skills zależą od API platformy lub CLI, co szybko rodzi problemy:

• Co, jeśli API się zmieni?
• Co, jeśli CLI utraci kompatybilność?
• Jak aktualizować i dystrybuować Skill?

Musisz też dystrybuować CLI, zarządzać rozproszonymi poświadczeniami, dostosowywać się do wielu platform i prowadzić użytkowników przez proces aktualizacji. Zwrot z inwestycji jest bardzo niski.

Serwery MCP są dużo prostsze. Użytkownicy łączą się przez URL. Zawsze wskazuje on na najnowszą wersję. Gdy aktualizujemy serwer MCP, użytkownicy korzystają z niego przy kolejnym połączeniu. Bez potrzeby aktualizacji lokalnej. Jeśli API się zmieni, aktualizujemy je po stronie serwera MCP.

Większość produktów SaaS ma już mocną infrastrukturę: solidne API i dojrzałe systemy uwierzytelnienia. Serwer MCP naturalnie pasuje jako "interfejs AI" dla API, tak jak konsola administratora jest innym interfejsem na tych samych API.

Dla Logto wybór serwera MCP jest zgodny z naszą architekturą i wykorzystuje nasze mocne strony.

Centralizuje on także wszystkie żądania w jednym punkcie wejścia. Logi i audyty są łatwiejsze. Uprawnienia są jasne: AI może zrobić tylko to, na co użytkownik wyraził zgodę. Ten model jest strukturalnie czystszy w scenariuszach korporacyjnych i zgodności.

Problemy, które napotkaliśmy podczas wdrażania serwera MCP i jak je rozwiązaliśmy#

MCP nie jest idealny. Większość problemów wynika z niedojrzałości ekosystemu. Z czasem sytuacja się poprawi. Do tego czasu stosujemy obejścia, by zaspokoić realne potrzeby.

Fragmentacja obsługi funkcji MCP#

Specyfikacja MCP definiuje wiele funkcji, ale ich wsparcie po stronie klientów jest różne:

• Narzędzia: szeroko obsługiwane
• OAuth: dobrze obsługiwane w VS Code; narzędzia jak Cursor wymagają mcp-remote jako mostka
• Inne funkcje (Zasoby, Podpowiedzi, Instrukcje): wsparcie nierówne

Obecnie narzędzia są najbardziej niezawodną warstwą wspólną (sprawdź stronę społeczności MCP, by zobaczyć, co obsługuje każdy klient).

Nasza strategia jest więc prosta: buduj na narzędziach.

LLM nie wie, jak używać twoich narzędzi#

To problem warstwy biznesowej.

W Agent Skills logika biznesowa i kontekst są pakowane razem. LLM wie, jak je używać. MCP udostępnia tylko narzędzia. Po połączeniu LLM nie wie:

• Scenariuszy użycia
• Kolejności wywołań
• Ograniczeń biznesowych

MCP ma pojęcie Instrukcji, ale nie wszystkie klienty je obsługują. Instrukcje także ładują całą treść do kontekstu podczas połączenia, co marnuje tokeny.

Inny pomysł to umieszczenie wskazówek w opisach narzędzi. Ale to powoduje dwa problemy:

• Opisy stają się skomplikowane. Kilkuetapowe procesy mieszają logiki i są trudne do utrzymania.
• Rosnąca liczba narzędzi powoduje, że opisy zużywają istotną część okna kontekstu.

Nasze obejście: dostarcz narzędzie getInstructions

Idea jest prosta: jeśli Instrukcje nie są dobrze obsługiwane, zamień je w narzędzia.

LLM może wywoływać getInstructions na żądanie.
Dla zadania A, wywołuje getTaskAInstructions. Serwer MCP zwraca podpowiedź, jak wykonać zadanie A oraz jak łączyć inne narzędzia.

Złożona logika biznesowa zostaje ukryta za narzędziami instrukcyjnymi. Pozostałe narzędzia są proste. Ich opisy skupiają się wyłącznie na własnej funkcji.

To podobne do Agent Skills: podpowiedzi ładowane są na żądanie. Jest to też efektywniejsze niż globalne Instrukcje, bo nie zalewamy całego kontekstu.

LLM może ujawnić twoje sekrety#

Dla wielu produktów SaaS pewne sekrety nigdy nie powinny być ujawnione (np. client secrets, klucze API czy klucze podpisujące webhooki). Jeśli wyciekną, ktoś może się podszyć pod ciebie albo uzyskać bezpośredni dostęp do zasobów.

Ryzyko z LLM-ami polega na tym, że czat nie jest bezpiecznym kanałem. Rozmowy mogą być logowane, kopiowane, przekazywane czy nawet trafiać do logów debugowania. Nie możesz zakładać, że "tylko ty i model to widzicie". Dlatego przekazanie LLM-owi długowiecznych sekretów albo proszenie go o ich wyświetlenie użytkownikowi jest bardzo ryzykowne.

To powszechne ryzyko w klasycznych integracjach webowych: programiści często potrzebują sekretu, umieszczają go w zmiennych środowiskowych lub plikach konfiguracyjnych i kończą proces inicjowania SDK.

Aby zachować łatwość onboardingu bez osłabiania bezpieczeństwa sekretów, stosujemy trzy rzeczy:

• Korzystaj z tymczasowych sekretów podczas integracji

  Podczas konfiguracji przez czat serwer MCP zwraca tylko krótkotrwałe sekrety tymczasowe (np. ważne 1 godzinę). Wystarczą, by uruchomić integrację, a zanim przejdziesz na produkcję - często już wygasają. Przed uruchomieniem produkcyjnym programiści tworzą nowe, długowieczne sekrety poza czatem.

• Wyraźnie zaznacz granicę bezpieczeństwa

  Wyraźnie ostrzegamy użytkowników: nie twórz, nie wklejaj ani nie przechowuj produkcyjnych sekretów w czacie. Przypominamy też programistom, że nawet zmienne środowiskowe czy pliki konfiguracyjne mogą wyciec, jeśli agent/LLM uzyska do nich dostęp przez narzędzia lub pośrednio. Sekrety produkcyjne przechowuj tylko tam, gdzie nie korzysta się z integracji AI.

• Nie obsługuj sekretów produkcyjnych na czacie; skieruj użytkownika do konsoli

  Długotrwałe sekrety nie są generowane ani dystrybuowane przez czat. Tworzy się je i zarządza nimi w konsoli na stronie poświadczeń. Na czacie dajemy tylko bezpośredni link do konsoli, by użytkownik mógł dokończyć konfigurację sekretu produkcyjnego tam.

Jak projektujemy narzędzia MCP#

Nasza droga#

Logto posiada kompletne Management API. Naszym pierwszym pomysłem było: wystawić każde endpoint API jako narzędzie MCP.

Szybko się nie powiodło.

Po pierwsze, eksplozja kontekstu. Logto posiada wiele API. Mapowanie ich 1:1 zapełnia okno kontekstu. Każdy opis narzędzia kosztuje tokeny.

Po drugie, utrata sensu. API to atomowe klocki dla programistów. Ale użytkownicy serwera Logto MCP nie budują systemów. Oni po prostu chcą wykonać zadanie. Ilość API ich nie obchodzi.

Przykład: Logto posiada API sign-in-experience do zarządzania brandingiem, metodami logowania, rejestracji i politykami bezpieczeństwa.
Na początku myśleliśmy, jak wystawić wszystkie parametry do LLM. Jak go nauczyć łączenia wywołań.

Ale to błędne podejście. Użytkownicy nie wywołują API. Oni chcą zmienić branding lub skonfigurować metody logowania.

Narzędzia powinny więc być: updateBranding, updateSignInMethod, updateSignUpMethod. Serwer MCP zajmuje się kompozycją API wewnętrznie.

Serwer Logto MCP należy traktować jak produkt, a nie prostą nakładkę na API. To "kolejna konsola administratora".

Jak projektować narzędzia MCP#

Zasada staje się jasna:

• Jeśli użytkownicy korzystają z twojej usługi bezpośrednio (jak konsoli), narzędzia powinny być skupione na zadaniach biznesowych.
• Jeśli dajesz podstawowe możliwości na których ktoś inny buduje, narzędzia powinny być atomowe i proste. Przykład: serwer MCP do systemu plików z read_file, write_file, wtedy agenci łączą je według potrzeb.

Dodatkowe zasady:

• Utrzymuj logikę i opisy narzędzi proste, aby oszczędzać kontekst.
• Do złożonych workflow używaj narzędzi getInstructions, by ładować instrukcje na żądanie. Ich opisy także trzymaj proste.

Nasze oczekiwania wobec przyszłości MCP#

Tworząc serwer MCP zastanawialiśmy się również, co można poprawić w ekosystemie.

Dostarczanie zdolności na poziomie Skill#

Czasem serwery MCP muszą zapewnić nie tylko narzędzia, ale też instrukcje, jak je łączyć w zadania - jak Agent Skills.

To częste w SaaS. Przykład: GitHub MCP Server, Logto MCP Server lub platformy analityczne. Użytkownicy oczekują workflow, a nie pojedynczych wywołań.

getInstructions to obejście. Lepsze byłoby wsparcie na poziomie protokołu.

Włączanie MCP na poziomie sesji#

Klienty łączą się z wieloma serwerami MCP, ale nie każda sesja potrzebuje ich wszystkich. Opcja włączania/wyłączania MCP na poziomie sesji zmniejszyłaby zużycie kontekstu.

Izolacja kontekstu dla wywołań narzędzi MCP#

Wywołania narzędzi MCP pochłaniają dużo kontekstu. Jeśli interakcje MCP odbywają się przez sub-agenty, główna rozmowa mogłaby otrzymywać jedynie podsumowane wyniki.

Podsumowanie#

To nasze doświadczenia związane z budową zdalnego serwera MCP.

Jeśli rozważasz taki kierunek, wypróbuj Logto MCP Server lub dołącz do naszego Discorda, by wymienić się doświadczeniami wdrożeniowymi z społecznością.

W przyszłości podzielimy się także szczegółami architektury oraz procesu OAuth.