MCP bez stanu, WebMCP w przeglądarce: czy asystent AI zarezerwuje hotel?

Krótka odpowiedź na pytanie z tytułu: wyszukać i porównać hotele asystent potrafi już dziś, ale płatność domyka strona sprzedawcy. Tak było od startu aplikacji hotelowych w ChatGPT i tak zostało po marcu 2026, gdy OpenAI wycofał finalizację zakupów w czacie nawet w handlu detalicznym. MCP i WebMCP nie konkurują ze sobą: to dwa wejścia do tej samej usługi — pierwszy od zaplecza, drugi od frontu, ze strony otwartej w przeglądarce. Nowa specyfikacja MCP z 28 lipca 2026 robi coś mniej widowiskowego, a ważniejszego: obniża firmom koszt wystawienia własnej „recepcji dla agentów”.

Co się zmieniło w MCP 28 lipca 2026

MCP (Model Context Protocol) to otwarty protokół, którym asystenci AI łączą się z narzędziami i danymi firm; Anthropic ogłosił go pod koniec 2024 roku. Specyfikacja z 28 lipca 2026 przynosi największą od tego czasu zmianę architektoniczną: protokół stał się bezstanowy, więc serwer MCP przestaje wymagać „lepkich” sesji i skaluje się zwykłymi load balancerami, jak każde API w firmie.

W szczegółach: zniknął handshake initialize, czyli wstępna wymiana ustaleń między klientem a serwerem, oraz nagłówek sesji. Wersję protokołu i możliwości klienta niesie każde żądanie z osobna, a nowy punkt końcowy server/discover pozwala klientowi z góry zapytać serwer, co potrafi. To różnica między usługą, którą trzeba niańczyć, a usługą, którą się po prostu hostuje.

Dwie zmiany mniejsze, ale ważne dla scenariuszy transakcyjnych. Długie operacje — na przykład rezerwacja czekająca na potwierdzenie systemu hotelowego — dostały oficjalne rozszerzenie tasks z odpytywaniem o stan zamiast wiszącego połączenia. A wzorzec Multi Round-Trip Requests pozwala serwerowi odpowiedzieć „potrzebuję jeszcze dat i liczby gości”, zamiast zgadywać albo zawodzić: dopytywanie, z którego składa się typowa rezerwacja, stało się częścią protokołu.

Skalę widać w liczbach podanych przy publikacji specyfikacji 28 lipca 2026: oficjalne SDK notują łącznie blisko pół miliarda pobrań miesięcznie, a biblioteki TypeScript i Python od premiery przekroczyły miliard każda. Ekosystem, który jeszcze niecałe dwa lata temu był ciekawostką z bloga Anthropic, ma dziś statystyki infrastruktury.

WebMCP: to samo, tylko od frontu

WebMCP to rozwijana od sierpnia 2025 propozycja inżynierów Google i Microsoftu w grupie społecznościowej W3C: strona sama deklaruje przez interfejs document.modelContext, jakie czynności udostępnia agentowi — „sprawdź dostępność”, „dodaj do koszyka”, „zmień termin” — z opisami i schematami, które agent rozumie bez zgadywania. To odpowiedź na słabość dzisiejszych agentów w przeglądarce, którzy naśladują człowieka: czytają układ strony i klikają, bywają skuteczni i bywają ślepi na każdą zmianę tego układu.

Autorzy piszą wprost, że WebMCP ma uzupełniać MCP, nie zastępować. Podział pracy jest naturalny. Serwer MCP obsługuje asystenta, który działa poza stroną — w czacie, w tle, na zlecenie. WebMCP obsługuje agenta działającego w zalogowanej sesji użytkownika, więc tożsamość, koszyk i uprawnienia dostaje z kontekstu przeglądarki, bez budowania osobnej autoryzacji.

Stan wdrożeń studzi emocje: to wciąż szkic (Draft Community Group Report), nie standard W3C, a działającą implementację ma w praktyce tylko Chrome; Firefox i Safari uczestniczą w dyskusji bez zobowiązań. Branżowe podsumowania z lata 2026 wspominają o pierwszych włączeniach na platformach e-commerce, ale to doniesienia wtórne — traktuję je jako kierunek, nie jako fakt do cytowania.

Dlaczego asystenci AI nie korzystają z WebMCP na stronie

Strona może mieć wzorowo zarejestrowane narzędzia WebMCP i żaden asystent ich nie wywoła, bo na sierpień 2026 nie ma jeszcze kto. Wtórne przeglądy z maja i lipca 2026 (Studiomeyer, Spronta) nie znalazły żadnego głównego klienta agentowego wywołującego te narzędzia: według nich ChatGPT, Claude, Perplexity i Gemini wciąż czytają strony przez DOM albo zrzuty ekranu, bez obsługi API WebMCP. Widzi je wyłącznie agent działający w przeglądarce użytkownika z obsługą tego API.

Google mówi to wprost w dokumentacji Chrome: API jest „primarily designed for local browser workflows with a human in the loop”, czyli człowiek ma otwartą stronę, a agent w jego Chrome używa jej narzędzi. Od Chrome 149 (ogłoszenie z 9 czerwca 2026) działa to w trybie origin trial, czyli próbnego wdrożenia, na które strona zapisuje się u Google i dostaje token: u zwykłych użytkowników obiekt modelContext istnieje tylko wtedy, gdy strona serwuje ten token w znaczniku meta albo nagłówku; bez tokenu dostęp ma wyłącznie programista z flagą chrome://flags/#enable-webmcp-testing. Edge prowadzi własny origin trial od wersji 150 (lipiec 2026), Brave deklaruje eksperymentalne wsparcie w asystencie Leo, a Firefox i Safari na sierpień 2026 implementacji nie mają (stanowiska Mozilli i WebKitu: neutralne albo niezajęte).

Do tego dwie pułapki z ostatnich miesięcy. Nazwa punktu wejścia się zmieniła: szkic przeniósł API z navigator.modelContext pod document.modelContext 27 maja 2026 (tak stoi też w wydaniu z 19 sierpnia 2026), a Chrome poszedł za tym od wersji 150, stabilnej od 30 czerwca 2026, zostawiając navigator.modelContext jako alias z ostrzeżeniem o wycofaniu. W buildzie Chromium 149 z tokenem origin trial sprawdziłem 22 sierpnia 2026, że token uruchamia natywny obiekt, wtedy jeszcze wyłącznie pod navigator.modelContext. Kod, który obsługuje tylko jedno z tych miejsc, działa więc tylko po jednej stronie tej zmiany; bezpieczny wzorzec obsługuje oba. Narzędzia najlepiej rejestrować statycznie, przy ładowaniu strony (Google zaleca to jako podejście domyślne), a dynamicznie dokładać je tylko w uzasadnionych stanach strony; agent, który wejdzie przed rejestracją, zobaczy pustą listę.

Test zajmuje kilka minut: Chrome 150 lub nowszy z włączoną flagą testową i rozszerzenie Model Context Tool Inspector, nieoficjalne narzędzie François Beauforta wskazywane w dokumentacji Chrome (jego README wymaga wersji 150.0.7861 lub nowszej), pokazują, które narzędzia strona zarejestrowała i z jakim schematem, oraz pozwalają wywołać je ręcznie. Jeśli inspektor je widzi, rejestracja działa, a brak ruchu to brak klientów, nie błąd w kodzie.

Jeśli celem jest, żeby ChatGPT albo Claude faktycznie sprawdziły termin i złożyły rezerwację, dziś prowadzi do tego drugie wejście: zdalny serwer MCP z tymi samymi narzędziami, dodany w asystencie jako własny connector, czyli połączenie z zewnętrznym serwerem MCP (w Claude przez połączenia niestandardowe w ustawieniach, w ChatGPT przez tryb deweloperski). Główne ograniczenie: użytkownik musi ten connector dodać ręcznie, bo publicznego odkrywania narzędzi, w którym asystent sam znajduje firmę i jej funkcje, na sierpień 2026 nie ma poza katalogami aplikacji, do których wchodzi się jako partner; dochodzą bramki planów, bo tryb deweloperski ChatGPT działa tylko na planach płatnych. Te ścieżki w ustawieniach zmieniają się bez zapowiedzi, więc ich stan trzeba sprawdzać na bieżąco; opis powyżej to stan na sierpień 2026.

Rezerwacja hotelu: co już działa, a co nie

Od października 2025 ChatGPT ma system aplikacji, a wśród pierwszych partnerów są Booking.com i Expedia: użytkownik opisuje termin i miejsce, asystent pokazuje w rozmowie aktualne ceny i dostępność. Wyszukanie i porównanie — etap, na którym człowiek traci najwięcej czasu — agent załatwia już dziś. Płatności w czacie nie: rezerwacja od początku kończy się na stronie partnera.

Rynek zdążył zresztą przetestować dalszy krok i się z niego wycofać. Finalizację zakupu wewnątrz czatu, Instant Checkout, OpenAI uruchomił we wrześniu 2025 dla sprzedawców detalicznych i zamknął w marcu 2026: konwersje zawiodły, kasa wróciła do sklepów, a ChatGPT skupia się na wyszukiwaniu produktów. Standardy płatności agentowych istnieją i dojrzewają — Agentic Commerce Protocol Stripe'a i OpenAI (rozwijany dziś także z Metą), Agent Payments Protocol Google, x402 dla mikropłatności — ale w podróżach wiszą nad nimi dwa otwarte pytania: o prowizję, bo jak pisał w sierpniu 2026 komentator branżowy w Hospitality Net, ustalonej struktury prowizji przy rezerwacjach agentowych po prostu nie ma, i o to, kto odpowiada, gdy agent zarezerwuje źle. Dopóki odpowiedzi nie padną, schemat jest hybrydowy: asystent doprowadza klienta do kasy, kasa stoi u sprzedawcy.

Dla hotelu czy każdej firmy usługowej płynie z tego wniosek odwrotny do intuicji „AI załatwi wszystko”: im więcej asystent robi na górze lejka, tym więcej waży to, co agent zastanie na dole — na stronie, gdzie transakcja faktycznie się domyka.

Co z tego wynika dla firmy

Układa się to w drabinę o trzech szczeblach: najpierw treść, ceny i terminy czytelne dla maszyn, potem serwer MCP tam, gdzie agent ma coś załatwić, na końcu spokojna obserwacja WebMCP. Już pierwszy szczebel odsiewa większość zmierzonych: w moim pomiarze z sierpnia 2026 podstawowy znacznik Organization miało tylko 23 z 60 spółek z WIG20 i mWIG40, a boty i agenci czytają dokument, nie ekran.

Szczebel drugi dotyczy firm, u których agent miałby coś zrobić, nie tylko przeczytać: sprawdzić termin, złożyć zamówienie, pobrać status sprawy. Tu właśnie bezstanowy MCP zmienia rachunek — punkt końcowy dla agentów przestaje być projektem specjalnym, a staje się zwykłym API z jasnymi regułami cache i bez sesji. Ile kosztuje zbudowanie agenta i takiej integracji, liczę osobno.

Szczebel trzeci to WebMCP: obserwować, nie budować na wyrost. Jedna przeglądarka i status szkicu to za mało na inwestycję, ale dość, żeby wiedzieć, w którą stronę idzie front. Jedno zastrzeżenie wspólne dla obu protokołów: narzędzie wystawione agentowi to nowa powierzchnia ataku, więc każdy taki punkt wymaga tych samych rygorów co publiczne API — uwierzytelnienia, limitów i założenia, że po drugiej stronie nie zawsze stoi grzeczny asystent. Agent to nowy typ gościa na stronie; różnica polega na tym, że temu gościowi można postawić ladę, zamiast kazać mu szukać po omacku.