MCP 2026-07-28 bez sesji: jak skalować serwer?

MCP 2026-07-28 usuwa sesje na poziomie protokołu i pozwala kierować niezależne żądania do dowolnej instancji serwera za zwykłym load balancerem round-robin. Odpada potrzeba utrzymywania wspólnego magazynu sesji MCP. Stan aplikacji nadal może istnieć, lecz autorzy protokołu zalecają przekazywanie jawnego uchwytu między wywołaniami narzędzi. Taką zmianę opisuje oficjalny komunikat wydania.

Dla architektury firmowej integracji widzę tu konkretne zadanie: oddzielić kontekst żądania od danych procesu biznesowego. Zanim usunę przywiązanie klienta do jednej repliki, sprawdziłbym, skąd kolejna replika odtworzy stan operacji i jak rozpozna jej powtórzenie.

Źródła sprawdziłem 5 października 2026 r. Specyfikację ogłoszono 28 lipca, a wpis Google Cloud z 14 września potwierdza obsługę tej wersji przez serwery MCP Google i Google Cloud oraz zgodność tych zmian z wersją 2025-11-25. To odrębne daty publikacji specyfikacji i komunikatu producenta. Wydanie MCP, release notes Google Cloud.

W skrócie

• Polecam traktować każdą replikę jako zdolną do obsługi samodzielnego żądania.
• Stan wieloetapowej operacji zaprojektowałbym jawnie, z właścicielem, identyfikatorem i czasem ważności.
• Migrację uznałbym za zakończoną dopiero po testach zmiany repliki, ponowień i starszych klientów.

Temat jest aktualny także w kalendarzu społeczności: organizator wyznaczył MCP Dev Summit Toronto na 5–6 października 2026 r. Strona wydarzenia.

Co dokładnie znika z sesji MCP?

Nowa specyfikacja usuwa wymianę initialize / notifications/initialized oraz nagłówek Mcp-Session-Id. Dodaje server/discover, który serwer musi implementować, ale klient może wywołać opcjonalnie przed innymi żądaniami. Nie trzeba więc zaczynać każdej integracji od odkrywania możliwości serwera. Lista zmian specyfikacji.

Każde żądanie musi zawierać w _meta pola io.modelcontextprotocol/protocolVersion i io.modelcontextprotocol/clientCapabilities. Pole io.modelcontextprotocol/clientInfo jest zalecane, a nie obowiązkowe. Serwer nie może polegać na kontekście ustanowionym przez wcześniejsze żądanie na tym samym połączeniu. Rdzeń protokołu.

Nie utożsamiam jednak starszego MCP z obowiązkową sesją HTTP. Dokumentacja SDK C# wyjaśnia, że w poprzednich wersjach użycie Mcp-Session-Id było wyborem serwera; klient musiał odsyłać identyfikator, jeśli go otrzymał. Nowa wersja usuwa sam ten mechanizm. Dokumentacja trybów SDK C#.

Co zmienia się w load balancerze?

Autorzy wydania wskazują, że każde samodzielne żądanie może trafić do dowolnej instancji za load balancerem round-robin bez współdzielonego magazynu sesji. Komunikat MCP.

Na tej podstawie rekomenduję replikom wspólny kontrakt narzędzi i zgodną konfigurację. Sticky sessions, czyli kierowanie kolejnych żądań klienta do tej samej repliki, usunąłbym dopiero po sprawdzeniu zależności aplikacyjnych. Dla hipotetycznego narzędzia przygotowującego eksport zaprojektowałbym osobno żądanie uruchomienia pracy oraz identyfikator pozwalający odczytać jej stan z innej repliki.

Routing po nagłówkach

W Streamable HTTP nagłówek Mcp-Method jest wymagany dla wszystkich żądań. Mcp-Name jest wymagany dla tools/call, resources/read i prompts/get; odpowiada nazwie narzędzia, nazwie promptu albo URI zasobu. Pośrednicy mogą dzięki temu kierować ruch bez parsowania treści JSON. Specyfikacja Streamable HTTP.

Każdy POST musi też zawierać MCP-Protocol-Version, zgodny z wersją w _meta. Serwer przetwarzający treść musi odrzucać niezgodność wymaganych nagłówków z odpowiadającymi im wartościami w treści żądania. Wymagania nagłówków i walidacji.

Polecam przetestować tę zgodność przez rzeczywistą bramę API. Dodałbym przypadek, w którym nagłówek wskazuje inne narzędzie niż JSON, oraz kontrolę przekazywania wymaganych nagłówków przez proxy.

Gdzie umieścić stan aplikacji?

Specyfikacja wymaga, aby stan obejmujący wiele żądań, na przykład zadanie lub uchwyt aplikacyjny, był wskazywany jawnym identyfikatorem przekazywanym przez klienta w każdym odpowiednim żądaniu. Zasady bezstanowości.

W projekcie integracji rozdzieliłbym odpowiedzialności następująco:

To moja propozycja architektury, nie narzucony przez MCP wybór bazy danych. Dla uchwytów ustaliłbym zasady własności, wygaśnięcia i odwołania. Osobno zaprojektowałbym kontrolę dostępu do wskazanego obiektu.

Nie używałbym clientInfo jako dowodu tożsamości użytkownika. Specyfikacja określa te dane jako deklarowane przez nadawcę i niezweryfikowane przez protokół; zaleca, aby nie opierać na nich decyzji bezpieczeństwa. Znaczenie danych identyfikujących klienta.

MRTR: jak poprosić użytkownika o dane bez sesji?

Multi Round-Trip Requests, czyli MRTR, zastępuje wcześniejsze żądania inicjowane przez serwer. Gdy operacja potrzebuje dodatkowych danych, przepływ wygląda następująco. Specyfikacja MRTR.

1. Klient wysyła pierwotne żądanie.
2. Serwer zwraca resultType: "input_required" z żądaniami danych w inputRequests oraz opcjonalnym requestState.
3. Klient zbiera odpowiedzi i ponawia pierwotne żądanie z inputResponses, nowym identyfikatorem JSON-RPC oraz dokładnie tym samym requestState, jeśli go otrzymał.
4. Serwer, mając wystarczające dane, zwraca wynik końcowy.

Każda próba jest niezależna; replika obsługująca ponowienie nie potrzebuje informacji poza zawartością ponowionego żądania. Przepływ i wymagania klienta.

requestState trzeba traktować jako dane kontrolowane przez potencjalnego atakującego. Jeśli wpływa na autoryzację, dostęp do zasobów lub logikę biznesową, serwer musi chronić jego integralność, na przykład przez HMAC lub AEAD, i odrzucać niepoprawny stan. Jeżeli stan wolno wykorzystać tylko raz, serwer musi sam egzekwować tę zasadę. Wymagania bezpieczeństwa MRTR.

W integracji zatwierdzającej zmianę danych powiązałbym kontynuację z konkretną operacją i użytkownikiem. Zapis wykonałbym dopiero po sprawdzeniu odpowiedzi oraz stanu kontynuacji.

Bez sesji nadal można mieć strumień

Streamable HTTP nadal pozwala odpowiedzieć na żądanie obiektem JSON albo strumieniem SSE ograniczonym do tego żądania. Dokumentacja transportu.

Powiadomienia o zmianach można odbierać przez subscriptions/listen, którego odpowiedź jest długotrwałym strumieniem. Stan takiego strumienia należy do żądania; po utracie kanału klient wysyła je ponownie. Wzorce komunikacji.

Nowa wersja usuwa wznawianie SSE przez Last-Event-ID. Zerwanie strumienia odpowiedzi oznacza utratę trwającego żądania; klient musi wysłać nowe, z nowym identyfikatorem. Lista zmian transportu.

Dlatego operacje zapisujące dane projektowałbym z ochroną przed powtórzeniem skutku biznesowego. W teście odłączyłbym klienta po zapisie, przed odebraniem odpowiedzi, a następnie sprawdził ponowienie.

Jak zaplanowałbym migrację serwera?

Najpierw sprawdziłbym rzeczywiście używany protokół. Dokumentacja TypeScript SDK v2 zaznacza, że obsługa nowej wersji wymaga jawnego wyboru; ręcznie utworzone instancje Client, Server lub McpServer domyślnie zachowują protokół starszej generacji. Sam numer głównej wersji pakietu nie wystarcza. Przewodnik migracji TypeScript.

Następnie wykonałbym trzy testy architektury:

1. Zmiana repliki: skierowałbym kolejne etapy tej samej operacji do różnych instancji, bez sticky sessions.
2. Utrata odpowiedzi: sprawdziłbym ponowienie odczytu i zapisu oraz zachowanie po przerwaniu strumienia.
3. Zgodność klientów: sprawdziłbym osobno nową wersję i używane przez odbiorców starsze wersje.

Dla zespołu korzystającego z C# rozważyłbym udokumentowany tryb HttpServerSessionMode.StatefulForInitializeClients. Pozwala obsługiwać na jednym endpoincie starszych klientów z sesjami i klientów nowej wersji bez sesji. Tryb hybrydowy SDK C#.

Przy takim wdrożeniu utrzymałbym obsługę sesji dla starszego ruchu, dopóki testy i obserwacja klientów nie uzasadnią jej usunięcia. Za kryterium gotowości przyjąłbym możliwość obsłużenia kolejnego żądania na dowolnej replice, poprawną kontrolę dostępu do uchwytów oraz przewidywalne zachowanie po ponowieniu.