Amazon AWS wspiera bezstanowy MCP, ale prawdziwym testem jest teraz kompatybilność

Amazon AWS dodał obsługę MCP 2026-07-28 do AgentCore Gateway dwa dni po tym, jak największa rewizja architektury specyfikacji osiągnęła status stabilnego wydania. Jedno wywołanie UpdateGateway może włączyć nową wersję protokołu w istniejącej bramie. Jednak prosta zmiana w warstwie sterowania skrywa trudniejsze przejście dla klientów, serwerów i zespołów ds. bezpieczeństwa w przedsiębiorstwach.

Nowa rewizja Model Context Protocol usuwa sesje na poziomie protokołu i sprawia, że każde żądanie opisuje własną wersję oraz możliwości klienta. MCP to otwarty standard łączący aplikacje AI z narzędziami, źródłami danych i innymi usługami. Jego bezstanowa konstrukcja powinna ułatwić skalowanie, trasowanie i odzyskiwanie działania bram.

Ta korzyść wiąże się z testem kompatybilności. Klienci muszą przyjąć nowe metadane żądań, serwery muszą wdrożyć mechanizm wykrywania, a wcześniejsze założenia dotyczące sesji przestają obowiązywać. Amazon Bedrock AgentCore Gateway znajduje się teraz między tymi dwiema erami protokołu, tłumacząc usługi przedsiębiorstwa na narzędzia MCP i egzekwując kontrolę dostępu w jednym zarządzanym punkcie końcowym.

Prawdziwa historia jest więc większa niż pole wyboru wersji. Amazon AWS stawia na to, że zarządzana brama może wchłonąć zmienność protokołu, zanim dotrze ona do każdego zespołu aplikacyjnego. To, czy się to sprawdzi, zależy od negocjacji wersji, poprawności autoryzacji oraz zachowania mieszanych flot klientów.

Amazon AWS zamienia gruntowną przebudowę MCP w jedną aktualizację bramy

AWS ograniczył krok infrastrukturalny do jednej operacji API, ale aplikacje nadal muszą poprawnie komunikować się zgodnie ze zrewidowanym protokołem.

Opiekunowie MCP wydali stabilną specyfikację 2026-07-28 28 lipca, po okresie wersji kandydującej do wydania, który rozpoczął się w maju. Stabilne wydanie MCP zastępuje kilka założeń ukształtowanych podczas wczesnego rozwoju protokołu.

AWS następnie dodał obsługę w Amazon Bedrock AgentCore Gateway. Według firmowej aktualizacji AgentCore właściciele bram mogą dodać nową rewizję za pośrednictwem UpdateGateway. Żądanie aktualizuje konfigurację protokołu MCP bramy oraz listę obsługiwanych wersji.

Istotnym obiektem warstwy sterowania jest protocolConfiguration.mcp.supportedVersions. AWS dokumentuje to pole jako tablicę wersji MCP, z których brama może korzystać. UpdateGateway zwraca status HTTP 202, gdy usługa przyjmie aktualizację, po czym brama przechodzi w stan aktualizacji.

To rozróżnienie ma znaczenie operacyjne. Przyjęte wywołanie nie oznacza, że każdy podłączony klient pomyślnie ukończył żądanie. Zespoły powinny poczekać, aż brama powróci do stanu gotowości, a następnie przeprowadzić testy zgodności i obciążeniowe względem rzeczywistego punktu końcowego.

Zmiana nie wymaga od organizacji przebudowy każdej funkcji Lambda, usługi OpenAPI ani usługi Smithy działającej za bramą. AgentCore Gateway już przekształca te zasoby w narzędzia zgodne z MCP. Obsługuje także zdalne cele MCP i inne usługi HTTP, zależnie od konfiguracji celu.

Ta architektura pozwala AWS zmieniać warstwę zwróconą ku protokołowi bez konieczności wprowadzania identycznych zmian w każdej dalszej usłudze biznesowej. Na przykład API obsługi klienta może pozostać API, podczas gdy brama udostępnia jego operacje jako narzędzia zgodnym agentom.

AgentCore Gateway obsługuje również uwierzytelnianie przychodzące, poświadczenia wychodzące, wykrywanie narzędzi, trasowanie i egzekwowanie zasad. Mechanizmy te zyskują na wartości, gdy jeden punkt końcowy udostępnia usługi należące do kilku wewnętrznych zespołów.

Wywołanie UpdateGateway zmienia jednak wyłącznie deklarowane wsparcie bramy. Klient korzystający z rewizji 2026 musi nadal wysyłać wymagane metadane i nagłówki. Starszy klient musi wynegocjować wzajemnie obsługiwaną rewizję albo skorzystać ze zgodnej ścieżki awaryjnej.

To pierwsze ograniczenie kryjące się za prostym przekazem AWS dotyczącym aktualizacji. Zarządzana usługa może ograniczyć pracę platformową, ale nie sprawi, że przestarzały SDK zacznie emitować nowy format transmisji.

Drugie ograniczenie dotyczy testowania. Właściciele bram muszą zweryfikować listowanie narzędzi, wywołania narzędzi, błędy uwierzytelniania, zachowanie przesyłania strumieniowego i mechanizmy kontroli pamięci podręcznej w ramach każdej obsługiwanej wersji. Sukces z jednym nowoczesnym klientem nie potwierdza kompatybilności w całej flocie przedsiębiorstwa.

Praktyczne wdrożenie zaczyna się zatem od inwentaryzacji. Zespoły muszą ustalić, które aplikacje agentowe łączą się z bramą, z jakich wersji SDK korzystają oraz czy te SDK obsługują MCP 2026-07-28.

Organizacje, które przechowują decyzje techniczne i dowody z testów w przeszukiwalnej bazie wiedzy inżynieryjnej, mogą rejestrować wyniki według klienta i wersji protokołu. Taki zapis staje się istotny, gdy awaria występuje tylko w jednym frameworku lub kanale wdrożeniowym.

AWS uczynił działanie w warstwie sterowania niewielkim. Weryfikacja na poziomie aplikacji pozostaje właściwym projektem migracyjnym.

Dlaczego bezstanowy MCP zmienia rolę bramy

Bezstanowy MCP przenosi informacje o kompatybilności do każdego żądania, upraszczając trasowanie horyzontalne, ale wymagając, by każda wiadomość była samowystarczalna.

Wcześniejsze rewizje MCP wykorzystywały wymianę inicjalizacyjną do ustanowienia szczegółów protokołu i możliwości. Klient wysyłał initialize, serwer odpowiadał, a klient kończył sekwencję przez notifications/initialized. Streamable HTTP mógł również używać nagłówka Mcp-Session-Id, aby powiązać późniejszy ruch z sesją na poziomie protokołu.

Kluczowe zmiany MCP usuwają ten cykl życia w nowej rewizji. Usuwają również identyfikator sesji na poziomie protokołu. Serwery, które potrzebują stanu między wywołaniami, muszą wystawiać jawne uchwyty, które klienci przekazują jako zwykłe argumenty narzędzi.

Każde żądanie w nowym stylu zawiera wersję protokołu i możliwości klienta w _meta. Klienci powinni również identyfikować się w tym miejscu. Serwery zwracają swoją tożsamość w metadanych wyniku, dzięki czemu każda wymiana jest bardziej samodzielnie opisująca.

Nowa metoda server/discover pozwala klientowi sprawdzić obsługiwane wersje, możliwości i tożsamość serwera przed rozpoczęciem innej pracy. Serwer korzystający z rewizji 2026-07-28 musi zaimplementować to zdalne wywołanie procedury.

Ta konstrukcja zmienia zakres informacji, które brama musi pamiętać. Nie musi już zależeć od wymiany inicjalizacyjnej ukończonej przez jedno połączenie ani wiązać późniejszego ruchu protokołu z nieprzejrzystą sesją MCP.

Moduł równoważenia obciążenia może trasować oddzielne żądania bez zachowywania powinowactwa na poziomie protokołu. Instancja bramy otrzymująca dziesiąte wywołanie może sprawdzić te same kluczowe informacje o kompatybilności, które otrzymała pierwsza instancja.

Ten model dobrze pasuje do zarządzanej bramy chmurowej. Usługi bezstanowe mogą skalować się między workerami, zastępować niezdrową przepustowość i rozdzielać ruch bez odtwarzania rekordu sesji MCP przed interpretacją każdego żądania.

Ogranicza także niewygodne niedopasowanie między krótkotrwałą infrastrukturą chmurową a zorientowanym na połączenia zachowaniem protokołu. Funkcje bezserwerowe i rozproszone bramy zwykle działają najlepiej, gdy żądania zawierają informacje wymagane do niezależnego przetwarzania.

Bezstanowość nie oznacza jednak, że praca agenta nie ma stanu. Przepływ zakupowy może nadal wymagać informacji o zatwierdzeniu, odniesienia do transakcji lub danych zebranych podczas wcześniejszej wymiany. Specyfikacja przenosi ten stan do jawnych uchwytów na poziomie aplikacji, zamiast ukrywać go w sesji transportowej.

Ta zmiana może poprawić widoczność. Argumenty narzędzi i uchwyty wystawiane przez serwer tworzą wyraźniejsze granice odpowiedzialności niż stan wywnioskowany z połączenia. Wymagają również starannego zaprojektowania, ponieważ klienci mogą ponawiać żądania lub przedstawiać stare uchwyty.

Nowa rewizja rezygnuje z możliwości wznawiania Streamable HTTP za pomocą Last-Event-ID i identyfikatorów zdarzeń wysyłanych przez serwer. Jeśli strumień odpowiedzi przerwie się podczas żądania, klient musi wysłać nowe żądanie z nowym identyfikatorem żądania.

Ta zasada rodzi ważne pytanie operacyjne. Jeśli narzędzie wykona efekt uboczny przed awarią strumienia, ślepe ponowienie może powtórzyć działanie, chyba że aplikacja wdroży idempotencję.

Rozważmy agenta, który tworzy zgłoszenie do pomocy technicznej. Usługa zgłoszeń może pomyślnie zapisać rekord, gdy strumień odpowiedzi zniknie. Ponowienie powinno zawierać klucz idempotencji na poziomie aplikacji albo sprawdzać wcześniejszą operację przed utworzeniem kolejnego zgłoszenia.

AWS nie może rozwiązać każdego problemu idempotencji w usługach downstream na granicy protokołu. Dzienniki i ślady bramy mogą pokazać powtórzone wywołania, ale docelowa usługa musi zdefiniować bezpieczne zachowanie przy ponawianiu.

Rewizja zastępuje także osobne wywołania inicjowane przez serwer żądaniami wieloetapowymi Multi Round-Trip Requests. W tym wzorcu serwer zwraca wynik input_required, opisujący informacje, których nadal potrzebuje. Klient ponawia pierwotne żądanie wraz z żądanymi odpowiedziami.

Takie podejście utrzymuje kontrolę w ramach sekwencji żądań i ponowień. Unika niezależnego żądania serwer-do-klienta docierającego przez połączenie, którego inna instancja bramy może nie obsługiwać.

Wszystkie wyniki zawierają teraz resultType, zwykle complete albo input_required. Klienci komunikujący się ze starszymi serwerami muszą traktować pominiętą wartość jako ukończony wynik, zachowując ograniczony pomost kompatybilności.

Mechanizm wyraźnie sprzyja rozproszonej infrastrukturze. Kompromisem jest konieczność przyjęcia przez SDK i aplikacje bardziej jawnych metadanych, logiki ponawiania i obsługi stanu.

Presja spada na SDK i mieszane floty klientów

AgentCore Gateway może obsługiwać dwie ery protokołu, ale każda organizacja musi udowodnić, że jej klienci negocjują właściwą wersję.

Bezpośrednim celem presji nie jest API ukryte za bramą. Jest nim oprogramowanie klienckie łączące się z punktem końcowym MCP.

Klient deklarujący rewizję 2026-07-28 musi w każdym żądaniu wysyłać wersję protokołu oraz swoje możliwości. Musi rozumieć server/discover, wymagane typy wyników i zrewidowaną obsługę interakcji wieloetapowych.

Klienci HTTP muszą również używać standardowych nagłówków żądań MCP, w tym Mcp-Method i Mcp-Name. Nagłówki te umożliwiają infrastrukturze sprawdzanie i trasowanie ruchu bez analizowania każdego ciała JSON-RPC.

Ta zmiana jest przydatna dla bram, systemów obserwowalności i mechanizmów kontroli bezpieczeństwa. Tworzy również kolejny punkt walidacji, w którym niekompletni klienci mogą zawieść przed wykonaniem narzędzia.

MCP definiuje konkretne błędy dla tej nowej granicy. Niezgodności nagłówków używają kodu -32020, brak wymaganych możliwości klienta — -32021, a nieobsługiwane wersje protokołu — -32022.

Kody te zapewniają zespołom platformowym bardziej przejrzystą taksonomię awarii. Wzrost liczby odpowiedzi -32022 wskazuje na problemy z negocjacją wersji, podczas gdy -32020 sugeruje rozbieżność między nagłówkami HTTP a zawartym żądaniem.

Przejście SDK nie nastąpi jednocześnie we wszystkich językach. Oficjalne implementacje mogą przyjmować stabilną specyfikację w różnych harmonogramach, a aplikacje często przypinają wersje bibliotek długo po pojawieniu się nowego wydania.

Przedsiębiorstwa mają również klientów, nad którymi nie sprawują pełnej kontroli. Pracownik może korzystać z zatwierdzonego asystenta desktopowego, wewnętrznego agenta wiersza poleceń oraz rozszerzenia IDE stworzonego przez inny zespół. Każdy z nich może inaczej negocjować MCP.

Lista obsługiwanych wersji AgentCore stanowi pomost dla tej mieszanej floty. Brama może reklamować więcej niż jedną rewizję, zamiast zmuszać wszystkich klientów do jednoczesnego przejścia na nowy format transmisji.

To wsparcie należy traktować jako mechanizm migracji, a nie dowód identycznego zachowania. Funkcje usunięte z rdzenia 2026 nadal istnieją w starszych przepływach protokołu. Test zakończony powodzeniem po wynegocjowaniu starszej wersji niewiele mówi o ścieżce bezstanowej.

Roots, Sampling i Logging są teraz wycofywane, a nie natychmiast usuwane z całej specyfikacji. Nowe implementacje powinny unikać ich wdrażania, natomiast istniejące implementacje otrzymują określony okres przejściowy.

Nowa polityka cyklu życia funkcji MCP ustanawia minimalny 12-miesięczny okres wycofywania. Ta zmiana zasad zarządzania daje implementatorom bardziej przewidywalne wyprzedzenie niż nieformalne sformułowania o wycofywaniu.

Protokół sugeruje alternatywy. Aplikacje mogą przekazywać katalogi przez parametry narzędzi lub identyfikatory zasobów zamiast Roots. Serwery mogą wywoływać API dostawców modeli bezpośrednio zamiast polegać na Sampling. Implementacje mogą korzystać z OpenTelemetry lub standardowych strumieni błędów zamiast protokołu Logging.

Te zamienniki zmieniają architekturę, a nie tylko składnię. Serwer, który wcześniej żądał próbkowania modelu za pośrednictwem klienta MCP, może potrzebować bezpośredniej integracji z dostawcą, oddzielnych poświadczeń i nowej polityki kontroli kosztów.

Presja obejmuje więc również zespoły bezpieczeństwa i finansów. Przeniesienie dostępu do modelu z funkcji klienta do serwera zmienia miejsce przechowywania poświadczeń i raportowania użycia.

Właściciele bram powinni podzielić klientów na trzy grupy. Pierwsza w pełni obsługuje wersję 2026. Druga działa wyłącznie z wcześniejszą stabilną wersją. Trzecia zachowuje się niejednoznacznie i wymaga izolacji do czasu zakończenia testów.

Testowanie powinno obejmować więcej niż tools/list. Przydatna macierz uwzględnia wykrywanie, uwierzytelnione wywołania narzędzi, odrzucone zakresy, strumieniowanie odpowiedzi, przerwane żądania, buforowanie list oraz aplikacje wymagające dodatkowych danych od użytkownika.

Zespoły powinny również weryfikować wynegocjowaną wersję w telemetrii. Bez tego sygnału udane żądanie może ukrywać nieoczekiwany powrót do wcześniejszego protokołu.

Migracja jest udana, gdy nowa ścieżka obsługuje reprezentatywne obciążenia produkcyjne. Nie jest udana wyłącznie dlatego, że brama akceptuje zaktualizowane pole supportedVersions.

Autoryzacja staje się bardziej rygorystyczna, gdy rozszerzenia opuszczają rdzeń

MCP 2026-07-28 ogranicza niejednoznaczność poświadczeń, jednocześnie przenosząc opcjonalne możliwości do zarządzanego, negocjowanego systemu rozszerzeń.

Zmienione zasady autoryzacji koncentrują się na granicach tożsamości, które stają się ryzykowne, gdy agenci łączą się z wieloma serwerami. Klient MCP może uzyskiwać poświadczenia od kilku serwerów autoryzacji, z których każdy chroni inne narzędzia i dane.

Specyfikacja mówi teraz, że klienci muszą powiązać przechowywane poświadczenia z wystawcą, który je utworzył. Klient nie może ponownie używać poświadczeń z innym serwerem autoryzacji i musi zarejestrować się ponownie, gdy wystawca się zmienia.

Ta zasada przeciwdziała pomyleniu poświadczeń. Podobne nazwy serwerów, przekierowania lub zmieniające się metadane nie powinny powodować, że poświadczenia klienta jednej usługi trafiają do innej granicy autoryzacji.

Serwery autoryzacji powinny również umieszczać wartość iss w swoich odpowiedziach autoryzacyjnych. Gdy to pole jest obecne, klienci muszą zweryfikować je względem wystawcy zarejestrowanego przed wymianą kodu autoryzacyjnego.

Ta walidacja jest zgodna z RFC 9207, standardem Internet Engineering Task Force zaprojektowanym w celu zapobiegania atakom polegającym na pomyleniu serwera autoryzacji. Kontrola ma znaczenie, gdy jeden klient współpracuje z wieloma wystawcami lub dynamicznie wykrywa metadane autoryzacji.

Dynamiczna rejestracja klienta również otrzymuje bardziej rygorystyczne wytyczne. Klienci MCP muszą określić odpowiedni typ aplikacji, ograniczając konflikty dotyczące zasad URI przekierowań dla aplikacji natywnych i internetowych.

Wymagania te nie czynią automatycznie bezpieczną każdej implementacji. Opcje SDK nadal wymagają poprawnej konfiguracji, przechowywane rekordy poświadczeń odpowiedniego kluczowania, a dostawcy tożsamości muszą zwracać spójne informacje o wystawcy.

AgentCore Gateway zapewnia użyteczny punkt egzekwowania zasad, ponieważ może uwierzytelniać wywołujących przychodzących i oddzielnie zarządzać poświadczeniami wychodzącymi. Dokumentacja AWS podaje, że usługa obsługuje niestandardową autoryzację JSON Web Token, AWS Identity and Access Management oraz inne skonfigurowane tryby autoryzacji.

To rozdzielenie jest kluczowe. Tożsamość uprawniona do wywołania bramy nie powinna automatycznie otrzymywać nieograniczonych poświadczeń do każdego celu za nią.

AgentCore może również powiązać silnik polityk z bramą. Silnik ocenia wywołania narzędzi przez agenta i decyduje, czy każda akcja jest dozwolona, czy odrzucona na podstawie skonfigurowanych zasad.

Model bramy nie eliminuje potrzeby stosowania zasady najmniejszych uprawnień. Poświadczenie celu o szerokim zakresie nadal ma szeroki zakres, nawet jeśli jest przechowywane w zarządzanej usłudze tożsamości.

Zespoły powinny testować przypadki negatywne równie starannie jak udane wywołania. Klient z niewystarczającym zakresem powinien otrzymać kontrolowaną odpowiedź autoryzacyjną, a nie niepowiązany błąd protokołu ani dostęp do sąsiedniego narzędzia.

System rozszerzeń tworzy równoległą zmianę w zarządzaniu. Opcjonalne funkcje mogą teraz rozwijać się poza rdzeniem protokołu, korzystając ze standaryzowanych identyfikatorów, deklaracji możliwości i negocjacji.

W ramach frameworka rozszerzeń oficjalne identyfikatory używają prefiksu io.modelcontextprotocol. Strony trzecie powinny używać odwróconej domeny, której są właścicielami, co ogranicza kolizje między niepowiązanymi funkcjami.

Klienci ogłaszają obsługiwane rozszerzenia w ramach możliwości przypisanych do każdego żądania. Serwery ogłaszają swoje za pośrednictwem server/discover. Obie strony muszą wyraźnie wyrazić zgodę, a rozszerzenia pozostają domyślnie wyłączone.

Oficjalne rozszerzenia obejmują asynchroniczne Tasks, interaktywne MCP Apps, poświadczenia klienta OAuth oraz autoryzację zarządzaną przez przedsiębiorstwo. Rdzeń nie musi już wchłaniać każdej wyspecjalizowanej funkcji, zanim implementatorzy będą mogli z niej korzystać.

Ta struktura może ograniczyć złożoność rdzenia. Tworzy jednak również macierz wsparcia, którą zespoły platformowe muszą śledzić wśród klientów, serwerów, bram i wersji SDK.

Klient obsługujący rozszerzenie interaktywnego interfejsu powinien nadal obsługiwać sensowną odpowiedź tekstową, gdy serwer może w sposób kontrolowany ograniczyć funkcjonalność. Serwer wymagający konkretnego rozszerzenia autoryzacji może zamiast tego odrzucić niekompatybilnego klienta.

Pierwszym obowiązkiem AgentCore Gateway jest poprawne zachowanie rdzenia protokołu. Obsługi wersji 2026 nie należy interpretować jako uniwersalnego wsparcia dla każdego obecnego lub przyszłego rozszerzenia.

To kluczowa niepewność w ogłoszeniu AWS. Brama może przenosić informacje o możliwościach rozszerzeń, ale klienci potrzebują jednoznacznej dokumentacji i testów dla każdego rozszerzenia, od którego zależy ich przepływ pracy.

Zmiany w autoryzacji i framework rozszerzeń łączy jedna zasada. Ukryte założenia stają się jawne, niezależnie od tego, czy dotyczą wystawców poświadczeń, możliwości klienta czy opcjonalnego zachowania.

Ta jawność jest korzystna dla kontroli w przedsiębiorstwie. Oznacza jednak również, że niepełna konfiguracja będzie kończyć się bardziej widocznymi błędami niż w przypadku liberalnej integracji.

Co klienci Amazon AWS nadal muszą udowodnić

Trzy kolejne sygnały to telemetria wynegocjowanej wersji, jakość błędów autoryzacji oraz obsługa rozszerzeń przy rzeczywistych obciążeniach.

Pierwszym sygnałem jest to, czy klienci produkcyjni faktycznie negocjują MCP 2026-07-28. Sama konfiguracja bramy nie może odpowiedzieć na to pytanie.

Zespoły powinny monitorować metadane żądań i błędy związane z protokołem po etapowym wdrożeniu. Powinny porównywać wyniki według nazwy klienta, wersji klienta, frameworka i kanału wdrożenia.

Malejący odsetek błędów nieobsługiwanej wersji i niezgodności nagłówków wzmocniłby argument AWS za zarządzaną migracją. Utrzymujące się błędy pokazałyby, że wąskim gardłem pozostaje adopcja klienckich SDK, a nie dostępność bramy.

Obniżenie wersji zasługuje na równą uwagę. Klient, który po cichu przechodzi na starszą wersję, może utrzymać działanie przepływu pracy, jednocześnie ukrywając nierozwiązany problem migracyjny.

Organizacje powinny zdefiniować oczekiwaną wersję dla każdego testowanego klienta. Alerty mogą wtedy rozróżniać zatwierdzony powrót do zgodnej wersji od niezamierzonego obniżenia wersji.

Drugim sygnałem jest zachowanie błędów autoryzacji w wielu dostawcach tożsamości i celach. Zespoły muszą testować zmiany wystawcy, nieprawidłowe wartości iss, wygasłe tokeny, niewystarczające zakresy i próby ponownego użycia poświadczeń.

Najbezpieczniejszym wynikiem jest precyzyjna odmowa, zanim cel wykona działanie. Logi powinny wskazywać zaangażowaną politykę lub granicę autoryzacji bez ujawniania sekretów wywołującemu.

Czyste testy negatywne potwierdziłyby twierdzenie, że AgentCore ogranicza niestandardową pracę związaną z bezpieczeństwem. Mylące błędy lub niespójna obsługa wystawców osłabiłyby je, szczególnie w przypadku bram obejmujących kilka jednostek biznesowych.

Trzecim sygnałem jest interoperacyjność rozszerzeń. Przepływ pracy korzystający z Tasks, MCP Apps lub rozszerzenia autoryzacji powinien weryfikować możliwości przed wywołaniem zachowania specyficznego dla rozszerzenia.

Testowanie musi obejmować kontrolowane ograniczanie funkcjonalności. Klient bez obsługi interfejsu użytkownika powinien nadal otrzymać użyteczną treść rdzenia, gdy serwer obiecuje mechanizm awaryjny.

Znaczenie ma również przypadek odwrotny. Jeśli rozszerzenie jest obowiązkowe dla bezpiecznego działania, serwer powinien wyraźnie odrzucić żądanie zamiast próbować realizować częściowy przepływ pracy.

Pod tymi trzema priorytetami kryją się szersze sygnały operacyjne. Zespoły powinny obserwować przerwane wywołania powodujące skutki uboczne pod kątem zduplikowanych działań, ponieważ nowa wersja usuwa możliwość wznawiania strumienia.

Powinny również analizować buforowanie. Wyniki list i zasobów zawierają teraz ttlMs, wskazówkę świeżości mierzoną w milisekundach, oraz cacheScope, które rozróżnia możliwość publicznego i prywatnego buforowania.

Deterministyczne porządkowanie narzędzi może poprawić buforowanie po stronie klienta i buforowanie promptów modelu. Jednak nieaktualne opisy narzędzi mogą spowodować, że agent wywoła przestarzały schemat, dlatego zachowanie pamięci podręcznej wymaga testów podczas aktualizacji celów.

Obserwowalność powinna obejmować rozproszony kontekst śledzenia. Specyfikacja dokumentuje konwencje _meta dla traceparent, tracestate i baggage, pomagając zespołom śledzić pracę między klientami, bramami i celami.

To śledzenie staje się szczególnie przydatne podczas ponownych prób. Operatorzy muszą połączyć pierwotny nieudany strumień z nowo wydanym żądaniem, nie traktując ich jako jednego identyfikatora żądania JSON-RPC.

Największa wartość zarządzanej bramy ujawnia się, gdy te kwestie się zbiegają. Jeden punkt końcowy może uwierzytelniać wywołujących, stosować polityki, tłumaczyć ruch protokołu, wybierać narzędzia, wstrzykiwać poświadczenia celu i tworzyć dowody audytowe.

W tym samym miejscu ujawnia się również jej główne ryzyko. Brama staje się punktem kontroli o dużym wpływie, więc błąd konfiguracji może jednocześnie dotknąć wielu agentów i usług.

Ostrożne wdrożenie powinno rozpocząć się od niekrytycznej bramy lub ograniczonej grupy klientów. Zespoły mogą dodać nową obsługiwaną wersję, poczekać na status gotowości i uruchomić zestaw testów specyficznych dla wersji.

Kolejny etap powinien wprowadzić reprezentatywne przepływy stanowe wykorzystujące jawne uchwyty. Powinien obejmować jedno przerwane żądanie i jeden bezpiecznie ponowiony skutek uboczny.

Testowanie autoryzacji powinno następnie objąć zarówno udane, jak i odrzucone wywołania. Przepływy pracy zależne od rozszerzeń powinny wejść jako ostatnie, po ustabilizowaniu zachowania rdzenia protokołu.

Planowanie wycofania zmian nadal jest konieczne. Utrzymanie poprzedniej stabilnej wersji na liście obsługiwanych wersji zapewnia zgodnym klientom rozwiązanie awaryjne, gdy zespoły badają defekty.

Jednak rozwiązanie awaryjne nie powinno stać się trwałą niejednoznacznością. Organizacje potrzebują daty przeglądu pozostałych starszych klientów oraz planu dla funkcji wycofanych, z których nadal korzystają.

Deweloperzy powinni się tym interesować, ponieważ ta wersja zmienia miejsce przechowywania stanu i sposób ponawiania prób. Zespoły platformowe powinny się tym interesować, ponieważ zgodność staje się obserwowalna na granicy bramy.

Nabywcy korporacyjni powinni się tym interesować, ponieważ zarządzana obsługa protokołu może ograniczyć powielaną infrastrukturę. Nadal powinni pytać, które rozszerzenia, SDK, regiony, konfiguracje tożsamości i typy celów przeszły walidację produkcyjną.

Pracownicy umysłowi odczują ten efekt pośrednio. Ich asystenci mogą łączyć się z większą liczbą narzędzi przy mniejszej liczbie nieudanych połączeń, ale tylko wtedy, gdy tożsamość i zgoda pozostaną jasne we wszystkich tych narzędziach.

Amazon AWS sprawił, że pierwszy krok migracji jest wyjątkowo niewielki. Ważniejsze pytanie brzmi, czy zespoły zdołają uczynić każde żądanie samowystarczalnym, nie tracąc przy tym bezpieczeństwa, kompatybilności ani widoczności.

W ciągu najbliższego jednego do trzech miesięcy warto obserwować dane dotyczące negocjowanych wersji, jakość komunikatów o odmowie autoryzacji oraz zgodność rozszerzeń w głównych SDK. Sygnały te pokażą, czy bezstanowy MCP stał się standardem produkcyjnym, czy pozostaje funkcją bramy oczekującą na obsługę po stronie klientów.

Dla zespołów, które już korzystają z AgentCore Gateway, kolejnym praktycznym krokiem jest kontrolowany audyt kompatybilności. Zaktualizuj jedną bramę, przetestuj każdego obsługiwanego klienta, zapisz wynegocjowaną wersję i wymuś przypadki błędów, zanim rozszerzysz dostęp.

Te dowody mają większe znaczenie niż pozorna prostota jednego wywołania API. Amazon AWS zapewnia teraz pomost do MCP 2026-07-28, lecz każda organizacja musi udowodnić, że jej agenci potrafią bezpiecznie przez niego przejść.