Buduj z CometAPIPotrzebujesz jednego API dla wielu modeli?Przetestuj proces w Playground, a potem utwórz klucz API, gdy model i koszt pasują do Twojego zastosowania.
Dowiedz się, jak przeprowadzić migrację do MCP 2026-07-28, w tym bezstanowy transport, MRTR, nagłówki trasowania, buforowanie, zmiany w OAuth oraz aktualizacje SDK.
TL;DR: MCP 2026-07-28 usuwa sesje na poziomie protokołu oraz obowiązkowy handshake inicjalizacyjny. Zespoły produkcyjne powinny wykryć ukryte zależności od sesji, przyjąć metadane protokołu per żądanie, wdrożyć Multi Round-Trip Requests, zaktualizować polityki bram/gatewayów i przeprowadzić kanarkowe wdrożenie nowego protokołu przed wycofaniem zachowań legacy.
Specyfikacja Model Context Protocol wydana 28 lipca 2026 wprowadza największą zmianę architektury MCP od czasu dodania wsparcia dla zdalnego transportu.
Protokół korzysta teraz z bezstanowego rdzenia request–response. Wymiana initialize i notifications/initialized została usunięta, Mcp-Session-Id zniknęło, a każde żądanie niesie informacje protokołowe potrzebne do jego przetworzenia.
Sprawdzone pod kątem przejrzystości, atrybucji źródeł i aktualnej terminologii API.
Wydanie wprowadza także Multi Round-Trip Requests, nagłówki routingu HTTP, keszowalne odpowiedzi list, ostrzejsze zachowanie autoryzacji, framework rozszerzeń oraz formalny cykl wycofywania. Zobacz oficjalny komunikat o wydaniu MCP 2026-07-28 oraz pełny changelog specyfikacji po szczegóły na poziomie protokołu.
Zmiany ułatwiają skalowanie zdalnych serwerów MCP za standardową infrastrukturą HTTP. Nie czynią jednak istniejącej aplikacji automatycznie bezstanową.
Serwer produkcyjny może nadal polegać na pamięciowych workspace’ach, lepkim routingu, poświadczeniach powiązanych z sesją, długo żyjących strumieniach lub interakcjach inicjowanych przez serwer. Ten poradnik koncentruje się na wykrywaniu i zastępowaniu tych zależności.
Czy serwer odrzuca wywołania, dopóki inicjalizacja nie zostanie ukończona?
Czy ID sesji wybiera użytkownika, poświadczenie, workspace lub konwersację?
Czy inna instancja serwera może kontynuować workflow rozpoczęty przez pierwszą?
Czy load balancer wymaga przypinania sesji?
Czy narzędzie wykonuje efekt uboczny przed uzyskaniem potwierdzenia?
Czy gateway parsuje ciało, aby zidentyfikować metodę lub narzędzie?
Czy poświadczenia OAuth są przechowywane bez ich serwera autoryzacji (issuer)?
Czy klient polega na wznawianiu SSE lub ponownym doręczeniu wiadomości?
Czy listy narzędzi lub zasobów różnią się w zależności od połączenia?
Które funkcje zdeprecjonowane wciąż otrzymują ruch produkcyjny?
Nie usuwaj Mcp-Session-Id, dopóki nie zrozumiesz, co aplikacja przechowuje pod nim.
Serwer, który usunie nagłówek, ale zachowa stan w pamięci lokalnej, może działać podczas developmentu i okresowo zawodzić, gdy żądania zostaną rozproszone na wiele instancji.
2. Zastąp ukryty stan sesji
MCP 2026-07-28 usuwa sesje na poziomie protokołu, nie stan aplikacji.
Stan potrzebny między wywołaniami powinien korzystać z jednego z trzech wzorców.
Jawne uchwyty (Explicit Handles)
Zwróć przez narzędzie uchwyt nadany przez serwer i wymagaj go w kolejnych wywołaniach.
Dzięki temu zależność jest widoczna w kontrakcie narzędzia i dowolna zgodna instancja serwera może przetworzyć żądanie.
Współdzielony magazyn (Shared Storage)
Użyj bazy danych, rozproszonego cache, object store lub trwałego systemu zadań, gdy:
wielu workerów potrzebuje tego samego stanu;
workflow musi przetrwać restart;
stan jest zbyt duży dla uchwytu;
workflow trwa dłużej niż pojedyncze żądanie;
wymagana jest transakcyjność lub jednokrotne użycie.
Chronione requestState
MRTR może zwrócić nieprzezroczystą wartość requestState, którą klient odzwierciedla przy ponowieniu oryginalnego żądania.
Ponieważ wartość przechodzi przez klienta, chroń ją za pomocą HMAC lub uwierzytelnionego szyfrowania. Zwiąż ją z uwierzytelnionym podmiotem, oryginalną operacją, ważnymi parametrami, czasem wygaśnięcia oraz nonce, gdy wymagana jest ochrona przed replay.
Nigdy nie ufaj niepodpisanej wartości requestState tylko dlatego, że klient zwrócił ją bez zmian.
3. Przyjmij samowystarczalne żądania i discovery
Nowoczesne żądania MCP zawierają kontekst protokołu w _meta.
Wywołanie narzędzia w Streamable HTTP może wyglądać tak:
Serwery celujące w nowy protokół muszą zaimplementować server/discover, który ogłasza wspierane wersje, możliwości i tożsamość serwera. Klienci mogą wywołać go przed inną operacją lub użyć do określenia, czy wymagana jest ścieżka legacy.
Przeczytaj oficjalną dokumentację server/discover po kontrakt odpowiedzi.
Negocjacja wersji w TypeScript SDK
Sama aktualizacja TypeScript SDK nie przełącza automatycznie klienta na nowy protokół.
zachowanie, gdy klient nie wspiera wymaganej możliwości.
Unikaj finalizowania zakupu, usunięcia, obciążenia kredytów lub zewnętrznego zapisu przed zwróceniem input_required.
Użyj operacji etapowanej lub klucza idempotency, aby ponowienia nie duplikowały działania. Zobacz oficjalną specyfikację MRTR po pełny model interakcji.
5. Zaktualizuj bramy/gatewaye, keszowanie i autoryzację
Zmiany infrastrukturalne są ściśle powiązane i powinny być testowane razem.
Waliduj nagłówki routingu MCP
Żądania POST Streamable HTTP zawierają teraz:
MCP-Protocol-Version
Mcp-Method
Mcp-Name
Te nagłówki pozwalają bramom routować, taryfikować, autoryzować i limitować ruch bez parsowania każdego ciała JSON.
Mogą wspierać kontrole takie jak:
ograniczenia rate limit specyficzne dla narzędzia;
odrębne polityki dla metod listujących i wykonawczych;
dedykowane pule workerów dla kosztownych narzędzi;
ograniczony dostęp do operacji wysokiego ryzyka;
metryki opóźnień i błędów per narzędzie;
przypisywanie kosztów infrastruktury.
Wartości nadal dostarcza klient. Porównuj je z ciałem JSON-RPC przed zastosowaniem polityki.
Żądanie nie może zadeklarować niskiego ryzyka narzędzia w Mcp-Name, a wywołać inne narzędzie w ciele. Niezgodności nagłówek–ciało powinny być odrzucane i logowane.
Używaj kluczy cache świadomych autoryzacji
Nowy protokół dodaje ttlMs i cacheScope do wyników możliwych do keszowania, w tym:
tools/list
prompts/list
resources/list
resources/templates/list
resources/read
Klucz cache zwykle powinien obejmować:
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
Nie używaj prywatnego wpisu cache między użytkownikami lub tenantami tylko dlatego, że TTL nie wygasł.
Deterministyczne sortowanie narzędzi również ma znaczenie. Stabilny katalog unika niepotrzebnych chybionych trafień cache i może poprawić ponowne użycie cache promptu modelu, gdy definicje narzędzi są wstawiane do promptów.
Wzmocnij obsługę issuerów OAuth
Podczas migracji autoryzacji:
waliduj zwróconą wartość iss względem issuer’a zarejestrowanego dla przepływu;
indeksuj przechowywane poświadczenia klienta według issuer’a;
nigdy nie używaj poświadczeń z innym serwerem autoryzacji;
ustaw odpowiedni application_type podczas DCR;
przygotuj nowe integracje na Client ID Metadata Documents.
Dynamic Client Registration pozostaje dostępne dla wstecznej kompatybilności, ale jest deprecated jako preferowane podejście rejestracyjne.
6. Migruj powiadomienia, zadania i funkcje deprecated
Starsza ścieżka powiadomień HTTP GET oraz przepływ resources/subscribe lub resources/unsubscribe zostały zastąpione przez subscriptions/listen.
Klienci otwierają długo żyjący strumień odpowiedzi POST i zapisują się na potrzebne kategorie powiadomień. Powiadomienia o postępie i logi specyficzne dla żądania pozostają dołączone do strumienia odpowiedzi dla opisywanego żądania.
Dla wdrożeń wieloinstancyjnych użyj współdzielonej szyny zdarzeń, gdy powiadomienia wygenerowane na jednej instancji muszą dotrzeć do subskrypcji podłączonej do innej.
Rozszerzenie Tasks
Długo trwające prace zostały przeniesione z eksperymentalnego core protokołu do:
io.modelcontextprotocol/tasks
Rozszerzenie używa:
tasks/get do odpytywania;
tasks/update do aktualizacji od klienta do serwera;
trwałych uchwytów zadań;
subscriptions/listen do subskrybowanych aktualizacji.
Starszych wzorców tasks/result i tasks/list nie należy przenosić do nowej implementacji.
Funkcje deprecated
Następujące funkcje są deprecated:
Funkcja
Zalecany kierunek
MCP 2026-07-28
Działanie migracyjne
Roots
Przekazuj katalogi przez argumenty narzędzi, URI zasobów lub konfigurację
Brak wymaganego handshake
Usuń bramki inicjalizacji dla modern-request
Sampling
Integruj bezpośrednio z API dostawców modeli
Brak sesji na poziomie protokołu
Uczyń wymagany stan jawnym
Logging
Używaj stderr dla stdio lub OpenTelemetry w produkcji
Opcjonalne wywołanie server/discover
Zaimplementuj discovery i negocjację wersji
Dynamic Client Registration
Przejdź w kierunku Client ID Metadata Documents
Dołączone do żądania w _meta
Wysyłaj metadane protokołu per żądanie
Legacy HTTP+SSE
Migruj do Streamable HTTP
Nagłówki Mcp-Method i Mcp-Name
Zaktualizuj routing, polityki i obserwowalność
Deprecated includeContext values
Pomiń pole lub użyj "none"
Multi Round-Trip Requests
Obsługuj input_required i ponowienia
List caching
Katalogi pobierane wielokrotnie
ttlMs, cacheScope, deterministyczne sortowanie
Dodaj autoryzację-świadome keszowanie
Powiadomienia
Strumień GET i subskrypcje zasobów
subscriptions/listen
Przenieś powiadomienia o zmianach na nowy strumień
Autoryzacja
Funkcjonalność deprecated pozostaje dostępna w oknie wycofywania, ale nowe implementacje nie powinny jej adoptować. Polityka cyklu życia MCP zapewnia minimalnie 12 miesięcy okresu deprecjacji; nie oznacza to, że każda funkcja ma tę samą potwierdzoną datę usunięcia.
Nie zmieniaj klientów, serwerów, bram, keszowania i autoryzacji w jednym, nieobserwowanym wydaniu.
Zalecana kolejność migracji
Sporządź inwentaryzację wersji protokołu, SDK, sesji, ruchu SSE, klientów DCR i metod deprecated.
Zaktualizuj SDK w środowiskach nieprodukcyjnych.
Dodaj server/discover i negocjację wersji.
Zastąp ukryte zależności sesji.
Zaimplementuj i zabezpiecz MRTR.
Dodaj walidowane nagłówki routingu i kesze o zasięgu.
Przetestuj granice issuerów w autoryzacji.
Wdrażaj kanarkowo nowy protokół obok ścieżki legacy.
Wycofuj starsze zachowanie dopiero po przeglądzie telemetryki.
Kompatybilność podczas kanarkowego wdrożenia
Modern client + modern server
→ Use MCP 2026-07-28
Modern client + legacy server
→ Probe and fall back when supported
Legacy client + dual-version server
→ Continue on the legacy path
Unsupported combination
→ Return a clear protocol-version error
Wydanie nowej specyfikacji MCP nie jest przełącznikiem dla całego ekosystemu. Klienci, serwery, SDK i platformy hostowane będą migrować w różnym tempie.
Telemetria do rejestrowania
Sygnał
Co ujawnia
Wersja protokołu per żądanie
Adopcję i niekompatybilne kombinacje
Sukces discovery i wskaźnik fallback
Zachowanie negocjacji wersji
Brakujące lub nieprawidłowe nagłówki MCP
Przestarzali klienci lub błędy gatewaya
Niezgodności nagłówek/ciało
Błędy klienta lub próby obejścia polityk
MRTR żądane i zakończone
Niezawodność interaktywnych workflowów
MRTR odrzucone lub wygasłe
Ścieżki błędów użytkownika i klienta
Błędy weryfikacji request-state
Manipulacje, replay lub wygaśnięcie
Zapobieganie duplikacji operacji
Skuteczność kontroli idempotencji
Trafienia cache według scope
Bezpieczną redukcję ruchu
Błędy walidacji issuerów
Problemy z konfiguracją OAuth
Ruch HTTP+SSE
Pozostałą pracę nad migracją transportu
Ruch metod deprecated
Dane do planowania wycofania
Latencja narzędzi i odsetek akceptowanych zadań
Niezawodność widoczna dla użytkownika
Udane jednorazowe wywołania tools/call nie wystarczą do pomiaru migracji. Workflow, który wielokrotnie przekracza czas, prosi o niepotrzebne dane lub duplikuje zewnętrzny zapis, nadal jest porażką produkcyjną.
Jak CometAPI wpisuje się w architekturę MCP
MCP nie zastępuje API modelu. Te dwie warstwy rozwiązują różne problemy integracyjne.
Warstwa
Główna odpowiedzialność
MCP
Łączyć agentów z narzędziami, zasobami, promptami, zgodami i zadaniami
Ujednolicone API modelu
Łączyć aplikacje z modelami, poświadczeniami, użyciem i rozliczaniem
Orkiestracja aplikacji
Decydować, kiedy i jak wywoływać modele i narzędzia
Typowa architektura produkcyjna wygląda tak:
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP standaryzuje sposób, w jaki agenci wchodzą w interakcję z narzędziami i kontekstem. Nie standaryzuje cen modeli, poświadczeń dostawców, endpointów inferencji ani failoveru dostawców.
To rozdzielenie staje się szczególnie użyteczne przy migracji z deprecjonowanej możliwości Sampling. Jeśli serwer MCP lub agent, który go konsumuje, nadal potrzebuje inferencji modelu, aplikacja może wywołać API modelu bezpośrednio zamiast polegać na dawnym przepływie MCP Sampling.
Kiedy pomaga ujednolicona brama modeli
Ujednolicona brama modeli może zmniejszyć prace operacyjne, gdy:
kilka serwerów MCP potrzebuje dostępu do różnych dostawców modeli;
różne narzędzia wymagają różnych modeli;
zespoły chcą zmieniać modele bez przepisywania integracji specyficznych dla dostawcy;
poświadczenia, użycie i rozliczanie muszą być zarządzane centralnie;
dostęp do modeli powinien pozostać niezależny od zmian transportu MCP.
CometAPI dostarcza endpoint kompatybilny z OpenAI, który może służyć jako warstwa dostępu do modeli za aplikacjami MCP. Utrzymuje to logikę dostawców modeli oddzielnie od narzędzi MCP, zasobów i orkiestracji zadań.
Na przykład narzędzie MCP może wywoływać model przez ten sam kompatybilny z OpenAI klient używany w innych miejscach aplikacji:
Serwer MCP pozostaje odpowiedzialny za kontrakt narzędzia, autoryzację, stan i obsługę wyników. Brama modeli obsługuje wybór modeli, dostęp do dostawców i odpowiedzi inferencji.
Utrzymanie tych warstw oddzielnie daje dwie praktyczne korzyści:
Klienci i serwery MCP mogą migrować do nowego protokołu bez zmiany warstwy integracji modeli.
Dostawców modeli można zmieniać bez przeprojektowywania narzędzi MCP lub zachowania transportu.
Zastąp ukryty stan uchwytami lub współdzielonym magazynem.
Zwracaj resultType.
Zastąp żądania serwer→klient mechanizmem MRTR.
Chroń requestState.
Waliduj wszystkie inputResponses.
Dodaj idempotencję dla efektów ubocznych.
Zwracaj deterministyczne listy.
Publikuj konserwatywne wskazówki cache.
Migruj długo trwające prace do rozszerzenia Tasks.
Gateway i infrastruktura
Waliduj nagłówki żądań MCP.
Porównuj nagłówki z ciałem żądania.
Usuń niepotrzebny lepki routing.
Testuj żądania na wielu instancjach.
Partycjonuj cache według granic autoryzacji.
Dodaj współdzieloną szynę powiadomień, gdy wymagane.
Śledź ruch legacy i deprecated.
Utrzymuj ścieżkę rollback podczas kanarkowania.
FAQ
Czym jest MCP 2026-07-28?
MCP 2026-07-28 to specyfikacja Model Context Protocol wydana 28 lipca 2026. Wprowadza bezstanowy rdzeń protokołu, Multi Round-Trip Requests, nagłówki routingu HTTP, keszowalne wyniki, zmiany w autoryzacji, rozszerzenia i formalny cykl wycofywania.
Czy Mcp-Session-Id zostało usunięte?
Tak. Nowy protokół Streamable HTTP nie używa Mcp-Session-Id.
Aplikacje nadal mogą zachowywać stan poprzez jawne uchwyty, współdzielony magazyn, trwałe zadania lub chronione wartości request-state.
Czy handshake inicjalizacji MCP został usunięty?
Tak. Nowoczesne żądania nie wymagają wymiany initialize i notifications/initialized.
Serwery muszą zaimplementować server/discover, choć klienci nie muszą go wywoływać przed każdą operacją.
Czy bezstanowy MCP oznacza, że narzędzia nie mogą zachować stanu?
Nie. Bezstanowość dotyczy warstwy protokołu.
Narzędzie może nadal przechowywać stan, ale przetwarzanie żądań nie powinno zależeć od ukrytej zależności transportu lub jednego konkretnego procesu serwera.
Czym jest MRTR?
Multi Round-Trip Requests pozwala serwerowi poprosić o dodatkowe dane od klienta lub użytkownika bez wysyłania żądania inicjowanego przez serwer przez ciągle otwarte, dwukierunkowe połączenie.
Serwer zwraca input_required, a klient ponawia oryginalną operację z żądanymi odpowiedziami.
Czy HTTP+SSE jest usunięte od razu?
Nie. Jest deprecated, a nie natychmiast usunięte.
Nowe serwery powinny używać Streamable HTTP, a istniejące systemy powinny zmierzyć i migrować pozostały ruch HTTP+SSE.
Czy klienci TypeScript SDK v2 używają MCP 2026-07-28 automatycznie?
Nie. SDK v2 dla TypeScript wymaga jawnej konfiguracji negocjacji wersji, aby użyć nowoczesnego protokołu.
Użyj negocjacji automatycznej, gdy klient musi działać zarówno z nowoczesnymi, jak i legacy serwerami.
Końcowe rekomendacje
MCP 2026-07-28 ułatwia skalowanie, routing, keszowanie i obserwowalność zdalnej infrastruktury MCP. Głównym ryzykiem migracji nie jest tylko usunięcie nagłówka czy handshake’u. To ukryty stan aplikacji i logika interakcji, które mogą nadal od nich zależeć.
Przed wdrożeniem nowego protokołu:
Znajdź każdą zależność od inicjalizacji i Mcp-Session-Id.
Przenieś wymagany stan do jawnych uchwytów lub współdzielonego magazynu.
Zaimplementuj MRTR z wygaśnięciem, ochroną replay i idempotencją.
Waliduj nagłówki MCP względem ciała JSON-RPC.
Partycjonuj cache według tenantów i zakresu autoryzacji.
Utwardź walidację issuerów OAuth.
Mierz metody deprecated i ruch legacy transportu.
Kanarkuj ścieżki nowoczesnego i legacy protokołu przed wycofaniem.
Traktuj migrację jako zmianę infrastrukturalną, a nie rutynową aktualizację SDK.
Gdy warstwa MCP będzie bezstanowa i obserwowalna, utrzymuj dostęp do modeli za oddzielnym interfejsem. Pozwoli to warstwie protokołu narzędzi i warstwie dostawców modeli rozwijać się niezależnie.
