MCP rośnie: co zespoły produkcyjne muszą zaplanować w nowych specyfikacjach
Jak rewizja protokołu kontekstu modelu z dатą 2026-07-28 zmienia skalowanie, zadania, uprawnienia i buforowanie, oraz jak migrować istniejący serwer w bezpiecznych etapach.
Źródła: **MCP Grows Up: Six Changes Production Teams Need to Plan For**
Wersja aktualizacji większa niż zwykłe ulepszenie
Zgodnie z komunikatem o wydaniu projektu, Model Context Protocol opublikował swoją największą aktualizację od momentu uruchomienia 28 lipca 2026 roku. Specyfikacja eliminuje sesje protokołowe, formalizuje rozszerzenia, dodaje możliwość wykonywania zadań asynchronicznych o długotrwałym czasie trwania, zaostrza zasady autoryzacji i zapewnia implementatorom rzeczywistą politykę wycofywania funkcji. Kandydat na ostateczną wersję był zamrożony od 21 maja, co dało utrzymywaczom SDK, deweloperom klientów oraz operatorom serwerów około dziesięciu tygodni na przetestowanie nowej architektury.
W całości dokument ten zapewnia bezstanową strukturę główną, możliwość wysyłania wielokrotnych żądań, routowanie przez nagłówki, mechanizmy odkrywania i przechowywania w pamięci cache wyników, framework do tworzenia rozszerzeń, funkcje typu Tasks i MCP Apps, bardziej rygorystyczne zasady autoryzacji oraz niezawodny proces stopniowego wycofywania funkcji.
„Stateless MCP” to ciekawy tytuł, ale lista zmian jest dłuższa. Poniżej kryją się kilka istotnych zmian, które mogą wpłynąć na funkcjonowanie aplikacji. Wyniki otrzymują pole resultType. Usunięto strumień HTTP GET. Funkcja subscriptions/listen zastępuje starsze sposoby subskrypcji. Strumienie SSE tracą możliwość kontynuacji odtwarzania dzięki polu Last-Event-ID. Wyniki z listy oraz zasobów muszą zawierać wskazówki dotyczące pamięci podręcznej. Schematy narzędzi mogą korzystać z pełnej specyfikacji JSON Schema 2020-12. Wreszcie, brakujący zasób teraz zwraca standardowy kod JSON-RPC -32602, podczas gdy wcześniej zwracał -32002.
Traktowanie tego jako zwykłej aktualizacji zależności i ponownego wdrożenia byłoby błędem. To migracja architektury.
1. Protokół bez stanu nie czyni aplikacji bezstanową
W wcześniejszych wersjach kontekst był ustalany za pomocą procedury initialize/initialized. W przypadku zdalnych serwerów HTTP serwer mógł również przekazać Mcp-Session-Id, który klient powtarzał w późniejszych żądaniach. Dzięki temu klient był powiązany z jedną sesją serwera, a w rzeczywistych implementacjach często stosowano „przyklejone” routowanie w balanserze obciążeń, wspólny magazyn sesji lub oba te rozwiązania jednocześnie.
Od 2026-07-28 zarówno procedura nawiązywania połączenia, jak i sesja protokołu znikają. Każde żądanie zawiera w polu _meta informacje o wersji protokołu, możliwościach klienta oraz opcjonalną tożsamość klienta. Serwery muszą implementować funkcję server/discover, chociaż klienci nie muszą jej wywoływać przed każdą operacją. Klient może zamiast tego wysłać swoją preferowaną wersję i spróbować ponownie, jeśli otrzyma błąd UnsupportedProtocolVersionError.
Przez Streamable HTTP aktualna prośba przekazuje metadane w następujący sposób:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Ta sama wersja, metoda i nazwa pojawiają się również w ciele JSON-RPC. Ciało to pozostaje autorytatywne, a serwery muszą odrzucić wszelkie niezgodności pomiędzy nagłówkami a ciałem. Dzięki temu brama nie może zatwierdzić ani skierować żadnej operacji, podczas gdy serwer wykonywa inna.
„Bezstanowość” nie oznacza „nie przechowywanie niczego”
Specyfikacja nie eliminuje stanu aplikacji; po prostu przestaje go ukrywać. Gdy serwer potrzebuje ciągłości pomiędzy jednym wywołaniem a drugim, powinien utworzyć identyfikator domeny, na przykład workspace_id, browser_id, basket_id, analysis_run_id lub deployment_id. Klient lub model dostarcza go następnie jako zwykły argument narzędzia w kolejnych wywołaniach:
create_workspace()
→ { "workspace_id": "ws_7f3..." }
add_file(workspace_id="ws_7f3...", ...)
→ ...
run_analysis(workspace_id="ws_7f3...")
→ ...
To jest czystsze niż ukryty stan transportu, ale nakłada na aplikację nowe obowiązki. Musi obsługiwać weryfikację prawa własności, izolację użytkowników, terminy ważności, zasady przechowywania danych, autoryzację oraz ochronę przed odgadnięciem lub ponownym wysłaniem danych. Pracy trwające może nadal wymagać bazy danych lub rozproszonego cache’a, a zadania długotrwałe z definicji potrzebują trwałego przechowywania. Infrastruktura może być bezstanowa, podczas gdy produkt pozostaje stanowy.
2. Gdzie bezstanowość naprawdę się opłaca
Zwykłe skalowanie poziome
Gdy żądanie zawiera cały swój własny kontekst, serwer może znajdować się za standardowym równoważnikiem obciążenia typu round-robin. W Kubernetes zazwyczaj wystarczają zwykłe Deployment i Service, bez adnotacji dotyczących powiązań sesji ani StatefulSet przeznaczonych wyłącznie do obsługi sesji MCP. Szczególnie korzystne jest tu automatyczne skalowanie – nowy pod nie musi odbudowywać sesji protokołowych przed przyjęciem ruchu, a pod zastąpiony podczas rolling deployment nie pozostawia klientów przy niesprawnej sesji.
Istnieje jednak jeden problem: jeśli aplikacja serwera obsługuje obiekty typu handles lub Tasks, obiekty te nadal przechowywane są w zewnętrznym, trwałym magazynie, gdy muszą przetrwać utratę procesu lub poda.
Łączenie i polityki w bramie
Ponieważ Mcp-Method i Mcp-Name to zwykłe nagłówki, bramka może kierować ruchem, mierzyć jego ilość oraz egzekwować zasady bez konieczności analizowania treści w formacie JSON. W usłudze wielu użytkowników to umożliwia ustalanie oddzielnych kwot dla tools/list, kosztownych narzędzi wyszukiwania, narzędzi do wdrażania oraz wszelkich elementów mogących powodować szkody:
tools/list → high request allowance
tools/call + search → standard allowance
tools/call + deploy_prod → lower rate limit and stronger policy
resources/read → data-volume quota
Brama nie powinna również nigdy czytać pola clientInfo jako dowodu na to, kto wykonał żądanie. Pole to jest samodeklarowane i służy do wyświetlania informacji, debugowania oraz rejestracji zdarzeń. Tożsamość użytkownika musi być ustalana na podstawie zweryfikowanego tokena lub innego zaufanego źródła.
Kasowanie z pamięci
Odpowiedzi na żądania resources/read, resources/templates/list, resources/list, prompts/list, tools/list oraz server/discover zawierają dwa nowe pola: ttlMs i cacheScope. Pierwsze służy jako wskazówka dotycząca aktualności danych, a nie interwału sprawdzania. Drugie określa, czy wynik jest publiczny, czy prywatny. Wszystko, co zmienia się w zależności od użytkownika, konta, zakresu lub uprawnień, nie powinno być traktowane jako dane publiczne dostępne dla wszystkich, a powiadomienia o zmianach mogą unieważnić wynik, który w przeciwnym razie byłby aktualny.
Kasowanie z pamięci tymczasowej zmniejsza liczba powtarzających się żądań katalogu narzędzi i stabilizuje dane wejściowe do modeli. Niewłaściwy wybór zakresu może również prowadzić do nowej grupy błędów związanych z poprawnością i prywatnością.
Obserwowalność
Dokumentacja specyfikacji opisuje propagację kontekstu śledzenia W3C za pomocą kluczy _meta traceparent, tracestate oraz baggage. Host, klient MCP, brama, serwer oraz usługi poniżej w łańcuchu przekazywania danych dzielą się w ten sposób jednym sposobem na powiązywanie wywołań narzędzi w całej ścieżce wykonania. Kontekst śledzenia ułatwia to powiązywanie, ale nie stanowi mechanizmu autoryzacji ani gwarancji integralności, a dane wrażliwe, tokeny, surowe dane wejściowe oraz informacje osobiste nie powinny znajdować się w elemencie baggage.
3. Rozszerzenia stają się koncepcją pierwszej klasy
Każda rozszerzenie ma teraz identyfikator, zasady negocjacji, wyznaczonych administratorów, własny repozytorium oraz własny cykl wypuszczania wersji. Klienci deklarują rozszerzenia, którymi się posługują, w informacjach o możliwościach wysyłanych z każdym żądaniem, natomiast serwery ogłaszają swoje rozszerzenia za pomocą server/discover. Rozszerzenie wchodzi w życie dopiero wtedy, gdy obie strony je obsługują; jeśli druga strona go nie ma, implementacja musi powrócić do podstawowego zachowania lub odpowiedzieć odpowiednim błędem.
To duży krok w rozwoju protokołu, ponieważ nowe funkcje nie muszą już czekać na pełną wersję jądra. Tworzy to również macierz kompatybilności. Serwer nie może zakładać, że każdy host obsługuje Tasks, MCP Apps, Enterprise-Managed Authorization czy jakiekolwiek przyszłe rozszerzenia, dlatego kod produkcyjny wymaga wyraźnych rozwiązań awaryjnych:
- Narzędzie, które obsługuje zadania, oferuje również synchroniczną ścieżkę dla klientów, które nie reklamują zadań, lub zwraca wyraźny błąd dotyczący braku obsługi danej funkcji.
- Narzędzie oparte na aplikacji MCP zwraca przydatną, ustrukturyzowaną lub tekstową treść, gdy host nie może wyświetlić swojego interfejsu.
- Uprawnienia typu enterprise są stosowane tylko wtedy, gdy na to pozwala polityka organizacyjna.
- Pola specyficzne dla rozszerzeń nigdy nie trafiają do klienta, który ich nie uzgodnił.
Rozszerzenia zmniejszają powiązanie z podstawowymi specyfikacjami i zwiększają ryzyko fragmentacji ekosystemu.
4. Zadania sprawiają, że narzędzia działające przez długi czas są bardziej odporne
Zadania przechodzą z eksperymentalnej części głównej do oficjalnego rozszerzenia, io.modelcontextprotocol/tasks. Jeśli klient zgłasza, że obsługuje zadania, serwer może odpowiedzieć zwykłą operacją, w której zamiast ostatecznego wyniku znajduje się identyfikator zadania. Następnie klient używa tasks/get, aby odczytać aktualny stan, tasks/update, aby dostarczyć wymagane dane wejściowe, oraz tasks/cancel, aby poprosić o anulowanie.
Zadanie przechodzi przez stany working, input_required, completed, failed i cancelled. Serwer musi zachować informacje o zadaniu przed zwróceniem jego identyfikatora. Proces anulowania jest oparty na współpracy, więc potwierdzenie żądania nie gwarantuje natychmiastowego zatrzymania wykonywanych działań.
Prawdziwymi kandydatami są zestawy testowe, pipeline’y budowania, generowanie kodu, wdrożenia w chmurze, import danych, przetwarzanie dokumentów, kroki wymagające zatwierdzenia przez człowieka, zadania zbiorcze oraz proste otoczenia dla zewnętrznych interfejsów API. To, co faktycznie otrzymujemy, to nie tyle wykonywanie zadań asynchronicznie, co możliwość odzyskania kontroli: klient może przerwać działanie, uruchomić je ponownie i kontynuować monitorowanie przy użyciu tego samego identyfikatora zadania.
Co musi dodać serwer produkcyjny
Zadania wymagają znacznie więcej niż tylko wątku w tle:
- trwałego repozytorium zadań
- sprawdzania uprawnień za każdym razem, gdy wywoływane są metody
tasks/get,tasks/updatelubtasks/cancel - izolacji właścicieli i użytkowników
- weryfikacji przejść pomiędzy stanami
- przechowywania wyników i błędów
- egzekwowania okresu ważności i usuwania niepotrzebnych danych
- ograniczeń dotyczących częstotliwości monitorowania
- przenoszenia informacji o anulowaniu zadania
- odzyskiwanie po awarii pracownika
- tworzenie zadań idempotentnych
- ochrona przed dublowanymi aktualizacjami
- metryki dotyczące wieku kolejki i zadań utkniętych
Traktuj ID zadania jako identyfikator zasobu, a nie sekret. Posiadanie ID nigdy nie powinno wystarczać do upoważnienia do jakichkolwiek działań.
5. Wielokrotne żądania typu Round-Trip zastępują żądania inicjowane przez serwer
Server bez stanu nie może polegać na trwałym dwukierunkowym połączeniu, aby w dowolnym momencie zadać klientowi pytanie. W takich przypadkach używa się wielokrotnych żądań typu Round-Trip (MRTR). Gdy serwer potrzebuje potwierdzenia, informacji, próbek lub innych danych dostarczonych przez klienta, zwraca obiekt InputRequiredResult. Klient zbiera te dane i ponawia pierwotną operację, używając inputResponses oraz, jeśli dostępne, requestState.
Weźmy przykład narzędzia niszczącego:
delete_resources(resource_ids=[...])
Zamiast otwierać żądanie odwrotne dla istniejącego strumienia, serwer odpowiada:
input_required:
"Confirm deletion of 53 resources"
Klient otrzymuje potwierdzenie i powtarza pierwotną próbę połączenia. Ponowna próba jest samodzielna, więc działa w różnych instancjach, ale oznacza to również, że serwery muszą być zaprojektowane z myślą o takich próbach.
Zasady dla MRTR w środowisku produkcyjnym
- Nie wykonywaj działań nieodwracalnych, dopóki nie masz wszystkich niezbędnych danych wejściowych.
- Uczyń ponowne próby idempotentnymi.
- Powiąż
requestStatez konkretną operacją oraz z osobą, która ją rozpoczęła. - Wygasz stare stany zapytań.
- Odrzucaj odpowiedzi, które odnoszą się do kluczy, o które serwer nigdy nie prosił lub które już otrzymał.
- Ustal górny limit liczby dopuszczalnych rund, aby uniknąć tworzenia pętli.
- Zatwierdzaj operację ponownie przy każdej próbie.
- Nigdy nie zakładaj, że ponowna próba trafi do tej samej instancji.
Gdy proces pracy wymaga szczególnej ostrożności, należy ustawić requestState albo na nieprzejrzysty, losowy identyfikator, przy czym rzeczywiste dane muszą być przechowywane na serwerze, albo na wartość zawierającą kod autoryzacji wiadomości, dzięki czemu można wykryć ingerencje.
6. Aplikacje MCP zmieniają produkt, a nie tylko protokół
Aplikacje MCP umożliwiają serwerowi powiązanie narzędzia z interaktywną interfejsem HTML. Kompatybilne hosty renderują je w zamkniętym iframe. Aplikacja komunikuje się z hostem za pomocą JSON-RPC poprzez postMessage, a host kontroluje, jakie funkcje i narzędzia aplikacja może używać. Dzięki temu możliwe są formularze, panele kontrolne, okna potwierdzeń, odtwarzacze mediów, konfiguratory wdrażania, ekrany triażu oraz inne elementy, których trudno jest opisać wyłącznie tekstowo.
Dla startupu może to zmienić zasady ekonomiczne MVP: interaktywny proces roboczy oparty na rozmowie, bez konieczności najpierw tworzenia oddzielnego interfejsu aplikacji oraz warstwy integracji. Inżynieria frontendu jednak nie znika – zespoły nadal są odpowiedzialne za projekt dostępnego interfejsu, obsługę stanu, konfigurację CSP, kod uruchamiany w środowisku sandbox, walidację danych wejściowych, negocjacje możliwości hosta, bezpieczną obsługę wywołań narzędzi, testy kompatybilności na różnych klientach oraz rozwiązania awaryjne dla hostów bez wsparcia aplikacji. Ponieważ aplikacje są opcjonalną rozszerzeniem, wsparcie hostów jest zróżnicowane, więc serwer powinien zwracać sensowny, zstrukturyzowany treść nawet wtedy, gdy nie można wyświetlić widoku.
7. Uproszczenie procesu autoryzacji staje się coraz trudniejsze
Zgodnie z zasadami autoryzacji HTTP, zabezpieczony serwer MCP pełni rolę serwera zasobu OAuth, a klient MCP rolę klienta OAuth. Ta wersja czerpie elementy z standardu OAuth 2.1 oraz powiązanych standardów. Serwery muszą publikować metadane zabezpieczonych zasobów, aby klienci mogli je znaleźć, przy czym akceptowane są zarówno metadane serwerów autoryzacji OAuth, jak i OpenID Connect. PKCE jest obowiązkowe, podobnie jak wskaźniki zasobów w żądaniach autoryzacji i tokenów, a weryfikacja emitenta jest bardziej rygorystyczna. Najważniejsze zasady to:
- Klienci wysyłają parametr
resourcez nazwą zamierzonego serwera MCP. - Serwer sprawdza, czy token otrzymany został wydany dla jego własnej grupy odbiorców.
- Serwery autoryzacji powinny zawierać pole
iss, a klienci sprawdzają emitenta, jeśli jest ono obecne, przed użyciem kodu autoryzacji.
Authorization, a nigdy w ciągu zapytania.S256.Wskaźniki zasobów ograniczają grupę odbiorców tokenu. Nie powinny być określane jako związanie tokenu kryptograficznego.
Tożsamość korporacyjna to odrębna kwestia
Podstawowa autorizacja MCP obejmuje standardowy przepływ OAuth delegowany przez użytkownika. Centralizowana polityka dostępu korporacyjnego pochodzi z opcjonalnego rozszerzenia Enterprise-Managed Authorization, które umożliwia dostawcy tożsamości organizacji kontrolowanie dostępu do serwerów MCP, obejmując procesy włączania i wyłączania użytkowników, dostęp warunkowy oraz jego egzekwowanie. Klient, system autorizacji serwera oraz środowisko tożsamości korporacyjnej muszą wszystkie je wspierać. W celu przeglądu bezpieczeństwa architektura jest podzielona w następujący sposób:
Core authorization
OAuth flow
issuer validation
resource/audience validation
scopes and step-up
Protected Resource Metadata
Optional enterprise extension
corporate IdP policy
SSO
centralized approval and revocation
identity-assertion exchange
Specyfikacja wyjaśnia architekturę, ale nie upraszcza operacyjnie mechanizmów OAuth. Pobieranie metadanych klienta rodzi problemy związane z SSRF oraz polityką zaufania. Tokeny i dane do odnowienia wymagają bezpiecznego przechowywania. W przypadku implementacji z wieloma wydawcami konieczne jest oddzielne rejestrowanie oraz zarządzanie stanem tokenów. Metadane, adresy URI do przekierowań, zakresy oraz kanoniczne identyfikatory zasobów muszą pozostać spójne.
8. Rzeczywista polityka deprecjacji
Funkcje mają obecnie trzy stany: Aktywne, Zdeprecjonowane i Usunięte. Podstawowa funkcja zazwyczaj pozostaje w stanie Zdeprecjonowany przez co najmniej dwanaście miesięcy, zanim może zostać usunięta, a deprecjacja wymaga udokumentowanej ścieżki migracji oraz wpisu w centralnym rejestrze. Usunięcie może nastąpić później niż w najwcześniejszym terminie. Istnieje przyspieszona ścieżka dla aktywnych zagrożeń bezpieczeństwa, ale nawet ona zwykle wymaga co najmniej 90 dni.
HTTP+SSE, starszy mechanizm transmisji, ma własną zasadę przejścia i może zostać usunięty wcześniej niż inne niedawno uznane za przestarzałe funkcje. Wszyscy, którzy nadal go używają, powinni najpierw zaplanować przeniesienie na Streamable HTTP. Należy również pamiętać, że zasada dwunastomiesięcznego okresu dotyczy wyłącznie funkcji protokołu; API SDK mają odrębne zasady wsparcia i harmonogramy, które mogą się różnić.
Jak to wygląda w rzeczywistych aplikacjach
Narzędzia wewnętrzne dla przedsiębiorstw
Wyobraźmy sobie firmę, która publikuje wiedzę wewnętrzną, informacje z Jira i Confluence, katalogi usług oraz instrukcje obsługi za pośrednictwem MCP. W starym modelu zdalne wdrażanie mogło polegać na zachowaniu sesji, dzięki czemu jeden pracownik zawsze trafiał do tej samej instancji. Od daty 2026-07-28 warstwa MCP może składać się z zestawu bezstanowych kontenerów za zwykłą usługą Kubernetes i balansem obciążeń:
MCP host
↓
API gateway / authorization
↓
Stateless MCP Deployment
├─ Knowledge connector
├─ Jira connector
├─ Confluence connector
└─ Service catalog connector
↓
OpenTelemetry backend
Autoryzacja codzienna może opierać się na podstawowym OAuth, natomiast rozszerzenie Enterprise-Managed Authorization zostaje użyte wtedy, gdy potrzebna jest centralna polityka IdP. Głównym ograniczeniem jest liczba klientów, które faktycznie obsługują to rozszerzenie.
Multi-tenant SaaS
Załóżmy, że dostawca narzędzi deweloperskich sprzedaje MCP jako płatną API setkom lub tysiącom użytkowników. Brak stanu umożliwia prostą routę między różnymi strefami, a bramka może mierzyć zużycie według Mcp-Method i Mcp-Name, przy czym informacje o użytkowniku pochodzą z zweryfikowanych uprawnień, a nie z nazw lub nagłówków wysyłanych przez klienta. Dobrze zaprojektowana implementacja powinna dzielić identyfikatory i zadania według użytkowników, oznaczać katalogi specyficzne dla użytkownika jako cacheScope: „private”, porównywać każdy nagłówek z treścią, ograniczać wykorzystanie kosztownych narzędzi ich własnymi limitami, blokować wyszukiwanie zadań pomiędzy użytkownikami oraz unikać przechowywania decyzji dotyczących uprawnień w pamięci lokalnego procesu. Routa uwzględniająca sesję nie istnieje; izolacja użytkowników nadal jest twoim obowiązkiem.
Asystenci do programowania oparte na AI
Server do kodowania może udostępniać funkcje run_tests, build_project, generate_patch lub deploy_preview jako zadania. Natychmiast zwraca identyfikator zadania, umieszcza pracę w kolejce i pozwala agentowi kontynuować czytanie kodu lub przeglądanie innych problemów. Klient sprawdza stan na zalecanym przez serwerze interwale, a gdy jakiś krok wymaga zatwierdzenia, zadanie przechodzi w stan input_required, a klient odpowiada wiadomością tasks/update. Zaletą jest odporność na awarie wynikające z ponownego uruchamiania edytora lub przerw w sieci. Cena to zaawansowany system zarządzania zadaniami: trwała kolejka, umowy najmu pracowników, przechowywanie wyników, możliwość anulowania, izolowane przestrzenie robocze oraz polityka przechowywania danych.
Ochrona zdrowia i usługi finansowe
Wskaźniki zasobów oraz weryfikacja odbiorców zmniejszają prawdopodobieństwo ponownego użycia tokena wydanego dla jednego serwera MCP w innym, a weryfikacja emitenta obniża ryzyko ataków typu OAuth mix-up. W3C Trace Context umożliwia śledzenie żądania wzdłuż ścieżki MCP oraz usług za nią. Razem zapewniają zespołom ds. bezpieczeństwa i zgodności jaśniejszy zestaw mechanizmów kontrolnych, choć nie stanowią kompletnego rozwiązania dotyczącego zgodności. Nadal potrzebna jest autoryzacja wewnątrz aplikacji, niezmienne zdarzenia audytowe, zasady przechowywania i usuwania danych, klasyfikacja danych, obsługa zgód, zarządzanie kluczami, logi dostępu administracyjnego, procedura reagowania na incydenty oraz minimalne dane śledzące. Śledzenie ułatwia diagnozę; nie powinno być jedynym zapisem audytowym.
Startup typu AI-native
Rozważmy mały zespół tworzący narzędzie do zarządzania infrastrukturą. Za pomocą MCP Apps można by dostarczyć formularz planu wdrożenia, panel analityczny z szacunkiem kosztów, interfejs do uzyskiwania zatwierdzeń, monitor wdrożenia oraz mechanizm odwracania zmian. Host zapewnia kontekst rozmowy, serwer dostarcza narzędzia i zasoby interfejsu użytkownika, a aplikacja korzysta z tych narzędzi przez most kontrolowany przez hosta. Odrębny produkt w postaci panelu analitycznego może na początku okazać się niepotrzebny, jednak projekt API, autoryzacja, testowanie interfejsu, dostępność, zasady CSP oraz rozwiązania awaryjne dotyczące kompatybilności pozostają niezbędne.
Gdzie nowa specyfikacja dodaje złożoności
Stan został przeniesiony, nie zniknął. Stan połączenia staje się wyraźnym stanem domeny, co stanowi ulepszenie architektoniczne wymagające starannego zaprojektowania mechanizmów obsługi, przechowywania, terminów ważności, przypisania właściciela oraz zapewnienia idempotencji.
Wersjonowanie SDK oraz wdrożenie nowego protokołu to dwa odrębne projekty. Gdy istniała wersja kandydująca, administratorzy SDK zachęcali zespoły, aby aktualizację głównej wersji SDK traktować oddzielnie od włączania nowego protokołu komunikacji, a ta rada pozostaje aktualna. Weźmy jako przykład SDK TypeScript v2: dzieli ono pojedynczy pakiet na osobne pakiety dla serwera i klienta, jest dostarczane wyłącznie w formacie ESM, działa na Node.js 20+ oraz Bun i Deno, jest weryfikowane za pomocą bibliotek kompatybilnych ze Standard Schema i zawiera kodmod służący do obsługi typowych zmian z wersji v1. Python v2 również wymaga znacznych zmian, między innymi przemianowania FastMCP na MCPServer. TypeScript v1 będzie otrzymywać poprawki i aktualizacje bezpieczeństwa przez co najmniej sześć miesięcy po wprowadzeniu wersji v2, a Python v1 nadal będzie otrzymywać krytyczne poprawki i pliki z aktualizacjami bezpieczeństwa. Ostrożny plan działań:
- Uaktualnij SDK, zachowując wcześniejsze zachowanie protokołu tam, gdzie jest to możliwe.
- Popraw zmiany w API na poziomie aplikacji.
- Dodaj obsługę protokołu z dwóch różnych er.
- Weryfikuj działanie z rzeczywistymi klientami i ruchem sieciowym.
- Stopniowo włączaj nowoczesne, bezstanowe zachowanie.
- Wycofaj obsługę starszych wersji tylko po obserwacji stopnia przyjęcia przez klientów.
Rozszerzenia ograniczają możliwości. Narzędzie nie może zakładać, że zadania lub aplikacje MCP istnieją wszędzie, dlatego zespoły produktowe potrzebują macierzy kompatybilności oraz alternatywnych rozwiązań użytkownika.
Ponawianie prób staje się problemem poprawności. Ścieżki ponawiania prób powstają teraz w wyniku negocjacji wersji protokołu, przerwanych strumieni odpowiedzi HTTP, procedur autoryzacji, monitorowania zadań oraz ponownego łączenia subskrypcji. Dlatego każda operacja z efektami ubocznymi wymaga starannego planu idempotencji.
OAuth współpracuje lepiej, ale nadal wymaga dużo wysiłku. Specyfikacja odnosi się do OAuth 2.1 oraz Dokumentów Metadanych ID Klienta jako do wersji roboczych, więc implementatorzy muszą przestrzegać zarówno zmian w MCP, jak i podstawowych standardów.
Kasowanie z pamięci podręcznej rodzi pytania dotyczące prywatności. Oznaczenie odpowiedzi zależnej od uprawnień jako publicznej mogłoby ujawnić katalog jednego użytkownika lub najemcy innemu. Odpowiednie są konserwatywne domyślne ustawienia: należy używać zakresu prywatnego, chyba że wynik jest rzeczywiście identyczny dla wszystkich żądających.
Ogólna ocena
MCP 2026-07-28 przybliża protokół do sposobu funkcjonowania nowoczesnej sieci: żądania działające samodzielnie, wyraźne wersje, zwykłe routowanie HTTP, rzeczywiste semantyki pamięci podręcznej, śledzenie rozproszone, standardowe uprawnienia oraz opcjonalne funkcje rozwijające się oddzielnie. Prawdziwą korzyścią nie jest brak stanu, lecz brak ukrytego stanu protokołu.
Rozszerzanie skali, kierowanie ruchem między strefami, przywracanie po awariach, ustawianie zasad bramy oraz monitorowanie systemu stają się znacznie prostsze. W zamian pojawia się stan sesji roboczej, który służył do ukrywania takich elementów jak: obsługa aplikacji, właściwości idempotencji, trwałe zadania, alternatywne rozwiązania w przypadku awarii, metadane autoryzacji, prywatność pamięci cache oraz mechanizmy ponawiania prób.
Jeśli zarządzasz już istniejącym serwerem produkcyjnym, przeprowadzaj migrację etapami i obsługuj obie wersje. Traktuj aktualizację SDK oraz protokół komunikacji jako odrębne kroki, eliminuj założenia dotyczące połączeń, przechowuj zadania długotrwałe w wyraźnie zdefiniowanych strukturach, testuj mechanizmy autoryzacji i prób ponownych, a tylko wtedy usuwaj starsze zachowania, gdy zostanie potwierdzone rzeczywiste przyjęcie rozwiązania przez klientów. W przypadku zupełnie nowego serwera jest to łatwiejsze: zacznij od bezstanowych obsługujących żądania i wyraźnie zdefiniowanego stanu, używaj Streamable HTTP oraz aktualnych mechanizmów autoryzacji, dodaj OpenTelemetry, upewnij się, że cacheowanie jest deterministyczne, i od pierwszego dnia planuj negocjacje dotyczące rozszerzeń.
Protokół jest teraz łatwiejszy w obsłudze, ale tylko dla zespołów gotowych dokładnie opisać stan aplikacji, granice bezpieczeństwa oraz zachowanie w przypadku awarii.
Literatura pokrewna
- Praktyczne notatki: MCP 2026: Protokół wyrosł – o tym, co jest AI w produkcji — Szczegółowy przewodnik po praktycznych notatkach: MCP 2026: Protokół wyrosł – o tym, co jest AI w produkcji: umowy, sprawdzania oraz miejsca na kod do wklejenia dla zespołów wdrażających ten model.
- Te serwery MCP, które warto zainstalować najpierw, w kolejności priorytetowej dla programistów — Uporządkowana lista serwerów MCP przeznaczonych do asystentów kodowania AI, od Context7 i GitHub po Postgres i pamięć, wraz z konfiguracjami instalacji i zaleceniami dotyczącymi uprawnień.