Przejdź do treści
Webdesign · 9 min czytania

WebMCP pięć miesięcy później: Chrome mówi tak, Apple mówi nie

W czerwcu WebMCP miał trafić do stabilnego Chrome w ciągu miesięcy. Dziś test przedłużono do marca, Apple formalnie mówi nie, a jego argumenty to wykład o semantyce stron.

Tekst:
WebMCP 2026 — dwie przeglądarki z przeciwnymi decyzjami, symbole akceptacji i odrzucenia oraz kalendarz wskazujący marzec 2027.
WebMCP między akceptacją a sprzeciwem. Chrome kontynuuje testy, Apple kwestionuje kierunek rozwoju standardu.

W czerwcu napisałem na webflux.pl, że WebMCP warto testować, ale nie wdrażać na produkcji, i że do stabilnego Chrome trafi raczej w ciągu miesięcy niż lat. Minęło pięć miesięcy. Pierwsza połowa tamtej rady jest nadal aktualna. Druga się nie sprawdziła, a powód jest ciekawszy niż sama data.

WebMCP pozwala stronie wystawić agentowi w przeglądarce narzędzia: nazwaną funkcję z opisem i schematem danych, zamiast zmuszać go do klikania po interfejsie. Przez te miesiące zmieniły się daty, API i lista agentów. Najważniejsze stało się jednak poza Chrome. Apple formalnie powiedziało „nie”, Mozilla powiedziała „zobaczymy”, a ich argumenty dotyczą wprost tego, jak projektujemy strony.

Co się zmieniło od czerwca

SprawaCzerwiec 2026Listopad 2026
ChromeOrigin trial od wersji 149, stabilna wersja „w ciągu miesięcy”Test przedłużony do Chrome 162, koniec 30 marca 2027; w Chrome Status nadal „Proposed”, bez docelowej wersji
EdgeZapowiedź na III kwartałWłasny test od Edge 150 (lipiec), również do 30 marca 2027
Safari (WebKit)Brak deklaracjiFormalny sprzeciw od 11 czerwca
FirefoxBrak deklaracjiStanowisko neutralne od 5 sierpnia
APInavigator.modelContext zastępowane przez document.modelContextStara nazwa usunięta w Chrome 152; deklaratywne atrybuty formularzy usunięte ze specyfikacji 8 października
AgenciWywołanie tylko po podaniu nazwy narzędziaChatGPT w aplikacji desktopowej sam znajduje narzędzia; Claude w Chrome nadal tylko wywołuje; Gemini w Chrome nadal „wkrótce”

Jedna zmiana idzie w stronę WebMCP. Od 25 sierpnia wbudowana przeglądarka w aplikacji ChatGPT na komputer obsługuje „site tools”, czyli narzędzia WebMCP, i sama wykrywa je na otwartej stronie. To pierwszy popularny agent, który robi to bez podpowiedzi. Zastrzeżenia są jednak duże: działa tylko w przeglądarce wbudowanej w aplikację, nie w Chrome, tylko na wybranych kontach i modelach i bez planów Enterprise i Edu.

W moim czerwcowym eksperymencie na webflux.pl Claude w Chrome wywołał narzędzie dopiero wtedy, gdy podałem mu jego nazwę. To się nie zmieniło. W publicznym zgłoszeniu do Anthropic opisano to krótko: wywołanie działa, odkrywania nie ma. Google zapowiedziało obsługę WebMCP w Gemini w Chrome w maju na I/O. W październiku tej obsługi nadal nie było.

Trzy przeglądarki, trzy stanowiska

Chrome i EdgeTak

Google i Microsoft piszą specyfikację i prowadzą testy na prawdziwych stronach. Do stabilnej wersji nie trafiła żadna z nich.

Safari (WebKit)Nie

Formalny sprzeciw. Agent powinien korzystać z tej samej semantyki co ludzie i technologie wspomagające.

FirefoxZobaczymy

Stanowisko neutralne, do rewizji, gdy będzie widać, jak strony naprawdę używają WebMCP.

Przeglądarki deklarują swoje zdanie o nowych propozycjach w publicznych repozytoriach „standards positions”. To nie są decyzje wdrożeniowe i każdą można zmienić. Ich treść mówi jednak dużo o tym, co musiałoby się wydarzyć, żeby WebMCP stał się standardem sieci, a nie funkcją jednej rodziny przeglądarek.

Dlaczego Apple mówi nie

Zespół WebKit, który rozwija silnik Safari, oznaczył WebMCP jako oppose 11 czerwca. Na liście zastrzeżeń w zgłoszeniu nr 670 są projekt API, dublowanie istniejących mechanizmów, umiędzynarodowienie, prywatność, bezpieczeństwo, przenośność, niejasne przypadki użycia i miejsce prac nad standardem. Wygląda to jak standardowa lista, ale za nią stoi jeden spójny argument. Na tyle mocny, że warto go przeczytać jako tekst o projektowaniu stron, a nie o polityce przeglądarek.

Agent to technologia wspomagająca

Rdzeń stanowiska jest prosty. Agent, który działa w imieniu użytkownika, jest w praktyce technologią wspomagającą, tak jak czytnik ekranu. Powinien więc obsługiwać stronę tak, jak zrobiłby to użytkownik, a strona nie powinna traktować go inaczej. Według WebKit, jeśli agent ma kłopot z interfejsem zbudowanym dla ludzi, to sygnał, że strona ma lukę w semantyce. Tę lukę trzeba zamknąć we wspólnych warstwach, czyli w HTML i ARIA, a nie obchodzić osobnym kanałem. Z naprawy skorzystają wtedy wszyscy: ludzie, czytniki ekranu i agenci.

Aaron Gustafson, od lat zajmujący się dostępnością, streścił tę alternatywę w trzech krokach. Najpierw piszesz etykiety, opisy i semantykę dla ludzi. Potem przeglądarka domyślnie przekazuje je agentowi. Dopiero gdy agent naprawdę potrzebuje czegoś więcej, dodajesz wąskie uzupełnienie tylko dla niego, jako ostatnią deskę ratunku, a nie wymóg.

Gdy widać, że prowadzi agent

Drugi argument jest mniej oczywisty i moim zdaniem najważniejszy. Czytnik ekranu z założenia nie jest dla strony osobną kategorią odwiedzającego. WebMCP robi odwrotnie: to, że stronę obsługuje agent, staje się faktem, który strona może zauważyć. A jeśli może, to nic nie trzyma obu interfejsów w równowadze. Strona może dać agentowi możliwości, których nie ma w interfejsie dla ludzi, a wtedy traci każdy, kto agenta nie używa. Może też odciąć agentom to, co dostają ludzie. WebKit nazywa to problemem blokowania czytników ekranu, tylko przeniesionym na agentów. Specyfikacja ma zresztą mechanizm exposedTo, którym strona sama decyduje, które pochodzenia mogą wołać jej narzędzia.

Niezawodność, której nie ma

Trzeci argument uderza w główną obietnicę WebMCP. Narzędzia miały być pewniejsze niż klikanie po interfejsie. Ale agent i tak wybiera narzędzie po nazwie i opisie w języku naturalnym, a sama specyfikacja przyznaje, że nic nie gwarantuje zgodności zadeklarowanego działania narzędzia z tym, co ono faktycznie robi. Niepewność nie znika, tylko przenosi się z interfejsu do opisu.

Prywatność przez nadmiar pytań

Czwarty argument dotyczy danych. Narzędzie może prosić o więcej parametrów, niż potrzebuje, a uczynny agent uzupełni je tym, co wie o użytkowniku z innych rozmów. Strona dostaje wtedy dane, których człowiek sam by jej nie podał. Ten scenariusz opisał wcześniej zespół Microsoftu w analizie prywatności, na przykładzie zamówienia sukienki, w którym agent sam podaje rozmiar. Do tego dochodzi prompt injection przez opisy narzędzi i zwracane przez nie dane.

Rozwiązanie przed problemem

Ostatni zarzut jest najkrótszy: WebMCP proponuje nowe rozwiązanie, zanim ustalono, na czym właściwie polega problem. Stąd rekomendacja WebKit, żeby na razie odłożyć propozycję. Do tego dochodzi zastrzeżenie co do miejsca prac. Specyfikację rozwija grupa społeczności W3C od uczenia maszynowego, a nie grupy, które odpowiadają za HTML i dostępność.

Co to znaczy w praktyce: Chrome na iPhonie i iPadzie korzysta z silnika WebKit. Dopóki WebKit mówi „nie”, na iOS nie ma WebMCP w żadnej przeglądarce. Strona, która opiera działanie na narzędziach WebMCP, pomija więc wszystkich użytkowników urządzeń Apple.

Odpowiedź Google i zwrot w październiku

Autor propozycji z Google nie wycofał się. Zadał WebKit dwa pytania: czy wystarczyłby WebMCP złożony wyłącznie z wariantu deklaratywnego, czyli atrybutów toolname i tooldescription na zwykłym formularzu, i jakie zmiany, poza usunięciem API w JavaScripcie, uczyniłyby propozycję akceptowalną. Pytanie o wariant deklaratywny było trafne. Formularz z atrybutami nie może rozjechać się ze stroną, bo narzędziem jest sam formularz, ten sam, który widzi człowiek.

A potem stało się coś odwrotnego. 8 października wariant deklaratywny usunięto ze specyfikacji, która skupia się teraz na rejestrowaniu narzędzi w JavaScripcie. Atrybuty formularzy zostały w osobnym dokumencie roboczym i w testowej implementacji Chrome, ale już nie w tekście standardu. Nie wiem, czy ta decyzja ma związek ze stanowiskiem WebKit, i nie będę zgadywał. Efekt jest jednak taki, że z WebMCP wypadła ta część, która była najbliżej postulatu Apple i najbliżej codziennej pracy projektanta stron.

Dlaczego Mozilla czeka

Mozilla oznaczyła WebMCP jako neutralny i zamknęła zgłoszenie 5 sierpnia. Neutralność nie znaczy tu obojętności. Recenzent zaproponował ją z wyraźnym warunkiem: Mozilla wróci do tematu, gdy będzie widać, jak strony naprawdę używają WebMCP. Zostawił też otwarte pytanie, czy rozjazd między narzędziem a stroną wynika z samego API, czy po prostu z tego, że przeglądarką steruje model językowy.

Ciekawe jest, w którą stronę Mozilla się przechyla. W sierpniowej dyskusji jej inżynierowie poparli API w JavaScripcie, a wątpliwości mieli co do wariantu deklaratywnego. To dokładnie odwrotnie niż w pytaniu Google do Apple. Każdy z dwóch silników spoza Chrome skłania się więc ku innej połowie WebMCP. Dlatego trudno dziś wskazać kompromis, który zadowoliłby oba naraz.

Dokąd to zmierza

Są dwa sygnały, które warto śledzić. Pierwszy to projekt statutu grupy roboczej W3C Agentic Web, w którym WebMCP figuruje jako jedna ze specyfikacji do opracowania. Przeniesienie prac z grupy społeczności do grupy roboczej odpowiadałoby na zarzut WebKit o złym miejscu prac. To jednak wciąż projekt, z pustymi miejscami na daty i przewodniczących. Drugi sygnał to koniec testów 30 marca 2027. Około tej daty Google musi zdecydować, czy wnioskuje o wydanie, czy przedłuża test, czy przebudowuje propozycję.

Obraz uzupełniają liczby z praktyki. Autor, który od końca września ma kilka narzędzi WebMCP na produkcji, w październiku notował wywołania przez prawdziwych agentów na poziomie bliskim zera. To jeden przypadek, nie badanie, ale zgadza się z resztą.

Co z tego dla projektanta strony

Zaktualizowałbym czerwcowe rekomendacje tak:

  • Nie sprzedawaj WebMCP klientom jako wdrożenia. Ta rada z czerwca zostaje, a dziś ma mocniejsze uzasadnienie: jedna rodzina przeglądarek, test z datą ważności i formalny sprzeciw silnika, który obsługuje każdego iPhone'a.
  • Jeśli już budujesz narzędzia, rób je jako dodatek, który da się odłączyć. Sprawdzaj dostępność API przed rejestracją, korzystaj z document.modelContext i niech narzędzie będzie cienką nakładką na funkcję, którą człowiek ma też w interfejsie. Narzędzie, które robi coś, czego nie umie interfejs, to dokładnie ten rozjazd, przed którym ostrzega WebKit.
  • Nie inwestuj w atrybuty formularzy. Przeglądarki bez WebMCP je ignorują, więc niczego nie zepsują. Wypadły jednak ze specyfikacji, więc nie warto na nich budować.
  • Rób to, co działało w czerwcu. Semantyczny HTML, pola z etykietami, przyciski, które są przyciskami. Tu Apple i Google są zgodni bardziej, niż się wydaje. Nawet audyt Lighthouse dla agentów liczy do wyniku tylko drzewo dostępności i stabilność układu, a kontrole WebMCP mają w nim wagę zero.

Ocenę zmieniłyby trzy wydarzenia. Gemini w Chrome zacznie sam wywoływać narzędzia na zwykłych stronach. Google przed końcem marca zdecyduje o wydaniu WebMCP w stabilnym Chrome. Mozilla albo WebKit zmienią stanowisko. Wtedy wrócę do tematu.

Na razie najciekawszym tekstem o WebMCP okazało się stanowisko przeciwnika. WebKit nie twierdzi, że agenci są niepotrzebni. Twierdzi, że strona dobrze zrobiona dla ludzi powinna wystarczyć także agentom. Szerzej pisałem o tym w tekście „Ogon, który udaje fundament”: semantyka to fundament, a dodatkowa warstwa dla agentów to ogon, który łatwo z nim pomylić.

Źródła