Specyfikacja MCP z lipca 2026 roku usuwa wszelkie formy stanu sesji z warstwy protokołu, wymuszając, aby cały stan znajdował się w oknie kontekstowym modelu. Ta zmiana pozwala każdemu serwerowi MCP odpowiadać na dowolne żądanie, co otwiera drogę do wdrożeń całkowicie bezstanowych (stateless) za load balancerami, funkcjami serverless oraz autoskalowalnymi podami Kubernetes.

Dlaczego ta zmiana jest istotna

Od swojej pierwszej wersji MCP (Model Communication Protocol) utrzymywał lekki proces nawiązywania sesji (handshake) oraz nagłówek Mcp-Session-Id, aby śledzić stan konwersacji w wielu wywołaniach HTTP. Taka konstrukcja pozwalała serwerowi pamiętać, które uchwyty narzędzi (tool handles), częstotliwość próbkowania czy preferencje logowania należały do danego klienta. Oferowała również strumienie Server-Sent Events (SSE) z możliwością wznawiania, dzięki czemu przerwane połączenie mogło zostać kontynuowane od momentu przerwania.

Specyfikacja z 28 lipca 2026 r. całkowicie eliminuje proces nawiązywania sesji. Każde żądanie zawiera teraz wersję protokołu i możliwości klienta w polu _meta, a nagłówek Mcp-Session-Id znika. Pola Roots, sampling i logging zostały oznaczone jako przestarzałe (deprecated). Krótko mówiąc, protokół przesyłania danych (wire protocol) to teraz czysty model żądanie-odpowiedź; nie ma już „sesji”, którą trzeba by utrzymywać.

Co programiści muszą robić inaczej

Stan nie jest już domeną serwera; znajduje się on w oknie kontekstowym modelu. Gdy model musi odnieść się do zewnętrznego zasobu, musi otrzymać od serwera jawny uchwyt (handle) jako część wyniku narzędzia. Następne żądanie zawiera ten uchwyt jako argument, a model traktuje go jak każdy inny token.

Ponieważ okno kontekstowe jest buforem tokenów o stałym rozmiarze, każdy uchwyt zajmuje miejsce, które konkuruje z promptami użytkownika lub wyjściem modelu.

Zmienia się również kwestia niezawodności. Bez możliwości wznawiania SSE lub ponownego przesyłania wiadomości, przerwany strumień powoduje całkowitą utratę żądania. Klienci muszą uruchomić wywołanie od nowa. W przypadku szybkich, bezstanowych zapytań jest to akceptowalne; jednak przy długotrwałym pobieraniu danych lub wieloetapowych zadaniach agentów, zmusza to programistów do budowy własnej logiki ponawiania prób (retry logic) lub dzielenia zadań na mniejsze części.

Pilot Protocol wypełnia lukę

Bezstanowość MCP jest zamierzona, ale pozostawia warstwę sieciową bez tożsamości na poziomie połączenia oraz gwarancji niezawodności. Pilot Protocol, działający pod MCP, wypełnia tę lukę. Pilot ustanawia tożsamość raz i używa szyfrowania, aby powiązać pakiety z nadawcą. Z punktu widzenia MCP klient po prostu za każdym razem wysyła nowe żądanie HTTP; Pilot utrzymuje stabilność transportu bazowego.

Oba protokoły uzupełniają się: MCP pozostaje lekki, tani w przeliczeniu na żądanie i łatwy do skalowania za dowolnym punktem końcowym HTTP, podczas gdy Pilot zajmuje się ciężką pracą, którą wcześniej zapewniały tradycyjne protokoły oparte na sesjach.

Korzyści przy dużej skali

  • Przyjazny dla load balancerów – nie jest wymagana powinowatość sesji (session affinity); dowolny backend może obsłużyć każde żądanie.
  • Gotowość na serverless – funkcje mogą uruchamiać się na żądanie, obsługiwać żądanie i wyłączać się bez pozostawiania stanu.
  • Autoskalowanie Kubernetes – pody mogą być swobodnie dodawane lub usuwane; płaszczyzna sterowania (control plane) nie śledzi już map sesji.

Kompromisy

  • Narzut tokenów – uchwyty i wszelkie inne stany zajmują teraz okno kontekstowe modelu, bezpośrednio konkurując z promptem i odpowiedzią.
  • Poprawność sterowana przez model – model musi poprawnie odsyłać uchwyty; halucynacja lub literówka może przerwać przepływ pracy.
  • Brak wbudowanej możliwości wznawiania – długotrwałe zadania muszą implementować własne punkty kontrolne (checkpointing) lub zaakceptować ryzyko pełnego restartu.
  • Wycofanie diagnostyki – pola Roots, sampling i logging zniknęły, więc programiści tracą wygodny punkt styku (hook) do szczegółowego monitorowania, chyba że dodadzą go na warstwie aplikacji.

Podsumowanie

Poprzez usunięcie stanu sesji z warstwy przesyłania danych, MCP 2026-07 zmienia protokół w czysty punkt końcowy HTTP, który może znajdować się za dowolnym load balancerem, platformą funkcji czy węzłem brzegowym (edge node). Zaletą jest bezdyskusyjna skalowalność; wadą jest to, że stan znajduje się teraz w ograniczonym oknie tokenów modelu, a niezawodność spoczywa na kliencie i warstwie Pilot. W miarę jak zadania agentów AI wydłużają się z sekund do godzin, to balans między niską ceną za żądanie a presją budżetu tokenów zdecyduje, czy bezstanowy model okaże się trwałym sukcesem.