Bezzstanie MCP w specyfikacji z 2026-07-28: Jakie zmiany dotyczą infrastruktury agentów.
Nowa wersja MCP eliminuje sesje, dodaje nagłówki routingu, obie strony wymagające danych wejściowych oraz bardziej rygorystyczne zasady OAuth. Co to oznacza dla bramek, skalowalności i bezpieczeństwa.
Źródła: MCP Goes Stateless: Why the New Spec Changes Agent Infrastructure
Model Context Protocol rozwijał się szybko. Na początku dyskusje koncentrowały się na łączeniu aplikacji AI z narzędziami i danymi. Od tamtej pory przeszedł przez autoryzację OAuth, serwery zdalne, dużą liczbę rewizji protokołu, rejestry, dokumenty metadanych Client ID oraz autoryzację przedsiębiorstw. Specyfikacja z 2026-07-28 zmienia coś bardziej fundamentalnego: sam protokół staje się bezstanowy.
Brak już procedury inicjalizacji oraz sesji na poziomie protokołu. Klient nie musi już być przywiązany do instancji serwera, która przyjęła jego połączenie. Każda prośba zawiera wystarczająco dużo informacji, aby funkcjonować samodzielnie, a na nią może odpowiedzieć każda kompatybilna instancja.
Można by to uznać za drobną modyfikację transportową, ale wpływ na architekturę jest znacznie głębszy. Serwery zdalne mogą funkcjonować jak każda chmurowa usługa HTTP, znajdując się za zwykłymi balanserami obciążenia, bramkami API, systemami WAF, platformami serverless oraz skalowalnymi flotami kontenerów, bez specjalistycznego sprzętu do zarządzania sesjami właściwego dla MCP.
Rewizja przynosi jeszcze więcej: standardowe nagłówki routingu, wyniki wyszukiwania, które można zapamiętywać w pamięci podręcznej, zapytania wielokrotnych przejść, silniejsze zasady autoryzacji, konwencje OpenTelemetry oraz formalny model rozszerzeń. MCP wydaje się mniej wyjątkowy jako infrastruktura, co może być jednym z najwyraźniejszych oznak dojrzałości. Dalej omówiono zmiany, dlaczego brak stanu jest ważny w środowisku produkcyjnym oraz jakie ma to implikacje dla bezpieczeństwa, bramek i ogólnego środowiska działania agentów.
Dlaczego sesje szkodzą
MCP zaczęło się od prostego problemu: zapewnienie aplikacjom AI standardowego sposobu na obsługę narzędzi, zasobów oraz zewnętrznych systemów. Dla lokalnych klientów i serwerów działało to naturalnie. Wersja zdalna MCP zmieniła sytuację. Gdy serwery zaczęły działać w kontenerach, klastrach Kubernetes, platformach serverless oraz infrastrukturze chmurowej, sesje na poziomie protokołu powodowały typowe problemy związane z systemami rozproszonymi.
Klient uruchamiał procedurę inicjalizacji, serwer mógł przydzielić Mcp-Session-Id, a każda późniejsza prośba musiała zachować tę relację. Na dużą skalę mogło to oznaczać:
- przywiązanie load-balancera
- wspólne magazyny sesji
- mechanizmy przechodzenia na zapas, które rozumieją sesje
- połączenia o długim czasie trwania
- dodatkową obsługę cyklu życia
Żadna z tych kwestii nie jest niemożliwa do opanowania, ponieważ systemy rozproszone radzą sobie z nimi od dziesięcioleci. Warto zadać pytanie, czy MCP w ogóle musiało tworzyć te problemy, a wraz z datą 2026-07-28 odpowiedź staje się coraz bardziej przecząca.
Nowa specyfikacja całkowicie eliminuje procedury initialize oraz notifications/initialized, sesje na poziomie protokołu oraz Mcp-Session-Id. Prośby zawierają wszystko, co jest potrzebne do ich przetworzenia. Koncepcyjnie architektura zmienia się w następujący sposób:
Każda zgodna instancja może obsłużyć kolejną prośbę. To znacznie lepiej pasuje do Kubernetes, kontenerów, funkcji serverless, automatycznego skalowania, infrastruktury edge oraz zwykłego równomiernego rozkładania obciążenia.
To już dzieje się w praktyce. Cloudflare przeniosło swoje serwery MCP na ten model i tworzy nowy, bezstanowy serwer dla każdej żądania. Google wskazuje na koniec sesji trwałych oraz wspólnej infrastruktury sesji jako na istotną korzyść pod względem skalowalności. AWS AgentCore Gateway obsługuje teraz nowy protokół obok wcześniejszych wersji MCP. Dlatego jest to element obecnego modelu wdrażania, a nie teoretyczna architektura.
Stan nie znika
Tutaj ważna jest różnica. Usunięcie sesji MCP nie powstrzymuje aplikacji przed przechowywaniem stanu. Oznacza to, że stan aplikacji nie powinien być ukryty w mechanizmach transmisji. Weźmy na przykład agenta tworzącego przestrzeń roboczą:
create_workspace()
|
v
workspace_id = ws_123
Późniejsza prośba może wyraźnie określić wynik:
update_workspace( workspace_id = "ws_123" )
Pierwsza prośba może trafić na serwer A, a druga na serwer C. Aplikacja nadal ma stan, ale teraz posiada wyraźny identyfikator i nie polega już na niewidzialnym połączeniu pomiędzy klientem a procesem serwera.
Stan protokołu i stan aplikacji to różne rzeczy. Wyraźny stan aplikacji jest łatwiejszy do przechowywania, audytowania, autoryzowania, wygaszania oraz analizowania, a systemy oparte na agentach mają dodatkową zaletę: agent może bezpośrednio pracować z tym identyfikatorem i przenosić go pomiędzy narzędziami oraz etapami procesu pracy.
Heady routingu
Brak stanu rozwiązuje jeden problem infrastrukturalny, a inna zmiana może być równie ważna w przypadku wdrożeń korporacyjnych. MCP standaryzuje teraz nagłówki HTTP, które opisują trwającą operację. Na przykład:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace
Wcześniej pośrednik musiałby otworzyć treść JSON-RPC, aby dowiedzieć się, czego chce agent. Teraz informacje te są widoczne na warstwie HTTP, co otwiera szereg interesujących możliwości.
Zespoły ds. bezpieczeństwa mają powody do zaniepokojenia. Agenci mają dostęp do coraz potężniejszych narzędzi, a bramka staje się naturalnym miejscem do egzekwowania zasad pomiędzy intencją a efektem zewnętrznym. Nic z tego nie eliminuje potrzeby mechanizmów kontrolnych na poziomie aplikacji czy agenta. Można nawet powiedzieć, że to sprawia, iż granice pomiędzy protokołem, bramką, mechanizmami kontrolnymi a systemami za nimi są jaśniejsze.
Prośba o dane bez sesji
Przejście na model bezstanowy rodzi oczywisty problem. Co jeśli serwer potrzebuje dodatkowych informacji, zanim będzie mógł zakończyć operację? Wyobraźmy sobie destruktywną próbę połączenia:
delete_environment(“production”)
Server może najpierw chcieć potwierdzenia. Utrzymywanie otwartej sesji dwukierunkowej wyłącznie w celu tej wymiany zniweczyłoby większość zalet braku stanu.
Odpowiedzią specyfikacji są wielokrotne żądania typu Round-Trip (MRTR). Sesja nie utrzymuje już aktywnej interakcji. Zamiast tego server zwraca wynik input_required, który wskazuje, czego potrzebuje. Proces wymiany przebiega mniej więcej w ten sposób:
Zatwierdzenie przez człowieka, dodatkowa autoryzacja, brakujące parametry, sprawdzanie zasad oraz podobne interaktywne procesy mogą mieścić się w modelu żądań bez stanu. Jest to szczególnie istotne w przypadku działań agentów o wysokim ryzyku. Możliwość wywołania narzędzia nie daje agentowi nieograniczonej władzy, a operacje wrażliwe mogą wymagać dodatkowego punktu decyzyjnego przed ich wykonaniem.
Kasowanie z pamięci i obserwowalność
Część mniej widocznych zmian może okazać się istotna w skali większej. Są to m.in. operacje wykazywania:
tools/list
prompts/list
resources/list
resources/read
Teraz można zwracać szczegóły cache, takie jak ttlMs i cacheScope, a listy narzędzi powinny być zwracane w określonej kolejności. Wydaje się to zwykłą optymalizacją protokołu HTTP, ale systemy AI również odnoszą z tego korzyść: stabilne definicje narzędzi mogą poprawić przechowywanie promptów na poziomie modeli LLM, natomiast narzędzia pojawiające się w zmiennej kolejności lub wymagające ponownego znajdowania przekształcają drobną specyfikację protokołu w dodatkową opóźnienie i koszt tokenów.
Specyfikacja opisuje również, jak przenosić kontekst OpenTelemetry, wykorzystując znane pola:
traceparent
tracestate
baggage
To kolejny przypadek, gdy MCP zmierza w kierunku infrastruktury, którą zespoły DevOps i platformowe już znają. Celem nie powinien być oddzielny zestaw narzędzi do obserwowalności stworzony wyłącznie dla protokołów AI. Powinno chodzić o to, by aktywność agentów była widoczna w systemach, które organizacje już używają.
Tożsamość staje się coraz ważniejsza
Prośby bez stanu nie zmniejszają znaczenia tożsamości. Wręcz przeciwnie – sprawiają, że prawidłowe obsłużenie każdej prośby staje się kluczowe. Nowa specyfikacja kontynuuje rozwój MCP w kierunku ugruntowanych praktyk OAuth i OpenID Connect. Obejmuje to weryfikację wydawcy, mającą na celu przeciwdziałanie atakom polegającym na pomyleniu serwerów autoryzacji, oraz bardziej ścisłe powiązanie danych uwierzytelniających.
Specyfikacja formalizuje również tendencję, która się rozwijała: rejestracja dynamiczna klientów jest przestarzała i zastępowana dokumentami metadanych identyfikatora klienta. CIMD okazuje się lepszą opcją ze względu na prostotę, podczas gdy DCR nadal jest używany ze względu na kompatybilność, a tekst teraz jasno to stwierdza. Jest to kolejny sygnał dojrzałości, ponieważ MCP unika prywatnego systemu tożsamości i coraz bardziej zbliża się do standardów już używanych w sieci. Jest to szczególnie ważne przy wdrażaniu agentów w przedsiębiorstwach, gdy MCP rozwija się od kilku integracji zatwierdzonych przez użytkowników do dużej liczby agentów, klientów, bramek i narzędzi.
Rejestracja to zaledwie część procesu autoryzacji. Na poziomie przedsiębiorstw trudniejszym pytaniem jest to, które agenty mogą korzystać z jakich funkcji: setki agentów korzystających z setek usług powodują skomplikowane problemy zarządzania typu N×M. Dwa mechanizmy – Enterprise-Managed Authorization (EMA) oraz Identity Assertion Authorization Grants (ID-JAG) – przenoszą to zadanie na centralną politykę przedsiębiorstwa. Dostawca tożsamości przedsiębiorstwa pomaga zdecydować, czy agent otrzyma dostęp, dzięki czemu poszczególne serwery MCP nie muszą prosić użytkowników o zgodę pojedynczo.
MCP bez stanu nie zastępuje tego modelu. Raczej pogłębia rozdzielenie: stan transportu, tożsamość klienta, polityka autoryzacji oraz stan aplikacji to odrębne aspekty architektoniczne.
Co pozostaje poza rdzeniem
Ważną częścią tej wersji jest to, co MCP usuwa lub przenosi. Funkcje Roots, Sampling i Logging opuszczają rdzeń modelu, a starszy transport HTTP+SSE ustępuje miejsca Streamable HTTP. Jednocześnie pojawia się formalna ramka rozszerzeń, dzięki której takie funkcje jak Tasks mogą rozwijać się poprzez rozszerzenia bez powiększania rdzenia protokołu. To oznacza zdrowsze rozgraniczenie:
MCP nie musi stać się całym środowiskiem wykonawczym agenta. Narzędzie to nadal kontroluje szersze środowisko wykonawcze, a MCP dostarcza standardowy sposób na interakcję tego środowiska z zewnętrznymi funkcjami. Dojrzały protokół nie jest definiowany tylko przez to, co dodaje, ale także przez to, co postanawia umieścić gdzie indziej.
Brak stanu nie oznacza zaufania
Server MCP bez stanu skaluje się prostiej, chociaż brak stanu nie oznacza zaufania: każda prośba nadal przechodzi przez granicę bezpieczeństwa. Iniekcja poleceń lub zatruty kontekst mogą nadal kierować agentami. Narzędzia mogą nadal posiadać nadmierne uprawnienia, dane uwierzytelniające mogą być źle skonfigurowane, a kompromitacja łańcucha dostaw może spowodować pojawienie się złośliwych serwerów lub narzędzi.
Zmienia się to tym, że architektura staje się bardziej uporządkowana. Zamiast traktować sesje transporowe jako część modelu bezpieczeństwa, środki ochronne mogą skupiać się na tym, kim w sposób wiarygodny jest osoba wysyłająca żądanie, jaką politykę stosuje brama oraz jakie uprawnienia przyznaje każde narzędzie. Należy dodać wyraźną autoryzację i wyraźne identyfikatory zasobów, następnie weryfikować dane wejściowe, wymagać zatwierdzenia człowieka dla działań wrażliwych, rejestrować dane telemetryczne w celach audytu oraz kontrolować również narzędzie używane przez agenta.
Jeden subtelny aspekt: metadane klienta nie są automatycznie tożsamością. To, co klient podaje o sobie w metadanych żądania, nie może być traktowane tak samo jak tożsamość ustalona kryptograficznie za pomocą OAuth lub innego zaufanego mechanizmu. Łatwiejsze kierowanie ruchem i inspekcja ruchu MCP umożliwiają zespołom bezpieczeństwa zaostrzenie kontroli nad protokołem, bez mylenia metadanych z zaufaniem.
Cały obraz
Zmiana kluczowa w 2026-07-28 jest prosta: MCP nie posiada stanu. Ważniejsze jest to, co to umożliwia. Zapytania MCP zachowują się bardziej jak zwykłe obciążenia HTTP. Serwery skalują się horyzontalnie bez konieczności utrzymywania powiązań sesji. Bramy rozumieją operacje MCP za pomocą standardowych nagłówków. Proces odkrywania może być buforowany. Interaktywne przepływy pracy kontynuują się poprzez wielokrotne żądania. Autoryzacja coraz bardziej opiera się na sprawdzonej praktyce OAuth, możliwości monitorowania można realizować za pomocą OpenTelemetry, a rozszerzenia pozwalają na dalszy rozwój bez konieczności przekształcania rdzenia w pełny silnik działania agenta.
Po pojedyncze oglądane są jak ulepszenia protokołu, ale razem mówią więcej. MCP zaczęło od rozwiązywania problemów z połączalnością. Remote MCP sprawiło, że ekosystem musiał zmierzyć się z kwestiami tożsamości i autoryzacji. CIMD oraz autoryzacja przedsiębiorstw skupiają się teraz na zarządzaniu, natomiast stateless MCP zajmuje się operacyjnością i skalowalnością. Protokół staje się coraz mniej ekskluzywny i pasuje do infrastruktury, której ludzie już wiedzą, jak budować, zabezpieczać, monitorować i uruchamiać. Biorąc pod uwagę tak szybki rozwój, to właśnie stanie się nudną infrastrukturą może być głównym celem.
Literatura pokrewna
- Praktyczne notatki: „MCP: Protokół, który przekształca AI z chatbota w agenta AI” — Szczegółowy przewodnik po praktycznych notatkach: „MCP: Protokół, który przekształca AI z chatbota w agenta AI”: umowy, sprawdzania oraz gotowe elementy kodu dla zespołów tworzących systemy MCP. — Operable walkthrough of Practical notes: “MCP: Protocol That Turns AI From a Chatbot Into an AI Agent”: contracts, checks, and drop-in code slots for teams shipping mcp systems.
- Tworzenie lokalnego agenta badawczego w LM Studio przy użyciu czterech serwerów MCP — Połączenie serwerów filesystem, GitHub, SearXNG i Camofox MCP w jednej rozmowie w LM Studio, uproścenie schematu narzędzia, dodanie promptu dotyczącego planu badań oraz weryfikacja poprawności za pomocą demonstracji. — Building a Local Research Agent in LM Studio With Four MCP Servers — Combine filesystem, GitHub, SearXNG and Camofox MCP servers in one LM Studio chat, trim the tool schema, add a research plan prompt and verify grounding with a demo.