Nowa specyfikacja MCP z dnia 2026-07-28 rezygnuje ze wszystkich wymagań dotyczących stanu sesji, pozwalając każdemu żądaniu nieść wszystkie niezbędne dane. Przejście na protokół bezstanowy (stateless) oznacza, że programiści mogą uruchamiać pojedynczą instancję na każde wywołanie, korzystać z rozwiązań serverless lub węzłów edge i wycofać przestarzałe mechanizmy „sticky routing” oraz współdzielonych magazynów danych, które stanowiły problem przy wdrażaniu.

Od uścisków dłoni do samodzielnych wywołań

Do tej pory Model Context Protocol (MCP) wymuszał uścisk dłoni (handshake), który generował identyfikator sesji. Serwery musiały pamiętać ten identyfikator przez cały czas trwania połączenia, co w praktyce oznaczało utrzymywanie aktywnych procesów, replikowanie stanu w klastrze Redis lub konfigurowanie load balancerów pod kątem „sticky routing”. Rezultatem był złożony, obciążający zasoby stos technologiczny, który utrudniał skalowanie i sprawiał, że wzrost horyzontalny stawał się kosztowny.

Nowa specyfikacja sprawia, że każde żądanie jest samodzielne. Każdy payload zawiera wersję protokołu oraz tożsamość wywołującego, dzięki czemu serwer może traktować żądanie jako pojedynczą transakcję. Brak magazynu sesji, brak długożyjących procesów, brak specjalnych reguł routingu.

Dlaczego bezstanowość ma znaczenie dla wdrażania

  • Gotowość na serverless i edge – Żądanie zawiera wszystko, czego potrzebuje, więc funkcja może wystartować, odpowiedzieć i zostać zamknięta bez konieczności przygotowywania stanu (warm-up state). Dostawcy rozliczani za każde wywołanie stają się opłacalni dla obciążeń MCP.
  • Uproszczone równoważenie obciążenia – Standardowe load balancery L4/L7 mogą równomiernie rozdzielać ruch; nie ma potrzeby przypisywania klienta do konkretnego backendu.
  • Zmniejszenie narzutu operacyjnego – Zespoły mogą wycofać klastry Redis lub niestandardowy kod replikacji sesji, co obniża zarówno koszty, jak i ryzyko awarii.

Dla organizacji, które już uruchamiają MCP za load balancerem, zmiana ta eliminuje potrzebę stosowania reguł „sticky”, które często wymuszają nierównomierny rozkład ruchu. Oszczędności są szczególnie widoczne w przypadku usług o wysokiej przepustowości, obsługujących miliony wywołań dziennie.

Ulepszenia wydajności i bezpieczeństwa

Specyfikacja wprowadza konkretne usprawnienia, które wzmacniają protokół poza samą jego bezstanowość:

  • Buforowanie oparte na TTL – Listy narzędzi i promptów zawierają teraz pole time-to-live, co pozwala klientom buforować wyniki lokalnie i unikać niepotrzebnych cykli komunikacji (round-trips).
  • Routing sterowany nagłówkami – Nowe nagłówki HTTP udostępniają informacje o routingu na wczesnym etapie, dzięki czemu bramy (gateways) mogą przekazywać ruch bez konieczności analizowania całego korpusu JSON, co skraca opóźnienia o milisekundy.
  • Wzmocnienie OAuth/OIDC – Tokeny tożsamości podlegają surowszym kontrolom OAuth i OpenID Connect, co zmniejsza ryzyko ataków typu replay oraz kradzieży tokenów.
  • Formalny framework rozszerzeń – Zadania (Tasks) i Aplikacje (Apps) należą teraz do zdefiniowanego modelu rozszerzeń, co ułatwi wprowadzanie nowych funkcji przez utrzymujących SDK.

Wpływ na programistów

Ekosystem SDK już odzwierciedla tę zmianę: biblioteki TypeScript, Python, Go i C# emitują nowy format żądań. Łączna liczba pobrań tych SDK zbliża się do pół miliarda miesięcznie – to czterokrotny wzrost w porównaniu z początkiem roku, co świadczy o szerokiej adopcji MCP.

Programiści muszą dostosować wszelki kod, który zakładał trwałą sesję. Zazwyczaj oznacza to przeniesienie danych specyficznych dla sesji do payloadu żądania lub do zewnętrznego magazynu sprawdzanego przy każdym wywołaniu. Okno migracyjne wynosi dwanaście miesięcy, co daje zespołom czas na refaktoryzację, testowanie i wdrażanie nowego wzorca.

Kontrargument: Złożoność migracji

Bezstanowość nie jest darmowym rozwiązaniem. Aplikacje, które wcześniej polegały na stanie po stronie serwera (np. w celu zachowania progresywnej historii rozmowy), muszą teraz zarządzać tym stanem po stronie klienta lub za pomocą oddzielnej warstwy trwałości danych (persistence layer).

Na co zwrócić uwagę

  • Metryki adopcji – Należy monitorować tempo wdrażania nowych wersji SDK; spowolnienie może sygnalizować trudności z migracją.
  • Wsparcie dla platform edge – W miarę jak kolejni dostawcy będą ogłaszać środowiska uruchomieniowe zgodne z MCP, rzeczywiste korzyści kosztowe rozwiązań serverless staną się wyraźniejsze.
  • Raporty o incydentach bezpieczeństwa – Wzmocniony przepływ OAuth/OIDC powinien ograniczyć ataki na tożsamość, ale każde naruszenie przetestuje nowe zabezpieczenia.

Podsumowanie: Poprzez uczynienie MCP bezstanowym, specyfikacja dostosowuje protokół do nowoczesnych wzorców cloud-native, redukując operacyjny ciężar zarządzania sesjami i otwierając drzwi do tańszych, bardziej elastycznych modeli wdrażania. Kosztem jest krótki okres refaktoryzacji kodu i większy rozmiar żądań, ale długofalową korzyścią jest protokół, który skaluje się równie łatwo, jak infrastruktura, na której pracuje.