Największa rewizja protokołu od premiery. Serwer, który wcześniej wymagał sticky sessions, teraz jedzie za zwykłym round-robinem.
28 lipca 2026 Model Context Protocol dostał finalną wersję specyfikacji 2026-07-28. Release candidate był zamrożony 21 maja, przez dziesięć tygodni walidowały go zespoły utrzymujące SDK — i wersja finalna wyszła bez poślizgu. Wszystkie cztery SDK Tier 1 miały wsparcie w dniu publikacji.
To nie jest kosmetyka. Poprzednia wersja, 2025-11-25, zakładała że klient i serwer utrzymują sesję: najpierw handshake, potem nagłówek Mcp-Session-Id na każdym kolejnym żądaniu. Nowa specyfikacja usuwa jedno i drugie. Protokół jest bezstanowy, rozszerzenia mają własny cykl życia, autoryzacja dogania to jak OAuth i OIDC są realnie wdrażane, a trzy funkcje z rdzenia trafiły do deprecacji.
Jeśli utrzymujesz serwer MCP w produkcji, ta zmiana dotyczy Cię bezpośrednio. Jeśli dopiero budujesz — właśnie zrobiło się wyraźnie łatwiej.
Przed i po, na drucie
Wywołanie narzędzia w 2025-11-25 zaczynało się od nawiązania sesji:
POST /mcp HTTP/1.1
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-11-25","capabilities":{},
"clientInfo":{"name":"webflux-client","version":"1.0"}}}Serwer odbijał identyfikator sesji, który klient musiał nosić przy każdym następnym żądaniu — i który przypinał go do konkretnej instancji:
POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search_posts","arguments":{"q":"agentic web"}}}W 2026-07-28 to samo wywołanie jest jednym samowystarczalnym żądaniem, które może obsłużyć dowolna instancja:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_posts
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search_posts","arguments":{"q":"agentic web"},
"_meta":{"io.modelcontextprotocol/clientInfo":
{"name":"webflux-client","version":"1.0"}}}}Zwróć uwagę na trzy rzeczy: nie ma initialize, nie ma Mcp-Session-Id, a informacje o kliencie jadą w _meta przy każdym żądaniu.
Handshake i sesja: usunięte
Za wywaleniem handshake'a stoi SEP-2575. Wersja protokołu, dane klienta i jego capabilities — czyli wszystko, co wcześniej wymieniało się raz przy nawiązywaniu połączenia — podróżuje teraz w _meta na każdym żądaniu. Kiedy klient naprawdę potrzebuje poznać możliwości serwera z wyprzedzeniem, jest nowa metoda server/discover.
Nagłówek Mcp-Session-Id i sesja na poziomie protokołu znikają wraz z SEP-2567. Konsekwencja operacyjna jest dokładnie taka, jak brzmi: dowolne żądanie MCP może wylądować na dowolnej instancji serwera. Sticky routing i współdzielony session store, których wcześniej wymagało poziome skalowanie, przestają być potrzebne na poziomie protokołu.
Cały ten ruch to sześć SEP-ów działających razem — domknięcie planu, który maintainerzy opisali w grudniu 2025 w „The Future of MCP Transports".
Protokół bezstanowy ≠ aplikacja bezstanowa
To jest miejsce, w którym najłatwiej wyciągnąć zły wniosek. Usunięcie sesji z protokołu nie oznacza, że Twoja aplikacja musi zapomnieć wszystko między wywołaniami.
Wzorzec, który specyfikacja rekomenduje, jest tym samym, co API HTTP robią od dwudziestu lat: jawny uchwyt. Narzędzie zwraca identyfikator, model przekazuje go z powrotem jako zwykły argument przy kolejnym wywołaniu.
create_draft() → { "draft_id": "d_8812" }
add_section(draft_id="d_8812", heading="Wstęp")
publish(draft_id="d_8812")Maintainerzy argumentują, że to nie jest gorszy substytut stanu sesyjnego, tylko lepszy wariant. Model może komponować uchwyty między narzędziami, rozumować o nich i przekazywać je między krokami — czego stan schowany w metadanych transportu nigdy nie umożliwiał. Stan przestaje być niewidzialny dla modelu.
Praktyczny wniosek dla Ciebie: przejrzyj swoje narzędzia i zapytaj, gdzie polegały na tym, że serwer „pamięta" kontekst. Każde takie miejsce trzeba zamienić na jawny identyfikator w sygnaturze narzędzia.
Serwer pyta klienta bez otwartego SSE
Bezstanowy protokół nadal musi umieć zapytać użytkownika w połowie operacji — choćby o potwierdzenie. Dwa SEP-y przebudowują ten przepływ tak, żeby działał bez trzymanego połączenia.
SEP-2260 zawęża okno: żądania inicjowane przez serwer mogą pojawić się wyłącznie wtedy, gdy serwer aktywnie przetwarza żądanie klienta. Wcześniej było to zalecenie, teraz jest wymóg. Efekt: użytkownik nigdy nie dostaje promptu znikąd, a każda elicytacja daje się prześledzić do czegoś, co sam (albo jego agent) zainicjował.
SEP-2322 wprowadza Multi Round-Trip Requests. Zamiast trzymać otwarty strumień SSE, serwer zwraca wynik typu input_required:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "Opublikować 3 wpisy?",
"schema": { "type": "boolean" }
}
},
"requestState": "eyJzdGVwIjoxfQ=="
}Klient zbiera odpowiedzi i ponawia oryginalne wywołanie z inputResponses oraz odesłanym z powrotem requestState. Ponowienie może obsłużyć dowolna instancja, bo wszystko, czego potrzebuje, jest w payloadzie.
To jest ta zmiana, która sprawia, że elicytacja przestaje wymagać długożyjącego połączenia — i tym samym przestaje być powodem, dla którego nie postawisz serwera na funkcjach serverless.
Routowalne, cache'owalne, śledzalne
Trzy mniejsze zmiany, które najbardziej odczujesz w warstwie operacyjnej.
Nagłówki Mcp-Method i Mcp-Name są teraz wymagane w transporcie Streamable HTTP (SEP-2243). Load balancery, bramki i rate-limitery mogą routować po operacji bez zaglądania do ciała żądania. Serwery odrzucają żądania, w których nagłówki nie zgadzają się z body.
To jest bezpośrednia odpowiedź na problem, który opisywaliśmy przy okazji bramki MCP: dotąd, żeby nałożyć osobny limit na tools/call i osobny na tools/list, trzeba było parsować JSON-RPC w bramce. Teraz to jest routing po nagłówku, czyli konfiguracja nginxa.
Wyniki list i odczytów zasobów niosą ttlMs i cacheScope (SEP-2549), wzorowane na HTTP Cache-Control. Klient wie dokładnie, jak długo odpowiedź tools/list jest świeża i czy wolno ją współdzielić między użytkownikami. Długożyjący strumień SSE przestaje być jedynym sposobem, żeby dowiedzieć się, że lista się zmieniła.
Propagacja W3C Trace Context w _meta jest udokumentowana (SEP-414) — nazwy kluczy traceparent, tracestate i baggagesą przybite w specyfikacji. Trace zaczęty w aplikacji hosta przechodzi przez SDK klienta, serwer MCP i to, co serwer woła dalej, i pojawia się jako jedno drzewo spanów w backendzie zgodnym z OpenTelemetry. Część SDK robiła to już wcześniej — teraz nazwy się zgadzają między implementacjami.
Rozszerzenia stają się pierwszoklasowe
Rozszerzenia istniały już w 2025-11-25, ale nie miały za sobą żadnego formalnego procesu. SEP-2133 to zmienia:
- identyfikowane przez odwrócone DNS-y,
- negocjowane przez mapę
extensionsw capabilities klienta i serwera, - mieszkają we własnych repozytoriach
ext-*z delegowanymi maintainerami, - wersjonują się niezależnie od specyfikacji.
W procesie SEP powstał osobny Extensions Track, dający rozszerzeniom ścieżkę od eksperymentu do statusu oficjalnego. Wraz z wydaniem oficjalne są dwa.
MCP Apps
SEP-1865. Serwery mogą dostarczać interaktywne interfejsy HTML, które host renderuje w sandboksowanym iframe. Narzędzia deklarują swoje szablony UI z wyprzedzeniem, żeby host mógł je prefetchować, cache'ować i przejrzeć pod kątem bezpieczeństwa, zanim cokolwiek się uruchomi. Wyrenderowany interfejs rozmawia z hostem po tym samym JSON-RPC, co reszta MCP — więc każda akcja zainicjowana z UI przechodzi tę samą ścieżkę audytu i zgody, co bezpośrednie wywołanie narzędzia.
Jeśli czytałeś nasz wpis o MCP Apps / MCP-UI — to, co było wtedy propozycją, jest teraz oficjalnym rozszerzeniem z własnym wersjonowaniem.
Tasks
Tasks weszły w 2025-11-25 jako eksperymentalna funkcja rdzenia. Użycie produkcyjne wygenerowało tyle potrzeby przeprojektowania, że właściwym miejscem okazało się rozszerzenie, nie specyfikacja.
Nowy cykl życia jest przekształcony pod model bezstanowy: serwer może odpowiedzieć na tools/call uchwytem zadania, a klient steruje nim przez tasks/get, tasks/update i tasks/cancel. Tworzenie zadania jest sterowane przez serwer — klient ogłasza, że obsługuje rozszerzenie, a serwer decyduje, kiedy wywołanie ma pobiec jako zadanie. tasks/list zostało usunięte, bo bez sesji nie da się go bezpiecznie ograniczyć zakresem.
Kto wdrożył eksperymentalne API Tasks z 2025-11-25, musi zmigrować.
Autoryzacja: sześć SEP-ów utwardzenia
Cel to zbliżenie specyfikacji do tego, jak OAuth 2.0 i OpenID Connect są realnie wdrażane.
| SEP | Co wnosi |
|---|---|
| SEP-2468 | Klient musi walidować parametr iss w odpowiedziach autoryzacyjnych zgodnie z RFC 9207 — tania mitygacja klasy ataków mix-up, szczególnie istotna przy MCP-owym wzorcu „jeden klient, wiele serwerów". W przyszłej wersji klienci będą musieli odrzucać odpowiedzi bez iss. |
| SEP-837 | Klient deklaruje application_type z OIDC przy Dynamic Client Registration. Rozwiązuje typowy przypadek, w którym serwer autoryzacyjny domyślnie traktuje klienta desktopowego albo CLI jako "web" i odrzuca jego redirect URI na localhost. |
| SEP-2352 | Klient wiąże zarejestrowane poświadczenia z issuer wydającego serwera autoryzacyjnego i rejestruje się ponownie, gdy zasób migruje między serwerami. |
| SEP-2207 | Dokumentuje, jak prosić o refresh tokeny u serwerów w stylu OIDC. |
| SEP-2350 | Doprecyzowuje akumulację scope'ów przy step-upie. |
| SEP-2351 | Doprecyzowuje sufiks discovery .well-known. |
Praktycznie: jeśli prowadzisz serwer autoryzacyjny i jeszcze nie zwracasz iss, zacznij teraz. Jeśli piszesz klienta — walidacja iss to kilka linijek, które warto dopisać przed terminem.
Roots, Sampling i Logging: deprecated
Trzy funkcje rdzenia trafiły do deprecacji pod nową polityką cyklu życia (SEP-2577):
| Funkcja | Zamiennik |
|---|---|
| Roots | Parametry narzędzi, URI zasobów albo konfiguracja serwera |
| Sampling | Bezpośrednia integracja z API dostawcy LLM |
| Logging | stderr przy transporcie stdio; OpenTelemetry dla obserwowalności strukturalnej |
To są deprecacje wyłącznie w warstwie adnotacji. Metody, typy i flagi capabilities działają dalej w tym wydaniu i w każdej wersji specyfikacji opublikowanej w ciągu roku od niego. Usunięcie któregokolwiek będzie wymagało osobnego SEP-a pod polityką cyklu życia.
Innymi słowy: nic Ci się dziś nie wywali, ale masz jasny sygnał, w którą stronę planować.
JSON Schema 2020-12 i jedna zmiana kodu błędu
inputSchema i outputSchema narzędzi zostały podniesione do pełnego JSON Schema 2020-12 (SEP-2106). Schematy wejściowe zachowują ograniczenie type: "object" w korzeniu, ale dopuszczają teraz kompozycję (oneOf, anyOf, allOf), warunki i referencje ($ref, $defs). Schematy wyjściowe są bez ograniczeń, a structuredContent może być dowolną wartością JSON, nie tylko obiektem.
Dwa zastrzeżenia implementacyjne: nie wolno automatycznie rozwiązywać zewnętrznych URI w $ref, i należy ograniczać głębokość schematu oraz czas walidacji.
Osobno: kod błędu dla brakującego zasobu zmienia się z MCP-owego -32002 na standardowy JSON-RPC -32602Invalid Params (SEP-2164). Jeśli Twój klient matchuje na literał -32002, popraw to. To jest dokładnie ten typ zmiany, który przechodzi testy i wywala się w produkcji.
Jak protokół będzie się zmieniał dalej
To wydanie zawiera breaking changes i maintainerzy wprost piszą, że nie ma to być normą. Trzy SEP-y governance mają sprawić, że kolejne rewizje nie będą już łamać rdzenia:
- Polityka cyklu życia funkcji — każda funkcja ma stany Active, Deprecated, Removed, z minimum dwunastoma miesiącami między deprecacją a najwcześniejszym możliwym usunięciem.
- Framework rozszerzeń — nowe możliwości mogą wychodzić jako opt-in i stabilizować się tam, zanim (o ile w ogóle) trafią do specyfikacji.
- SEP-2484 — SEP ze ścieżki Standards Track nie może osiągnąć statusu Final, dopóki pasujący scenariusz nie wyląduje w conformance suite. To ta sama suite, według której punktowany jest system poziomów SDK.
Co to zmienia dla WordPressa i PHP
Tu jest realna dobra wiadomość dla naszej publiczności, i warto ją powiedzieć wprost.
Największą przeszkodą w hostowaniu serwera MCP na zwykłym stacku PHP było to, że protokół zakładał stan i długożyjące połączenie. PHP z natury nie trzyma procesu między żądaniami. Trzeba było albo trzymać sesję w bazie i pilnować sticky routingu, albo utrzymywać SSE, co na współdzielonym hostingu jest walką z wiatrakami.
2026-07-28 usuwa oba te wymagania z poziomu protokołu:
- brak handshake'u — nie ma stanu do odtworzenia na starcie żądania,
- brak
Mcp-Session-Id— nie ma czego trzymać między żądaniami, - elicytacja przez
input_required+requestStatezamiast otwartego strumienia, ttlMsna listach zamiast powiadamiania przez SSE.
Model żądanie–odpowiedź to jest dokładnie to, w czym PHP jest dobre. Nasz tutorial budowania serwera MCP w PHP i WordPressie wymaga aktualizacji kodu, ale sam pomysł właśnie się uprościł, nie skomplikował.
Podobnie po stronie Go: bramka opisana w serii traci potrzebę deep packet inspection. Timeouty i circuit breaker zostają — bo backend nadal potrafi paść — ale routing schodzi do poziomu nagłówka.
Co się dezaktualizuje w serii „MCP na części pierwsze"
Uczciwie: kilka artykułów w tej serii opisuje świat sprzed 28 lipca. Zanim je poprawimy, tak wygląda mapa.
| Artykuł | Status |
|---|---|
| Trzy role — host, klient, serwer | Role bez zmian. Opis cyklu życia połączenia — do przepisania. |
| Trzy prymitywy: Resources, Tools, Prompts | Trzy prymitywy zostają. Do dopisania: pełne JSON Schema 2020-12 i deprecacja Roots. |
| JSON-RPC pod spodem | Pierwsza ramka na drucie nie jest już initialize. Do poprawki także kod -32002. |
| Transport: stdio, SSE i Streamable HTTP | Najmocniej dotknięty. Sesja, nagłówki i rola SSE — wszystko się przesunęło. |
| OAuth i autoryzacja | Fundament aktualny, dochodzi sześć SEP-ów utwardzenia. |
| Jak zbudować serwer MCP w PHP | Kod do aktualizacji, architektura się upraszcza. |
| MCP Apps / MCP-UI | Z propozycji na oficjalne rozszerzenie. |
| Mapa protokołów agentowych | Dochodzi warstwa rozszerzeń jako osobny wymiar mapy. |
Checklista migracyjna
Jeśli masz serwer MCP w produkcji, przejdź to po kolei:
- Usuń obsługę
initialize/initializedi przestań wydawaćMcp-Session-Id. - Czytaj
_meta— wersja protokołu, dane i capabilities klienta są tam przy każdym żądaniu. - Zaimplementuj
server/discover, jeśli klienci potrzebują capabilities z góry. - Znajdź stan sesyjny i zamień go na jawne uchwyty w sygnaturach narzędzi.
- Wymuś
Mcp-MethodiMcp-Namei odrzucaj żądania, gdzie nagłówek kłóci się z ciałem. - Dodaj
ttlMsicacheScopedo wyników list i odczytów zasobów. - Przepisz elicytację na
input_required+requestState. - Zmigruj Tasks na nowy cykl życia;
tasks/listjuż nie ma. - Popraw
-32002na-32602wszędzie, gdzie klient matchuje na literał. - Zaplanuj wyjście z Roots, Sampling i Logging — masz co najmniej rok, ale zegar tyka.
- Po stronie klienta: walidacja
iss, deklaracjaapplication_typeprzy DCR.
Punkt 4 jest jedynym, który wymaga myślenia. Reszta to mechanika.
Co z tego wynika szerzej
Zmiana jest głębsza niż lista SEP-ów. MCP przestało być protokołem integracyjnym, a stało się infrastrukturą, na której da się standaryzować — i widać to po tym, czego dotyczą zmiany. Nie przybyło prymitywów ani możliwości. Przybyło polityki deprecacji, conformance suite, wersjonowania rozszerzeń i nagłówków, po których routuje load balancer.
To są rzeczy, które robi się protokołowi wtedy, gdy przestaje być eksperymentem, a zaczyna być czymś, co ludzie wystawiają na produkcję i muszą utrzymać przez lata.
Źródła: ogłoszenie release candidate na blogu Model Context Protocol (David Soria Parra, Den Delimarsky, 21 maja 2026), specyfikacja 2026-07-28 opublikowana 28 lipca 2026, changelog względem 2025-11-25, nota adopcyjna Anthropic z dnia publikacji.
Największa rewizja protokołu od premiery. Serwer, który wcześniej wymagał sticky sessions, teraz jedzie za zwykłym round-robinem.
28 lipca 2026 Model Context Protocol dostał finalną wersję specyfikacji 2026-07-28. Release candidate był zamrożony 21 maja, przez dziesięć tygodni walidowały go zespoły utrzymujące SDK — i wersja finalna wyszła bez poślizgu. Wszystkie cztery SDK Tier 1 miały wsparcie w dniu publikacji.
To nie jest kosmetyka. Poprzednia wersja, 2025-11-25, zakładała że klient i serwer utrzymują sesję: najpierw handshake, potem nagłówek Mcp-Session-Id na każdym kolejnym żądaniu. Nowa specyfikacja usuwa jedno i drugie. Protokół jest bezstanowy, rozszerzenia mają własny cykl życia, autoryzacja dogania to jak OAuth i OIDC są realnie wdrażane, a trzy funkcje z rdzenia trafiły do deprecacji.
Jeśli utrzymujesz serwer MCP w produkcji, ta zmiana dotyczy Cię bezpośrednio. Jeśli dopiero budujesz — właśnie zrobiło się wyraźnie łatwiej.
Przed i po, na drucie
Wywołanie narzędzia w 2025-11-25 zaczynało się od nawiązania sesji:
POST /mcp HTTP/1.1
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-11-25","capabilities":{},
"clientInfo":{"name":"webflux-client","version":"1.0"}}}Serwer odbijał identyfikator sesji, który klient musiał nosić przy każdym następnym żądaniu — i który przypinał go do konkretnej instancji:
POST /mcp HTTP/1.1
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Content-Type: application/json
{"jsonrpc":"2.0","id":2,"method":"tools/call",
"params":{"name":"search_posts","arguments":{"q":"agentic web"}}}W 2026-07-28 to samo wywołanie jest jednym samowystarczalnym żądaniem, które może obsłużyć dowolna instancja:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_posts
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search_posts","arguments":{"q":"agentic web"},
"_meta":{"io.modelcontextprotocol/clientInfo":
{"name":"webflux-client","version":"1.0"}}}}Zwróć uwagę na trzy rzeczy: nie ma initialize, nie ma Mcp-Session-Id, a informacje o kliencie jadą w _meta przy każdym żądaniu.
Handshake i sesja: usunięte
Za wywaleniem handshake'a stoi SEP-2575. Wersja protokołu, dane klienta i jego capabilities — czyli wszystko, co wcześniej wymieniało się raz przy nawiązywaniu połączenia — podróżuje teraz w _meta na każdym żądaniu. Kiedy klient naprawdę potrzebuje poznać możliwości serwera z wyprzedzeniem, jest nowa metoda server/discover.
Nagłówek Mcp-Session-Id i sesja na poziomie protokołu znikają wraz z SEP-2567. Konsekwencja operacyjna jest dokładnie taka, jak brzmi: dowolne żądanie MCP może wylądować na dowolnej instancji serwera. Sticky routing i współdzielony session store, których wcześniej wymagało poziome skalowanie, przestają być potrzebne na poziomie protokołu.
Cały ten ruch to sześć SEP-ów działających razem — domknięcie planu, który maintainerzy opisali w grudniu 2025 w „The Future of MCP Transports".
Protokół bezstanowy ≠ aplikacja bezstanowa
To jest miejsce, w którym najłatwiej wyciągnąć zły wniosek. Usunięcie sesji z protokołu nie oznacza, że Twoja aplikacja musi zapomnieć wszystko między wywołaniami.
Wzorzec, który specyfikacja rekomenduje, jest tym samym, co API HTTP robią od dwudziestu lat: jawny uchwyt. Narzędzie zwraca identyfikator, model przekazuje go z powrotem jako zwykły argument przy kolejnym wywołaniu.
create_draft() → { "draft_id": "d_8812" }
add_section(draft_id="d_8812", heading="Wstęp")
publish(draft_id="d_8812")Maintainerzy argumentują, że to nie jest gorszy substytut stanu sesyjnego, tylko lepszy wariant. Model może komponować uchwyty między narzędziami, rozumować o nich i przekazywać je między krokami — czego stan schowany w metadanych transportu nigdy nie umożliwiał. Stan przestaje być niewidzialny dla modelu.
Praktyczny wniosek dla Ciebie: przejrzyj swoje narzędzia i zapytaj, gdzie polegały na tym, że serwer „pamięta" kontekst. Każde takie miejsce trzeba zamienić na jawny identyfikator w sygnaturze narzędzia.
Serwer pyta klienta bez otwartego SSE
Bezstanowy protokół nadal musi umieć zapytać użytkownika w połowie operacji — choćby o potwierdzenie. Dwa SEP-y przebudowują ten przepływ tak, żeby działał bez trzymanego połączenia.
SEP-2260 zawęża okno: żądania inicjowane przez serwer mogą pojawić się wyłącznie wtedy, gdy serwer aktywnie przetwarza żądanie klienta. Wcześniej było to zalecenie, teraz jest wymóg. Efekt: użytkownik nigdy nie dostaje promptu znikąd, a każda elicytacja daje się prześledzić do czegoś, co sam (albo jego agent) zainicjował.
SEP-2322 wprowadza Multi Round-Trip Requests. Zamiast trzymać otwarty strumień SSE, serwer zwraca wynik typu input_required:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "Opublikować 3 wpisy?",
"schema": { "type": "boolean" }
}
},
"requestState": "eyJzdGVwIjoxfQ=="
}Klient zbiera odpowiedzi i ponawia oryginalne wywołanie z inputResponses oraz odesłanym z powrotem requestState. Ponowienie może obsłużyć dowolna instancja, bo wszystko, czego potrzebuje, jest w payloadzie.
To jest ta zmiana, która sprawia, że elicytacja przestaje wymagać długożyjącego połączenia — i tym samym przestaje być powodem, dla którego nie postawisz serwera na funkcjach serverless.
Routowalne, cache'owalne, śledzalne
Trzy mniejsze zmiany, które najbardziej odczujesz w warstwie operacyjnej.
Nagłówki Mcp-Method i Mcp-Name są teraz wymagane w transporcie Streamable HTTP (SEP-2243). Load balancery, bramki i rate-limitery mogą routować po operacji bez zaglądania do ciała żądania. Serwery odrzucają żądania, w których nagłówki nie zgadzają się z body.
To jest bezpośrednia odpowiedź na problem, który opisywaliśmy przy okazji bramki MCP: dotąd, żeby nałożyć osobny limit na tools/call i osobny na tools/list, trzeba było parsować JSON-RPC w bramce. Teraz to jest routing po nagłówku, czyli konfiguracja nginxa.
Wyniki list i odczytów zasobów niosą ttlMs i cacheScope (SEP-2549), wzorowane na HTTP Cache-Control. Klient wie dokładnie, jak długo odpowiedź tools/list jest świeża i czy wolno ją współdzielić między użytkownikami. Długożyjący strumień SSE przestaje być jedynym sposobem, żeby dowiedzieć się, że lista się zmieniła.
Propagacja W3C Trace Context w _meta jest udokumentowana (SEP-414) — nazwy kluczy traceparent, tracestate i baggagesą przybite w specyfikacji. Trace zaczęty w aplikacji hosta przechodzi przez SDK klienta, serwer MCP i to, co serwer woła dalej, i pojawia się jako jedno drzewo spanów w backendzie zgodnym z OpenTelemetry. Część SDK robiła to już wcześniej — teraz nazwy się zgadzają między implementacjami.
Rozszerzenia stają się pierwszoklasowe
Rozszerzenia istniały już w 2025-11-25, ale nie miały za sobą żadnego formalnego procesu. SEP-2133 to zmienia:
- identyfikowane przez odwrócone DNS-y,
- negocjowane przez mapę
extensionsw capabilities klienta i serwera, - mieszkają we własnych repozytoriach
ext-*z delegowanymi maintainerami, - wersjonują się niezależnie od specyfikacji.
W procesie SEP powstał osobny Extensions Track, dający rozszerzeniom ścieżkę od eksperymentu do statusu oficjalnego. Wraz z wydaniem oficjalne są dwa.
MCP Apps
SEP-1865. Serwery mogą dostarczać interaktywne interfejsy HTML, które host renderuje w sandboksowanym iframe. Narzędzia deklarują swoje szablony UI z wyprzedzeniem, żeby host mógł je prefetchować, cache'ować i przejrzeć pod kątem bezpieczeństwa, zanim cokolwiek się uruchomi. Wyrenderowany interfejs rozmawia z hostem po tym samym JSON-RPC, co reszta MCP — więc każda akcja zainicjowana z UI przechodzi tę samą ścieżkę audytu i zgody, co bezpośrednie wywołanie narzędzia.
Jeśli czytałeś nasz wpis o MCP Apps / MCP-UI — to, co było wtedy propozycją, jest teraz oficjalnym rozszerzeniem z własnym wersjonowaniem.
Tasks
Tasks weszły w 2025-11-25 jako eksperymentalna funkcja rdzenia. Użycie produkcyjne wygenerowało tyle potrzeby przeprojektowania, że właściwym miejscem okazało się rozszerzenie, nie specyfikacja.
Nowy cykl życia jest przekształcony pod model bezstanowy: serwer może odpowiedzieć na tools/call uchwytem zadania, a klient steruje nim przez tasks/get, tasks/update i tasks/cancel. Tworzenie zadania jest sterowane przez serwer — klient ogłasza, że obsługuje rozszerzenie, a serwer decyduje, kiedy wywołanie ma pobiec jako zadanie. tasks/list zostało usunięte, bo bez sesji nie da się go bezpiecznie ograniczyć zakresem.
Kto wdrożył eksperymentalne API Tasks z 2025-11-25, musi zmigrować.
Autoryzacja: sześć SEP-ów utwardzenia
Cel to zbliżenie specyfikacji do tego, jak OAuth 2.0 i OpenID Connect są realnie wdrażane.
| SEP | Co wnosi |
|---|---|
| SEP-2468 | Klient musi walidować parametr iss w odpowiedziach autoryzacyjnych zgodnie z RFC 9207 — tania mitygacja klasy ataków mix-up, szczególnie istotna przy MCP-owym wzorcu „jeden klient, wiele serwerów". W przyszłej wersji klienci będą musieli odrzucać odpowiedzi bez iss. |
| SEP-837 | Klient deklaruje application_type z OIDC przy Dynamic Client Registration. Rozwiązuje typowy przypadek, w którym serwer autoryzacyjny domyślnie traktuje klienta desktopowego albo CLI jako "web" i odrzuca jego redirect URI na localhost. |
| SEP-2352 | Klient wiąże zarejestrowane poświadczenia z issuer wydającego serwera autoryzacyjnego i rejestruje się ponownie, gdy zasób migruje między serwerami. |
| SEP-2207 | Dokumentuje, jak prosić o refresh tokeny u serwerów w stylu OIDC. |
| SEP-2350 | Doprecyzowuje akumulację scope'ów przy step-upie. |
| SEP-2351 | Doprecyzowuje sufiks discovery .well-known. |
Praktycznie: jeśli prowadzisz serwer autoryzacyjny i jeszcze nie zwracasz iss, zacznij teraz. Jeśli piszesz klienta — walidacja iss to kilka linijek, które warto dopisać przed terminem.
Roots, Sampling i Logging: deprecated
Trzy funkcje rdzenia trafiły do deprecacji pod nową polityką cyklu życia (SEP-2577):
| Funkcja | Zamiennik |
|---|---|
| Roots | Parametry narzędzi, URI zasobów albo konfiguracja serwera |
| Sampling | Bezpośrednia integracja z API dostawcy LLM |
| Logging | stderr przy transporcie stdio; OpenTelemetry dla obserwowalności strukturalnej |
To są deprecacje wyłącznie w warstwie adnotacji. Metody, typy i flagi capabilities działają dalej w tym wydaniu i w każdej wersji specyfikacji opublikowanej w ciągu roku od niego. Usunięcie któregokolwiek będzie wymagało osobnego SEP-a pod polityką cyklu życia.
Innymi słowy: nic Ci się dziś nie wywali, ale masz jasny sygnał, w którą stronę planować.
JSON Schema 2020-12 i jedna zmiana kodu błędu
inputSchema i outputSchema narzędzi zostały podniesione do pełnego JSON Schema 2020-12 (SEP-2106). Schematy wejściowe zachowują ograniczenie type: "object" w korzeniu, ale dopuszczają teraz kompozycję (oneOf, anyOf, allOf), warunki i referencje ($ref, $defs). Schematy wyjściowe są bez ograniczeń, a structuredContent może być dowolną wartością JSON, nie tylko obiektem.
Dwa zastrzeżenia implementacyjne: nie wolno automatycznie rozwiązywać zewnętrznych URI w $ref, i należy ograniczać głębokość schematu oraz czas walidacji.
Osobno: kod błędu dla brakującego zasobu zmienia się z MCP-owego -32002 na standardowy JSON-RPC -32602Invalid Params (SEP-2164). Jeśli Twój klient matchuje na literał -32002, popraw to. To jest dokładnie ten typ zmiany, który przechodzi testy i wywala się w produkcji.
Jak protokół będzie się zmieniał dalej
To wydanie zawiera breaking changes i maintainerzy wprost piszą, że nie ma to być normą. Trzy SEP-y governance mają sprawić, że kolejne rewizje nie będą już łamać rdzenia:
- Polityka cyklu życia funkcji — każda funkcja ma stany Active, Deprecated, Removed, z minimum dwunastoma miesiącami między deprecacją a najwcześniejszym możliwym usunięciem.
- Framework rozszerzeń — nowe możliwości mogą wychodzić jako opt-in i stabilizować się tam, zanim (o ile w ogóle) trafią do specyfikacji.
- SEP-2484 — SEP ze ścieżki Standards Track nie może osiągnąć statusu Final, dopóki pasujący scenariusz nie wyląduje w conformance suite. To ta sama suite, według której punktowany jest system poziomów SDK.
Co to zmienia dla WordPressa i PHP
Tu jest realna dobra wiadomość dla naszej publiczności, i warto ją powiedzieć wprost.
Największą przeszkodą w hostowaniu serwera MCP na zwykłym stacku PHP było to, że protokół zakładał stan i długożyjące połączenie. PHP z natury nie trzyma procesu między żądaniami. Trzeba było albo trzymać sesję w bazie i pilnować sticky routingu, albo utrzymywać SSE, co na współdzielonym hostingu jest walką z wiatrakami.
2026-07-28 usuwa oba te wymagania z poziomu protokołu:
- brak handshake'u — nie ma stanu do odtworzenia na starcie żądania,
- brak
Mcp-Session-Id— nie ma czego trzymać między żądaniami, - elicytacja przez
input_required+requestStatezamiast otwartego strumienia, ttlMsna listach zamiast powiadamiania przez SSE.
Model żądanie–odpowiedź to jest dokładnie to, w czym PHP jest dobre. Nasz tutorial budowania serwera MCP w PHP i WordPressie wymaga aktualizacji kodu, ale sam pomysł właśnie się uprościł, nie skomplikował.
Podobnie po stronie Go: bramka opisana w serii traci potrzebę deep packet inspection. Timeouty i circuit breaker zostają — bo backend nadal potrafi paść — ale routing schodzi do poziomu nagłówka.
Co się dezaktualizuje w serii „MCP na części pierwsze"
Uczciwie: kilka artykułów w tej serii opisuje świat sprzed 28 lipca. Zanim je poprawimy, tak wygląda mapa.
| Artykuł | Status |
|---|---|
| Trzy role — host, klient, serwer | Role bez zmian. Opis cyklu życia połączenia — do przepisania. |
| Trzy prymitywy: Resources, Tools, Prompts | Trzy prymitywy zostają. Do dopisania: pełne JSON Schema 2020-12 i deprecacja Roots. |
| JSON-RPC pod spodem | Pierwsza ramka na drucie nie jest już initialize. Do poprawki także kod -32002. |
| Transport: stdio, SSE i Streamable HTTP | Najmocniej dotknięty. Sesja, nagłówki i rola SSE — wszystko się przesunęło. |
| OAuth i autoryzacja | Fundament aktualny, dochodzi sześć SEP-ów utwardzenia. |
| Jak zbudować serwer MCP w PHP | Kod do aktualizacji, architektura się upraszcza. |
| MCP Apps / MCP-UI | Z propozycji na oficjalne rozszerzenie. |
| Mapa protokołów agentowych | Dochodzi warstwa rozszerzeń jako osobny wymiar mapy. |
Checklista migracyjna
Jeśli masz serwer MCP w produkcji, przejdź to po kolei:
- Usuń obsługę
initialize/initializedi przestań wydawaćMcp-Session-Id. - Czytaj
_meta— wersja protokołu, dane i capabilities klienta są tam przy każdym żądaniu. - Zaimplementuj
server/discover, jeśli klienci potrzebują capabilities z góry. - Znajdź stan sesyjny i zamień go na jawne uchwyty w sygnaturach narzędzi.
- Wymuś
Mcp-MethodiMcp-Namei odrzucaj żądania, gdzie nagłówek kłóci się z ciałem. - Dodaj
ttlMsicacheScopedo wyników list i odczytów zasobów. - Przepisz elicytację na
input_required+requestState. - Zmigruj Tasks na nowy cykl życia;
tasks/listjuż nie ma. - Popraw
-32002na-32602wszędzie, gdzie klient matchuje na literał. - Zaplanuj wyjście z Roots, Sampling i Logging — masz co najmniej rok, ale zegar tyka.
- Po stronie klienta: walidacja
iss, deklaracjaapplication_typeprzy DCR.
Punkt 4 jest jedynym, który wymaga myślenia. Reszta to mechanika.
Co z tego wynika szerzej
Zmiana jest głębsza niż lista SEP-ów. MCP przestało być protokołem integracyjnym, a stało się infrastrukturą, na której da się standaryzować — i widać to po tym, czego dotyczą zmiany. Nie przybyło prymitywów ani możliwości. Przybyło polityki deprecacji, conformance suite, wersjonowania rozszerzeń i nagłówków, po których routuje load balancer.
To są rzeczy, które robi się protokołowi wtedy, gdy przestaje być eksperymentem, a zaczyna być czymś, co ludzie wystawiają na produkcję i muszą utrzymać przez lata.
Źródła: ogłoszenie release candidate na blogu Model Context Protocol (David Soria Parra, Den Delimarsky, 21 maja 2026), specyfikacja 2026-07-28 opublikowana 28 lipca 2026, changelog względem 2025-11-25, nota adopcyjna Anthropic z dnia publikacji.
