Znika nagłówek, wokół którego zbudowano wiele zdalnych integracji. 28 lipca 2026 wchodzi finalna wersja specyfikacji, po której protokół MCP przestaje pamiętać na swoim poziomie, z kim rozmawia: żadnego powitania na starcie, żadnego identyfikatora sesji, żadnego stanu trzymanego przez sam protokół. Aplikacja nadal może pamiętać, co chce, tylko musi to robić jawnie, po swojemu. Autorzy nazywają tę wersję największą rewizją od uruchomienia protokołu i trudno się z nimi spierać. Dla jednych zespołów oznacza koniec kłopotów z równoważeniem obciążenia, dla innych trochę pracy przy przepisywaniu kodu.
Co dokładnie wypada z protokołu
Zmiany są trzy i każda dotyka innego miejsca. Pierwsza to koniec powitania. Do tej pory klient i serwer zaczynały rozmowę od wymiany initialize i initialized, w której ustalały wersję protokołu i możliwości obu stron. Teraz te informacje jadą w polu _meta przy każdym pojedynczym żądaniu. Serwer nie musi niczego zapamiętywać, bo dostaje komplet danych za każdym razem.
Druga zmiana jest boleśniejsza w praktyce: znika nagłówek Mcp-Session-Id, a razem z nim pojęcie sesji na poziomie protokołu. Trzecia dotyczy sposobu, w jaki serwer dopytuje użytkownika o brakującą informację. Zamiast otwierać strumień zdarzeń i czekać, zwraca teraz odpowiedź typu InputRequiredResult, a klient wraca z uzupełnionymi danymi w kolejnym żądaniu. Klasyczne pytanie i odpowiedź zamiast otwartego kanału.
Sesje kosztowały więcej, niż dawały
Żeby zrozumieć, po co ktoś rozbiera działający mechanizm, trzeba spojrzeć na rachunek za utrzymanie. Serwer, który pamięta stan konkretnej rozmowy, musi dostać każde kolejne żądanie tego samego użytkownika. A to znaczy, że przed nim stoi warstwa, która potrafi rozpoznać, do której instancji skierować ruch.
Koszt takiego układu rośnie razem ze zdalnymi wdrożeniami obsługującymi wielu użytkowników naraz. Rozwiązanie wygodne przy jednej instancji trzeba wtedy rozłożyć na wiele, a każda z nich musi wiedzieć, kto jest kim.
Specyfikacja opisuje to bez ogródek. Zdalny serwer wymagał wcześniej przyklejonych sesji, wspólnego magazynu stanu i głębokiej inspekcji pakietów na bramie. Teraz może stać za zwykłym równoważeniem obciążenia w trybie karuzeli, bo każda instancja obsłuży każde żądanie. Sam protokół niczego nie pamięta, więc nie ma czego pilnować na bramie.
To ta sama logika, którą aplikacje internetowe przerabiały lata temu przy sesjach użytkowników. Dopóki serwer trzyma stan, skalowanie w poziomie boli. Kiedy stan wędruje do jawnych uchwytów przekazywanych jako argumenty wywołań, dokładanie kolejnych maszyn przestaje być projektem, a staje się suwakiem. Zmiana nie jest więc kaprysem, tylko rachunkiem, który autorzy protokołu w końcu zapłacili.
Roots, Sampling i Logging z etykietą przejściową
Trzy funkcje, które towarzyszyły protokołowi od początku, zostały oznaczone jako wycofywane. Roots służył do wskazywania serwerowi obszarów, w których wolno mu działać. Sampling pozwalał serwerowi poprosić klienta o wygenerowanie odpowiedzi modelem. Logging odpowiadał za przesyłanie komunikatów diagnostycznych.
Zanim ktokolwiek wpadnie w panikę: to deprecjacja wyłącznie na poziomie adnotacji. Specyfikacja mówi wprost, że metody, typy i flagi możliwości działają dalej w tym wydaniu i w każdej wersji opublikowanej w ciągu roku od niego. Nie ma więc terminu, po którym te funkcje przestają istnieć, a ich ewentualne późniejsze usunięcie wymagałoby osobnej decyzji. Autorzy podpowiadają za to zamienniki: parametry narzędzi albo konfiguracja serwera zamiast Roots, bezpośrednia integracja z API dostawcy modelu zamiast Sampling, standardowe wyjście błędów i OpenTelemetry zamiast Logging.
Warto zauważyć, co łączy tę trójkę. Każda z tych funkcji zakładała, że klient jest bogatym środowiskiem, które potrafi zrobić coś w imieniu serwera. Kierunek nowej wersji jest odwrotny: rdzeń protokołu wymaga od klienta mniej, a to, co bardziej złożone, przenosi się do rozszerzeń albo poza protokół.
W zamian: interfejsy w oknie czatu i rozszerzenia z własnym rytmem
Protokół nie tylko chudnie. Dwa dodatki awansowały do rangi pełnoprawnych elementów, a jeden porządkuje całą przyszłość projektu.
MCP Apps pozwala serwerowi zwrócić gotowy interfejs w HTML, który środowisko po stronie klienta renderuje w izolowanej ramce. Zamiast opisywać użytkownikowi słowami, że ma wybrać jeden z wielu rekordów, serwer podaje listę do kliknięcia. Różnica jest większa, niż się wydaje na pierwszy rzut oka. Protokół i wcześniej przesyłał ustrukturyzowane dane, ale nie miał standardowego sposobu, żeby pokazać człowiekowi interfejs, więc model bywał pośrednikiem tam, gdzie wystarczyłby zwykły przycisk.
Rozszerzenie Tasks, przeprojektowane pod bezstanowy rdzeń, obsługuje z kolei operacje trwające dłużej niż jedno żądanie: import dużego zbioru danych, generowanie raportu, długi eksport. Wcześniej istniały w wersji eksperymentalnej, teraz dostają cykl życia dopasowany do nowej architektury i status pełnoprawnego rozszerzenia. Jeśli śledzisz, jak Anthropic dokłada kolejne konektory MCP do narzędzi kreatywnych, zobaczysz w tym prostą linię: protokół dorasta do tego, że po drugiej stronie siedzi człowiek, a nie tylko model.
Najważniejszy jest jednak framework rozszerzeń. Nowe pomysły dostają identyfikatory w formacie odwróconej domeny, własne repozytoria, wyznaczonych opiekunów i wersjonowanie niezależne od rdzenia. Do tego dochodzi porządkowanie autoryzacji: sześć zmian dopasowuje protokół do standardów OAuth 2.0 i OpenID Connect, w tym walidacja pola iss w odpowiedziach zgodnie z RFC 9207. Wygląda to na drobiazg, dopóki nie przypomnimy sobie, że mówimy o narzędziach, którym oddajemy dostęp do firmowych danych.
Pierwsza Misja AI · Kodożercy
Używasz AI codziennie – ale czy robisz to dobrze?
Kurs Pierwsza Misja AI pokaże Ci techniki promptowania, które naprawdę działają. Praktyczne ćwiczenia z prawdziwym GPT-4, gamifikacja i certyfikat.
Sprawdź program kursu →
Co z tym zrobić, jeśli masz własny serwer
Najczęstsze zetknięcie z tym protokołem w codziennej pracy to dziś Claude Code, dodatki do edytorów kodu albo węzeł w narzędziu automatyzacyjnym. Jeśli tylko z nich korzystasz, warto po prostu śledzić komunikaty producenta i aktualizować narzędzie, gdy pojawi się wersja pod nową specyfikację. Bety zestawów bibliotek dla Pythona, TypeScriptu, Go i C# są dostępne od końca czerwca, więc twórcy narzędzi mieli czas na przygotowania.
Inaczej wygląda to po stronie osób, które utrzymują własny serwer. Tu warto zacząć od dwóch pytań. Czy serwer polega na stanie trzymanym przez protokół pomiędzy żądaniami? Jeśli tak, trzeba go przenieść do jawnych uchwytów przekazywanych w argumentach wywołań. Czy korzysta z Roots, Sampling albo Logging? Jeśli tak, nie musisz się spieszyć, bo z wersji wydanych w ciągu najbliższego roku nie mogą zniknąć, ale spokojna wymiana teraz jest tańsza niż awaryjna później. Do tego drobiazg, który potrafi zająć popołudnie: kod błędu -32002 zmienia się na -32602, a schematy narzędzi mają być zgodne z JSON Schema 2020-12.
Jest jeszcze jeden powód, żeby zajrzeć do tej listy wcześniej niż później. Protokół MCP przestał być ciekawostką dla entuzjastów w momencie, w którym integracje zaczęły sięgać do firmowych systemów: repozytoriów kodu, baz danych, narzędzi do obsługi klienta. Przy takich połączeniach porządkowanie autoryzacji przestaje być formalnością, bo od poprawnego sprawdzenia, kto o co prosi, zależy, czy model dostanie dostęp do czegoś, do czego nie powinien. Zmiany w tej części specyfikacji są nudne w opisie i najważniejsze w skutkach.
Autorzy wyrażają oczekiwanie, że kto dostosuje się do wersji z 28 lipca, ten kolejne rewizje przyjmie bez przepisywania warstwy transportu i cyklu życia. To oczekiwanie, nie gwarancja, ale kierunek jest sensowny. Podobne napięcie widać zresztą w szerszej dyskusji o tym, czy przyszłość należy do gotowych narzędzi automatyzacji, czy do agentów. Standard, który skaluje się na zwykłej infrastrukturze, przesuwa tę dyskusję o krok.
Najczęstsze pytania
Czym właściwie jest protokół MCP?
Model Context Protocol to otwarty standard, który opisuje, jak model sztucznej inteligencji może korzystać z zewnętrznych narzędzi i danych. Zamiast pisać osobną integrację dla każdej pary model plus aplikacja, twórca narzędzia udostępnia jeden serwer MCP, a każdy zgodny klient potrafi z niego skorzystać. Anthropic ogłosił protokół pod koniec 2024 roku i przekazał go do wspólnego rozwoju.
Czy moje obecne serwery przestaną działać 28 lipca?
Nie. Publikacja specyfikacji sama w sobie niczego nie wyłącza, a starsza wersja protokołu nie znika z dnia na dzień. Wycofanie Roots, Sampling i Logging ma charakter adnotacji, a specyfikacja gwarantuje ich działanie w każdej wersji wydanej w ciągu roku. Poważniejsza jest zmiana w warstwie transportu i cyklu życia, ale i tu wiele zależy od tego, które wersje obsługuje konkretny klient. Opis bet bibliotek zapowiada, że nowe klienty potrafią wrócić do starego powitania, kiedy trafią na serwer zgodny z poprzednią specyfikacją.
Podsumowanie
Protokół MCP przechodzi zmianę, którą prędzej czy później przechodzi każdy standard z ambicjami. Przestaje być wygodny dla twórcy, a zaczyna być wygodny dla tego, kto go utrzymuje na produkcji. Na poziomie protokołu znikają sesje, powitanie na starcie i strumień zdarzeń przy dopytywaniu użytkownika. Trzy stare funkcje zostają wycofywane wyłącznie adnotacyjnie i nie mogą zniknąć z wersji wydanych w ciągu najbliższego roku. W zamian pojawiają się interfejsy renderowane po stronie klienta, zadania długo działające i porządny system rozszerzeń.
Osoby korzystające z gotowych narzędzi odczują to głównie jako kolejną aktualizację. Osoby utrzymujące własne serwery mają konkretną listę rzeczy do sprawdzenia: stan trzymany dotąd przez protokół, trzy wycofywane funkcje, kod błędu i schematy narzędzi. Finalna specyfikacja publikuje się 28 lipca 2026.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
