MCP version 2 wchodzi w życie 28 lipca 2026 r. Rezygnuje z każdego handshake'u, nagłówka session-ID oraz trzech przestarzałych podsystemów, które wiązały Model Context Protocol (MCP) z serwerami typu sticky-session. Protokół staje się całkowicie bezstanowy (stateless), dzięki czemu każda instancja autoskalowalna lub serverless może obsłużyć dowolne żądanie bez konieczności zachowywania stanu klienta.

Dlaczego ta zmiana jest istotna

MCP v1 wymuszał na kliencie rozpoczęcie sesji poprzez handshake initialize; serwer przydzielał wówczas Mcp-Session-Id. Każde kolejne wywołanie musiało zawierać ten nagłówek, co wiązało użytkownika z pojedynczym węzłem backendowym. Load balancery musiały wymuszać powinowactwo sesji (session affinity), co zwiększało opóźnienia i utrudniało operacje.

Bezstanowość eliminuje te trudności. Cały kontekst znajduje się teraz w dedykowanych polach meta, które towarzyszą każdemu wywołaniu HTTP. Żądanie może trafić do dowolnej instancji, zostać przetworzone, a instancja może zostać usunięta w momencie wysłania odpowiedzi. Zespoły korzystające z platform serverless, klastrów zarządzanych przez kontenery lub dowolnego środowiska, które uruchamia i zatrzymuje pody na żądanie, mogą teraz dopasować protokół do swojej infrastruktury.

Co zostaje wycofane

Trzy podsystemy, które zależały od trwałych połączeń, zostają oficjalnie uznane za przestarzałe (deprecated):

  • Sampling – W wersji v1 serwer mógł poprosić klienta o wygenerowanie tekstu, co wymagało otwartej sesji. W v2 oczekuje się, że serwer wywoła dostawcę modelu LLM bezpośrednio lub skorzysta z wzorca InputRequiredResult, w którym klient dostarcza brakujące dane w kolejnym żądaniu.
  • Roots – Wcześniej klienci przesyłali URI, które ograniczały widok zasobów zewnętrznych serwera. Nowe podejście przekazuje te URI jako parametry narzędzi (tool parameters) lub osadza je w polach zasobów żądania, eliminując oddzielny krok negocjacji „roots”.
  • Logging – Nagłówki logowania na poziomie protokołu znikają. Należy pisać do stderr w celu lokalnego debugowania lub wdrożyć OpenTelemetry dla obserwowalności w środowisku produkcyjnym.

Okres wycofywania funkcji (deprecation window) trwa rok. Przestarzałe funkcje będą działać przez ten czas, dając zespołom czas na refaktoryzację, zanim protokół zacznie je odrzucać.

Co nowego poza bezstanowością

MCP v2 wprowadza dwa oficjalne rozszerzenia:

  • MCP Apps – Lekki sposób na opisywanie interfejsów użytkownika renderowanych po stronie serwera, które protokół może wywoływać.
  • Tasks – Wzorzec obsługi długotrwałych operacji, które mogą obejmować wiele cykli żądanie-odpowiedź.

Oba rozszerzenia zakładają bezstanowy model żądań i unikają ukrytego stanu sesji.

Ryzyka i kontrargumenty

Ta zmiana nie jest ulepszeniem typu „plug-and-play”. SDK v2 są wciąż w fazie beta, a ich publiczne API mogą ulec zmianie przed wydaniem stabilnej wersji. W przypadku obciążeń produkcyjnych, które nie mogą tolerować zmian naruszających kompatybilność (breaking changes), należy pozostać przy stabilnym SDK v1, dopóki SDK v2 nie zostanie oficjalnie wydane.

Programiści muszą również przeprowadzić audyt istniejącego kodu pod kątem wykorzystania któregokolwiek z trzech wycofywanych podsystemów.

Pragmatyczna mapa drogowa migracji

  1. Przeprowadź audyt już dziś – Przeskanuj swoje usługi pod kątem użycia handshake'u, Mcp-Session-Id, wywołań sampling, URI roots oraz logowania na poziomie protokołu. Zidentyfikuj kod, który przestałby działać w modelu bezstanowym.
  2. Testuj na niekrytycznym węźle – Gdy zostanie wydane stabilne SDK v2, uruchom serwer typu sandbox, skieruj go do klienta testowego i zweryfikuj, czy wszystkie wymagane pola meta są obecne i poprawnie interpretowane.
  3. Pełna migracja przed terminem – Zakończ proces przełączania na wszystkich węzłach produkcyjnych przed upływem rocznego okresu przejściowego, aby uniknąć odrzucania żądań w czasie rzeczywistym.

Na co zwrócić uwagę w następnej kolejności

  • Wydanie stabilnego SDK – Beta wersje SDK zostaną zamrożone, a zostanie opublikowany wersjonowany, stabilny pakiet. Ta wersja będzie bezpiecznym celem dla wszelkich krytycznych wdrożeń.

Przejście będzie wymagało zmian w kodzie oraz krótkiego okresu eksperymentowania z beta-SDK, ale efektem będzie czystszy i bardziej skalowalny punkt integracji dla każdej aplikacji opartej na LLM.

Podsumowanie: Jeśli Twój stos technologiczny nadal opiera się na handshake'ach MCP lub trzech wycofywanych podsystemach, rozpocznij audyt już teraz; roczny okres przejściowy jest hojny, ale prawdziwym kosztem jest wysiłek związany z refaktoryzacją, a nie sam termin.