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. Wyjątkiem jest od 27 sierpnia 2026 tryb AI Google w USA, w którym rezerwację opłaca się przez Google Pay. MCP i WebMCP uzupełniają się: 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 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.

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.

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. W tej propozycji 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, wersja z 29 września 2026) bez statusu standardu W3C. Implementacje mają Chrome i Edge w trybie origin trial, eksperymentalnie Brave w asystencie Leo, a od 25 sierpnia 2026 aplikacja ChatGPT na komputery. Firefox i Safari implementacji nie mają: Mozilla ocenia propozycję neutralnie, a WebKit jest przeciw.

W sierpniu napisałem tu, że o włączeniach na platformach e-commerce mówią tylko doniesienia wtórne, i przeoczyłem źródło pierwotne. Shopify ogłosił w swoim changelogu już 5 sierpnia 2026, że narzędzia WebMCP działają w każdym sklepie zbudowanym na szablonach Liquid („There's nothing to install or configure”). 28 września 2026 dołożył narzędzia w kasie, które przy 3D Secure oddają sterowanie kupującemu. We wpisie z 22 września 2026 Stripe ogłosił, że włączył WebMCP na wszystkich interfejsach Stripe Checkout, także bez zmian po stronie sprzedawcy.

W tym samym wpisie Stripe opisał własny test, który czytam jako deklarację producenta: 60 przebiegów sześciu nienazwanych modeli w fikcyjnym sklepie z artykułami outdoorowymi, po 30 z WebMCP i bez niego. Według tego wpisu agenci z WebMCP zużyli o 42% mniej tokenów, domknęli zakup o 39% szybciej i wykonali o 38% mniej wywołań narzędzi; bez WebMCP średnia wynosiła 1,8 mln tokenów, 38,83 wywołania i ponad 2,5 minuty na transakcję. Zakup domknęli wszyscy agenci w obu wariantach, więc test mierzy koszt i czas po stronie agenta, a konwersji nie dotyczy. Stripe nie podaje nazw modeli, dat testu ani przeglądarki, a tokeny liczy razem z cache, więc 42% mniej tokenów nie oznacza wprost rachunku niższego o tyle samo.

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 klientów, którzy to potrafią, jest wciąż kilku. Wszyscy, o których wiem na 29 września 2026, działają w przeglądarce otwartej na tej stronie. 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 czytały strony przez DOM albo zrzuty ekranu. Od 25 sierpnia 2026 wyjątkiem jest ChatGPT, ale tylko w przeglądarce wbudowanej w aplikację na komputery. Google o obsłudze WebMCP przez Gemini w Chrome mówi od 19 maja 2026 tylko w czasie przyszłym („Gemini in Chrome will soon support WebMCP APIs”). Do 29 września 2026 nie znalazłem informacji, że ją uruchomił.

OpenAI nazywa obsługę WebMCP w ChatGPT „site tools” i w dokumentacji (odczyt 30 września 2026) opisuje warunki, od których zależy, czy agent w ogóle zobaczy narzędzia strony. Przeglądarka ChatGPT nie widzi narzędzi deklarowanych atrybutami formularzy HTML („Tools defined through HTML form attributes aren't available as site tools”) ani narzędzi zarejestrowanych w ramkach iframe, także z tej samej domeny. Obsługa narzędzi działa z modelami GPT-5.6 Sol i GPT-6 Sol (przy GPT-5.6 Luna jest wyłączona), w obszarach roboczych Enterprise wymaga zgody administratora w zasadach obszaru, a w obszarach Edu jest niedostępna. Zakup i inne czynności o istotnych skutkach (wysłanie wiadomości, usunięcie danych, zmiana uprawnień) nadal wymagają potwierdzenia użytkownika. Z zestawienia dokumentacji wynika też wniosek, którego nie sprawdziłem pomiarem: ChatGPT nie zobaczy narzędzi Stripe'a do wypełniania formularza płatności, bo Stripe buduje je deklaratywnie, a formularz osadzony i Elements działają w ramkach. W aplikacji ChatGPT zadziałają najwyżej narzędzia imperatywne na hostowanej stronie Checkout, jak odczyt zamówienia i wybór metody płatności, a pola formularza agent wypełni zwykłą automatyzacją.

Google w dokumentacji Chrome opisuje samo API wprost: 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), a Brave deklaruje eksperymentalne wsparcie w asystencie Leo. Firefox i Safari na wrzesień 2026 implementacji nie mają (Mozilla ocenia propozycję neutralnie, WebKit w czerwcu 2026 formalnie się jej sprzeciwił).

Próba w Chrome ma wyznaczoną ostatnią wersję. Obejmuje wersje 149⁠–⁠156, a Chrome 156, stabilny od 20 października 2026, bez przedłużenia będzie ostatnią wersją objętą próbą. 28 września 2026 w Chrome Status i na liście blink-dev pojawił się wniosek o przedłużenie próby do wersji 162, stabilnej od 2 lutego 2027, z uzasadnieniem, że uwagi z pierwszej tury prowadzą do poprawek API. Wniosek dostał zgodę jednego z właścicieli API Blinka pod warunkiem przedstawienia podsumowania opinii deweloperów z pierwszej tury. Zespół WebMCP przedstawił je 29 września 2026 i zapowiedział, że w oknie przedłużenia chce złożyć wniosek o wdrożenie (Intent to Ship). Do przedłużenia próby wystarcza jedna zgoda, więc próba w Chrome najpewniej potrwa do wersji 162. Zapowiedzi WebMCP w stabilnym Chrome 157 z listopada, które krążą we wtórnych podsumowaniach, nie mają oparcia w Chrome Status: funkcja ma tam wciąż status „Proposed”.

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 wydaniach z 19 sierpnia i 29 września 2026). Chrome poszedł za tym od wersji 150, stabilnej od 30 czerwca 2026, i zostawił 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 pokazują, które narzędzia strona zarejestrowała i z jakim schematem, oraz pozwalają wywołać je ręcznie. Inspektor to nieoficjalne narzędzie François Beauforta wskazywane w dokumentacji Chrome; jego README wymaga wersji 150.0.7861 lub nowszej. Jeśli inspektor je widzi, rejestracja działa w Chrome z flagą. Jeśli przy tym strona serwuje token origin trial, a narzędzia nie siedzą w ramce iframe ani w atrybutach formularza (takich nie widzi przeglądarka ChatGPT), brak ruchu wynika z braku klientów.

Jeśli celem jest, żeby ChatGPT albo Claude sprawdziły termin i złożyły rezerwację także wtedy, gdy nikt nie ma otwartej strony, prowadzi do tego drugie wejście: zdalny serwer MCP z tymi samymi narzędziami. Dodaje się go 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 tych ścieżek 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ę i o to, kto odpowiada, gdy agent zarezerwuje źle. Ustalonej struktury prowizji przy rezerwacjach agentowych po prostu nie ma, jak pisał w sierpniu 2026 komentator branżowy w Hospitality Net. Dopóki odpowiedzi nie padną, schemat jest zwykle hybrydowy: asystent doprowadza klienta do kasy, kasa stoi u sprzedawcy.

27 sierpnia 2026 Google ogłosił, że w USA, po angielsku, zaczął udostępniać rezerwację hotelu w trybie AI: po wybraniu „Continue on Google” użytkownik wybiera pokój, sprawdza warunki anulowania i płaci przez Google Pay. Stroną transakcji zostaje hotel albo serwis rezerwacyjny („the hotel or booking platform will act as the merchant of record and handle any customer service”). Partnerów, wśród nich Booking.com, Expedię, Hilton, Marriott i IHG, Google miał dołączać w kolejnych tygodniach.

We wrześniu doszedł Meta Muse, agent udostępniany od 8 września 2026 w USA, który sam otwiera przeglądarkę, wypełnia formularze i przed zakupem prosi o zgodę. Meta wymienia wśród jego zadań rezerwację podróży („booking travel”), a płaci on przez Link od Stripe'a, u sprzedawców bez Linka jednorazową kartą wirtualną, więc w USA może już opłacić pokój w kasie hotelu. Nowa jest zapowiedź bezpośredniej rezerwacji u Expedii: firma ogłosiła 22 września 2026, że rezerwację hotelu będzie można domknąć u niej bez wychodzenia z Muse; według relacji branżowych to Expedia pozostanie stroną transakcji, a płatność odbędzie się w Muse. Branżowy Hospitality.today pisał 25 września 2026, że funkcja jeszcze nie działa i nie ma daty startu, a Meta w opublikowanym 24 września 2026 podsumowaniu konferencji Connect wciąż opisuje ofertę Expedii jako „coming soon”.

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, u sprzedawcy. To sprzedawca faktycznie domyka transakcję: na własnej stronie albo, jak w trybie AI Google, jako strona transakcji w cudzym interfejsie.

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 WebMCP. Przy nim pierwszym krokiem jest sprawdzenie, czy nie włączyła go już platforma. 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ć: sprawdzić termin, złożyć zamówienie, pobrać status sprawy. Tu właśnie bezstanowy MCP zmienia rachunek: punkt końcowy dla agentów 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 i tu od sierpnia zmieniło się najwięcej. Sklep na Shopify albo z kasą Stripe Checkout ma narzędzia od platformy, więc zamiast budować, sprawdza inspektorem, co widzi agent w Chrome. Trzeba przy tym pamiętać, że przeglądarka ChatGPT pominie narzędzia deklaratywne i te w ramkach (co to znaczy dla polskiego sklepu, opisuję osobno). Pozostałym wystarczy mały pilotaż: kilka narzędzi rejestrowanych skryptem w dokumencie najwyższego poziomu i token origin trial na stronie, bo wtedy obsłuży je i Chrome, i ChatGPT. Status szkicu i próba w Chrome, która nawet po przedłużeniu potrwa najpewniej tylko do wersji 162, stabilnej od 2 lutego 2027, to wciąż za mało na dużą inwestycję. Jedno zastrzeżenie wspólne dla obu protokołów: narzędzie wystawione agentowi to nowa powierzchnia ataku. Każdy taki punkt wymaga więc 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.