WebMCP: jak działa, które przeglądarki go obsługują i czy Twoja strona go potrzebuje?

Agenty działające w przeglądarce potrafią już obsługiwać strony internetowe. Interpretują zrzuty ekranu, analizują DOM i drzewo dostępności, a następnie symulują kliknięcia oraz naciśnięcia klawiszy. To działa, dopóki zmiana projektu nie przesunie przycisku, nakładka nie przejmie fokusu albo agent nie zrozumie błędnie pola. Agent odtwarza wtedy zasady interfejsu zaprojektowanego dla ludzi.

WebMCP zapewnia bardziej jednoznaczny kontrakt. Otwarta strona może udostępnić funkcję, na przykład wyszukiwanie produktów, wybór pokoju lub przygotowanie konsultacji, jako nazwane narzędzie z opisem i ustrukturyzowanymi danymi wejściowymi. Agent może wywołać to narzędzie, podczas gdy użytkownik pozostaje w przeglądarce, widzi ten sam stan aplikacji i zachowuje kontrolę nad działaniem wywołującym istotne skutki.

Krótka odpowiedź

WebMCP istnieje i można go testować, ale nadal jest eksperymentalny, a prace nad nim prowadzi przede wszystkim Chrome. Najbardziej przydaje się w procesach wymagających wielu działań, gdy agent ma coś filtrować, konfigurować, rezerwować, wysyłać lub aktualizować. Nie jest powodem do przebudowy prostej strony z treścią ani zamiennikiem integracji backendowych.

Zalecam traktowanie go jako progressive enhancement. Zachowaj interfejs dla człowieka, semantyczny HTML, API aplikacji, autoryzację i walidację. Dodaj niewielką warstwę narzędzi do jednego istniejącego procesu, zmierz, czy agenty potrafią go bezpiecznie ukończyć, i przygotuj się na zmiany tej warstwy wraz z rozwojem wersji roboczej specyfikacji.

Stan zweryfikowany: 22 lipca 2026. Wymienione niżej wersje przeglądarek i szczegóły API są wrażliwe na upływ czasu. Przed podjęciem decyzji o wdrożeniu produkcyjnym ponownie sprawdź podane źródła pierwotne.

Stan WebMCP w lipcu 2026

Łatwo pomylić trzy określenia: wersja robocza Community Group nie jest standardem internetowym, Origin Trial nie oznacza szerokiej obsługi przez przeglądarki, a szacowana wersja docelowa nie jest obietnicą wydania. Aktualna specyfikacja WebMCP i dokument Blink Intent to Experiment potwierdzają następujący obraz sytuacji:

Element	Stan zweryfikowany 22 lipca 2026
Specyfikacja	W3C Web Machine Learning Community Group Draft Report. Wyraźnie nie jest standardem W3C i nie znajduje się na ścieżce standaryzacji W3C.
Wersja próbna Chrome dla twórców	Rozpoczęła się w Chrome 146 i wymaga lokalnej flagi deweloperskiej.
Chrome Origin Trial	Zapowiedziany dla wersji od 149 do 156. Strony muszą się zarejestrować, aby udostępnić eksperyment uprawnionym odwiedzającym.
Szacowana wersja wydania	Chrome 157, wyraźnie jako szacunek, a nie zobowiązanie do wydania.
Gecko	Brak stanowiska w Blink Intent. Nie oznacza to obsługi przez Firefox.
WebKit	Brak stanowiska w Blink Intent. Nie oznacza to obsługi przez Safari.
Aktualny obiekt globalny API	`document.modelContext`. Starsza postać `navigator.modelContext` jest przestarzała od Chrome 150.
Zalecane podejście	Prototypuj jako progressive enhancement. Nie opieraj krytycznej ścieżki klienta wyłącznie na WebMCP.

Według specyfikacji jej redaktorzy są związani z Microsoft i Google. Świadczy to o aktywnym udziale dostawców przeglądarek, ale nie gwarantuje konsensusu ani interoperacyjnej implementacji. Obecnie uczciwy opis brzmi: rozwijane API przeglądarkowe z eksperymentalną implementacją w Chrome.

Czym jest WebMCP?

WebMCP to API przeglądarkowe, dzięki któremu otwarta strona internetowa udostępnia agentom AI funkcje JavaScript jako narzędzia. Każde narzędzie ma nazwę, opis w języku naturalnym i schemat ustrukturyzowanych danych wejściowych. Strona dostarcza kod wykonawczy i zwraca wynik.

Miejsce wykonania ma znaczenie. Narzędzie działa na aktualnej stronie, gdzie może korzystać ze stanu frontendu, uwierzytelnionej sesji użytkownika i istniejących funkcji aplikacji. Konfigurator produktu może udostępnić bieżący wybór. Strona rezerwacji może wystawić tylko narzędzia dostępne po wybraniu dat. Narzędzie finalizacji zakupu może pojawić się dopiero wtedy, gdy koszyk zawiera produkt.

W ten sposób powstaje oparty na współpracy proces w przeglądarce. Użytkownik widzi interfejs. Agent może działać za pośrednictwem jawnie udostępnionych funkcji. Aplikacja nadal egzekwuje swoje reguły. Z narzędzi może korzystać agent wbudowany w przeglądarkę, agent działający jako rozszerzenie albo autoryzowany agent na stronie, zależnie od programu klienckiego przeglądarki (ang. user agent) i sposobu, w jaki strona przyznaje dostęp.

Przydatny model myślowy nie brzmi „strona internetowa staje się serwerem MCP”. Trafniejsze ujęcie to „widoczna strona publikuje w przeglądarce tymczasowy kontrakt narzędzi uwzględniający bieżący stan”. Lista narzędzi może się zmienić, gdy zmienia się strona, użytkownik się loguje albo określone działanie staje się dostępne.

Czym WebMCP nie jest?

WebMCP czerpie inspirację z Model Context Protocol i wykorzystuje znane pojęcia, takie jak narzędzia oraz schematy. Dokument objaśniający WebMCP i porównanie przygotowane przez Chrome jasno wskazują, że WebMCP nie rozszerza, nie transportuje ani nie zastępuje backendowego MCP.

WebMCP nie zastępuje również:

Publicznych ani prywatnych API HTTP, które pozostają niezawodną granicą komunikacji między serwerami.
Opisów OpenAPI używanych do dokumentowania i integrowania tych API.
Semantycznego HTML, etykiet, obsługi klawiatury ani testów dostępności.
Danych strukturalnych, schema.org, llms.txt ani treści dostępnych dla robotów, które pomagają systemom zrozumieć informacje.
Ogólnej automatyzacji przeglądarki, gdy strona nie udostępniła wymaganej funkcji.
Interfejsu dla człowieka, szczególnie na potrzeby przeglądu, poprawek, zgody i wychodzenia z błędów.

Obecny WebMCP wymaga również otwartej strony lub webview. Omówienie WebMCP przygotowane przez Chrome nie przedstawia go jako mechanizmu wywołań headless. Jeśli operacja musi działać po zamknięciu strony, właściwą podstawą jest backendowy serwer MCP lub bezpośrednie API.

WebMCP a MCP, API i automatyzacja przeglądarki

Mechanizmy te częściowo się pokrywają, ale rozwiązują różne problemy operacyjne.

Mechanizm	Miejsce wykonania	Model odkrywania	Sesja i kontekst	Najlepsze zastosowanie	Główne ograniczenie
WebMCP	JavaScript na widocznej stronie	Aktywna strona udostępnia nazwane narzędzia i schematy wejściowe	Współdzieli aktualny stan UI i uwierzytelniony kontekst strony	Działania wspierane przez agenta w interaktywnym procesie	Eksperymentalny, rozwijany głównie przez Chrome i niedostępny po zamknięciu strony
Backendowy MCP	Zdalny serwer lub lokalny proces	Klient MCP wyświetla narzędzia ze skonfigurowanego serwera	Korzysta z własnego połączenia, tożsamości i stanu po stronie serwera	Procesy headless i funkcje usług wielokrotnego użytku	Wymaga osobnej integracji, uwierzytelniania i obsługi kontekstu
Automatyzacja przeglądarki	Kontroler przeglądarki działa na DOM, drzewie dostępności, zrzutach ekranu i danych wejściowych	Agent wywnioskuje możliwe działania z wyrenderowanego UI	Obserwuje aktualną stronę i sesję	Uniwersalne rozwiązanie awaryjne dla stron bez jawnych narzędzi	Selektory i wnioskowanie wizualne bywają kruche lub niejednoznaczne
OpenAPI lub bezpośrednie API	Usługa backendowa	Klient zna endpoint lub odczytuje opis API	Używa danych uwierzytelniających API i stanu żądania	Stabilna integracja między aplikacjami	Nie współdzieli automatycznie stanu otwartej strony ani interfejsu do przeglądu
Treść semantyczna	Dokumenty i wyrenderowane znaczniki	Roboty lub agenty analizują HTML, dane strukturalne i pliki tekstowe	Głównie informacyjny kontekst strony	Zrozumienie, pobieranie i odkrywanie treści	Opisuje informacje, ale sama nie zapewnia bezpiecznej umowy dotyczącej działań

Używaj WebMCP, gdy sesja przeglądarki i widoczny stan są częścią wartości rozwiązania. Wybierz backendowy MCP lub API, gdy funkcja musi być trwała, działać w trybie headless albo być dostępna niezależnie od otwartej karty. Zachowaj automatyzację przeglądarki jako rozwiązanie awaryjne dla działań bez jawnego narzędzia. Dbaj o treści semantyczne, ponieważ agenty i ludzie nadal muszą zrozumieć stronę przed podjęciem decyzji o działaniu.

Jak przebiega interakcja z WebMCP?

Dobrze zaprojektowana interakcja podąża za rzeczywistym stanem strony, zamiast publikować wszystkie możliwe działania naraz:

Użytkownik otwiera witrynę w obsługiwanym środowisku przeglądarki.
Strona rejestruje narzędzia odpowiednie dla bieżącej ścieżki, użytkownika i stanu aplikacji.
Agent odkrywa nazwy narzędzi, opisy, adnotacje i schematy wejściowe.
Agent wybiera narzędzie i przekazuje ustrukturyzowane argumenty.
Istniejąca logika aplikacji sprawdza żądanie i wykonuje operację.
Strona zwraca jednoznaczny wynik i synchronizuje widoczny interfejs.
Operacja wrażliwa lub destrukcyjna zatrzymuje się w punkcie wymagającym wyraźnej decyzji użytkownika.

Przeglądarka pośredniczy między agentem AI a ustrukturyzowanymi narzędziami strony do wyszukiwania, rezerwacji i finalizacji zakupu.

W tym procesie przeglądarka pośredniczy w wywołaniach i wyznacza ich granicę. Narzędzie strony wywołuje istniejące funkcje frontendu i backendu w widocznym dla użytkownika kontekście przeglądarki. Nie jest to zdalne narzędzie potajemnie omijające aplikację. Jeśli agent dodaje produkt, koszyk na stronie powinien go pokazać. Jeśli dostępność się zmieni, nieaktualny wybór powinna odrzucić ta sama walidacja, której używa interfejs dla człowieka.

Dynamiczna rejestracja jest ważna. Narzędzie wyszukiwania tylko do odczytu może być dostępne od razu, a narzędzie rezerwacji powinno pojawić się dopiero po wybraniu odpowiedniego pokoju i wprowadzeniu danych gościa. Usuwanie nieaktualnych narzędzi ogranicza dezorientację agenta i utrzymuje zgodność umowy z tym, co rzeczywiście może zrobić UI.

Dwa sposoby dodania WebMCP do strony internetowej

Aktualne materiały Chrome opisują API deklaratywne i imperatywne. Oba powinny rozszerzać interfejs, który już działa dla człowieka.

Narzędzia deklaratywne dla widocznych formularzy

API deklaratywne dodaje toolname, tooldescription i opcjonalne opisy parametrów do semantycznego formularza:

<form
  toolname="request_consultation"
  tooldescription="Prepare a consultation request for an AI agent implementation."
  action="/api/consultation"
  method="post"
>
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" autocomplete="email" required />

  <label for="goal">What should the agent accomplish?</label>
  <textarea
    id="goal"
    name="goal"
    toolparamdescription="The business goal, current workflow, and expected outcome."
    required
  ></textarea>

  <button type="submit">Review request</button>
</form>

Pominięcie toolautosubmit sprawia, że formularz pozostaje widoczny do sprawdzenia, zamiast pozwalać agentowi wysłać go automatycznie. Jest to właściwe ustawienie domyślne dla leada, zakupu, rezerwacji, usunięcia danych lub innej operacji wywołującej istotne skutki. Użytkownik może sprawdzić i poprawić wypełnione pola przed naciśnięciem zwykłego przycisku.

Ta adnotacja nie sprawia, że przesłane dane stają się godne zaufania. Walidacja w przeglądarce poprawia doświadczenie użytkownika, ale standardowe uwierzytelnianie, autoryzacja i walidacja po stronie serwera, ograniczanie liczby żądań oraz zabezpieczenia przed nadużyciami pozostają obowiązkowe.

Narzędzia imperatywne dla logiki aplikacji

API imperatywne pasuje do interfejsów zależnych od stanu i funkcji, których nie da się naturalnie przedstawić za pomocą jednego formularza:

const modelContext = document.modelContext;

if (modelContext && typeof modelContext.registerTool === "function") {
  const controller = new AbortController();

  await modelContext.registerTool(
    {
      name: "find_services",
      description:
        "Find WebsiteInit services relevant to a business goal. Returns matching service names and URLs.",
      inputSchema: {
        type: "object",
        properties: {
          goal: {
            type: "string",
            minLength: 10,
            maxLength: 500,
            description: "The business or engineering outcome the user wants.",
          },
        },
        required: ["goal"],
        additionalProperties: false,
      },
      annotations: {
        readOnlyHint: true,
        untrustedContentHint: false,
      },
      async execute({ goal }) {
        if (typeof goal !== "string" || goal.trim().length < 10) {
          return { status: "error", message: "Describe the goal in at least 10 characters." };
        }

        return {
          status: "success",
          services: findRelevantServices(goal),
        };
      },
    },
    { signal: controller.signal },
  );

  window.addEventListener("pagehide", () => controller.abort(), { once: true });
}

findRelevantServices oznacza istniejącą logikę aplikacji współdzieloną z interfejsem dla człowieka, a nie drugą implementację reguł biznesowych. Warstwa narzędzia opisuje funkcję, sprawdza dane wejściowe przekazane przez agenta i zwraca użyteczny wynik. Funkcja bazowa powinna pozostać tą samą, której strona używa, gdy człowiek wyszukuje lub filtruje treści.

Wykrywanie funkcji zabezpiecza przeglądarki bez eksperymentalnego API. AbortSignal wiąże rejestrację z cyklem życia strony, dzięki czemu nawigacja nie pozostawia po sobie nieaktualnej funkcji. W aplikacji jednostronicowej zastosuj tę samą zasadę po odmontowaniu komponentu albo utracie ważności działania zależnego od stanu.

Nazwy i opisy wymagają uwagi inżynierskiej. Narzędzie o nazwie do_action z niejasnym schematem ponownie przerzuca niejednoznaczność na model. Wybierz precyzyjny czasownik, pola o określonych granicach, opisowe błędy i tylko parametry niezbędne dla danej operacji.

Gdzie WebMCP zapewnia rzeczywistą wartość?

Najlepszymi kandydatami są procesy obejmujące istotne działanie i na tyle trudne w obsłudze, że jawna umowa upraszcza pracę:

Wyszukiwanie i filtrowanie według wielu ograniczeń, takich jak daty, lokalizacja, pojemność, cena czy zgodność.
Długie formularze, w których użytkownik opisuje cel w języku naturalnym, pozwala agentowi przygotować pola, a następnie sprawdza wynik.
Konfiguracja produktu i budowanie koszyka, gdy wybory muszą pozostać zsynchronizowane z widocznym stanem.
Procesy rezerwacji wymagające wykonania kroków w określonej kolejności i ostatecznego potwierdzenia.
Obsługa klienta lub diagnostyka, w których narzędzie może zebrać istotny stan strony bez ujawniania niepowiązanych danych.
Uwierzytelnione procesy, których przydatny kontekst już znajduje się w otwartej aplikacji.

Wspólny wzorzec nie brzmi „AI na stronie internetowej”. Chodzi o proces, w którym dobór właściwego działania i argumentów jest na tyle trudny, że uzasadnia użycie schematu, lecz użytkownik nadal odnosi korzyść z oglądania i kontrolowania wyniku.

Równie ważne są nietrafione zastosowania. Serwis redakcyjny bez istotnych działań powinien najpierw zainwestować w jasną treść, semantyczny HTML, dostępność i dane strukturalne. Proces działający w tle powinien korzystać z API lub backendowego MCP. Stabilna funkcja serwera już dostępna przez te kanały nie potrzebuje warstwy przeglądarkowej, chyba że współdzielony kontekst strony wyraźnie poprawia doświadczenie. Operacja wysokiego ryzyka bez wiarygodnego modelu potwierdzeń, autoryzacji i audytu nie powinna stać się narzędziem dla agenta.

Cztery działające serwisy do testowania agenta

Zbudowałem cztery niewielkie serwisy, aby testy były konkretne. Każdy działa za pośrednictwem zwykłego UI i udostępnia kompletny proces. Poniższe łącza prowadzą do kodu źródłowego i działających wersji demonstracyjnych.

Serwis	Repozytorium i demo	Proces i przykładowe narzędzia	Sugerowane polecenie dla agenta	Granica potwierdzenia
Sklep	Repozytorium, demo na żywo	Wyszukiwanie produktów, sprawdzanie szczegółów, dodawanie i aktualizowanie pozycji w koszyku, przegląd koszyka, finalizacja zakupu	„Znajdź butelkę na wodę za mniej niż 100 PLN, dodaj jedną do koszyka i pokaż mi końcowe zamówienie przed finalizacją zakupu.”	Zatrzymaj się przed potwierdzeniem zamówienia.
Noclegi	Repozytorium, demo na żywo	Wyszukiwanie celu podróży, filtrowanie noclegów, wybór pokoju, dodawanie danych gości, rezerwacja	„Znajdź nocleg w Lizbonie dla dwóch dorosłych od 12 do 15 sierpnia 2026, wybierz pokój i przygotuj rezerwację.”	Zatrzymaj się przed zarezerwowaniem noclegu.
Linie lotnicze	Repozytorium, demo na żywo	Wyszukiwanie lotnisk i lotów, wybór każdego odcinka, dodawanie pasażerów, rezerwacja	„Zaplanuj podróż z Warszawy do Paryża 15 sierpnia 2026, a następnie z Paryża do Rzymu 18 sierpnia dla dwóch dorosłych, i przygotuj rezerwację.”	Zatrzymaj się przed zarezerwowaniem lotu.
Strona firmowa	Repozytorium, demo na żywo	Odczyt informacji o firmie i produktach, pobieranie danych kontaktowych, przygotowanie formularza kontaktowego	„Wyjaśnij, czym jest ACME Drive X, a następnie przygotuj zapytanie z prośbą o konsultację techniczną.”	Wypełnij widoczny formularz, ale wyśle go użytkownik.

Projekty zawierają natywny eksperymentalny WebMCP oraz ścieżkę MCP-B. MCP-B to most zgodności i polyfill, dzięki któremu istniejące agenty MCP mogą przez przekaźnik uzyskać dostęp do narzędzi na stronie. Przydaje się obecnie do rozwijania logiki agenta, ale korzysta z innej ścieżki transportu. Sukces przez MCP-B nie dowodzi natywnej interoperacyjności przeglądarek.

Korzystaj z wersji demonstracyjnych, aby badać zachowanie, a nie po to, by uzyskać jeden udany wynik. Powtórz polecenie ze zmienionymi ograniczeniami, nieprawidłowymi danymi i przerwanym procesem. Sprawdź, czy agent zadaje przydatne pytanie, gdy brakuje informacji, oraz czy zatrzymuje się na wskazanej granicy potwierdzenia.

Jak testować implementację WebMCP?

Zacznij lokalnie w wersji Chrome objętej testami deweloperskimi. Włącz flagę testową WebMCP w chrome://flags, uruchom przeglądarkę ponownie i wczytaj stronę w wymaganym bezpiecznym lub lokalnym środowisku deweloperskim. Aby przeprowadzić eksperyment na działającej stronie w wersjach od 149 do 156, zarejestruj origin w programie Chrome Origin Trials i postępuj zgodnie z instrukcjami wdrażania tokena dla tej wersji próbnej. Rejestracja nie oznacza obsługi przez różne przeglądarki.

Model Context Tool Inspector i powiązane narzędzia GoogleChromeLabs zapewniają pierwszy praktyczny cykl testów. Sprawdź listę narzędzi, przeczytaj każdy opis z perspektywy agenta i zweryfikuj wygenerowany lub dostarczony JSON Schema. Ręcznie wykonuj wywołania z prawidłowymi argumentami, wartościami granicznymi i nieprawidłowymi argumentami. Potwierdź, że wyniki są ustrukturyzowane, a błędy wyjaśniają agentowi sposób naprawy.

Wywołania ręczne oddzielają zachowanie aplikacji od zachowania modelu. Wytyczne Chrome dotyczące evali zalecają testy na obu poziomach:

Deterministyczne testy aplikacji sprawdzają walidację, zależności, synchronizację UI, zwracane wartości, decyzje autoryzacyjne, ochronę przed powtórzeniem wywołania oraz ścieżki błędów. Uruchamiaj je jak zwykłe testy jednostkowe i integracyjne, bez polegania na modelu.
Probabilistyczne testy ewaluacyjne agentów mierzą, czy model wybiera właściwe narzędzie, przekazuje prawidłowe argumenty, wykonuje wywołania w poprawnej kolejności i interpretuje wyniki dla promptów bezpośrednich, niejednoznacznych, niepełnych oraz złośliwych (kontradyktoryjnych).

Przydatny protokół oceny obejmuje sześć pytań:

Czy agent potrafi wybrać właściwe narzędzie dla zamiaru użytkownika?
Czy przekazuje argumenty zgodne zarówno ze schematem, jak i regułami dziedzinowymi?
Czy wywołuje wiele narzędzi we właściwej kolejności?
Czy widoczne UI pozostaje zgodne z każdym wynikiem narzędzia?
Czy agent zatrzymuje się przed ostatecznym działaniem wywołującym istotne skutki, aby poprosić o potwierdzenie?
Czy potrafi odzyskać kontrolę po otrzymaniu nieprawidłowych danych wejściowych lub napotkaniu niedostępnego już stanu aplikacji?

Zapisuj polecenie, aktywny zestaw narzędzi, początkowy stan aplikacji, przewidywane i rzeczywiste wywołania, wynik oraz sposób obsługi potwierdzenia. Uwzględnij narzędzia, których agent nie powinien wybrać, ponieważ jakość wyboru zależy od alternatyw widocznych dla modelu. Uruchamiaj ten sam zbiór danych po zmianie opisów, schematów, modeli lub wersji przeglądarki. Zielony test aplikacji i przypadkowo udana demonstracja nie dowodzą niezawodnego działania agenta.

Bezpieczeństwo, prywatność i scenariusze awarii

WebMCP tworzy wewnątrz strony nową granicę, przez którą można wywoływać funkcje. Omówienie bezpieczeństwa w wersji roboczej i wytyczne Chrome dotyczące bezpiecznych narzędzi wskazują istotne zagrożenia, takie jak prompt injection, zatruwanie narzędzi, ujawnianie nadmiernej ilości danych i fałszywe przedstawienie zamiaru użytkownika.

Prompt injection może pochodzić bezpośrednio z instrukcji użytkownika albo pośrednio z treści odczytanej przez agenta. Zatruwanie narzędzia może wynikać z mylącej nazwy lub opisu, które ukrywają rzeczywiste skutki wykonania. Zbyt szerokie schematy mogą skłaniać agenta do przekazywania danych osobowych lub kontekstu z innych stron, których operacja nie potrzebuje. Pozornie rozsądne wywołanie może nadal dotyczyć niewłaściwej osoby, konta, pozycji albo ostatecznego zamiaru.

Traktuj agenta jako niezaufanego klienta. Narzędzie przeglądarkowe nie może nigdy stać się skrótem omijającym autoryzację. Przy każdym żądaniu zmieniającym stan serwer musi uwierzytelnić sesję, autoryzować określone działanie i zasób, sprawdzić dane wejściowe względem aktualnych danych, egzekwować granice dzierżawców i stosować te same reguły biznesowe co ścieżka dla człowieka.

Mechanizmy zabezpieczające powinny być widoczne w projekcie:

Publikuj wąskie narzędzia świadome stanu i udostępniaj tylko parametry niezbędne dla danego działania.
Świadomie stosuj ograniczenia origin. Sprawdź delegowanie w iframe i Permissions Policy tools, zamiast przypadkowo udostępniać funkcje zbyt szeroko.
Ustawiaj readOnlyHint zgodnie z prawdą. Wyszukiwanie jest operacją tylko do odczytu, lecz dodanie produktu do koszyka lub zmiana rezerwacji nią nie jest.
Ustawiaj untrustedContentHint zgodnie z prawdą, gdy zwracana treść może zawierać niezaufane materiały. Nie oznaczaj wyniku jako zaufanego tylko dlatego, że zwróciła go Twoja funkcja.
Wymagaj wyraźnego potwierdzenia zakupów, rezerwacji, wysyłania formularzy, usuwania danych, zmian uprawnień i nieodwracalnych operacji.
Zapewnij idempotencję wywołań wywołujących istotne skutki albo zabezpiecz je transakcją lub kluczem idempotencji. Agenty i warstwy transportu mogą ponowić lub zduplikować wywołanie.
Prowadź dzienniki audytowe uwierzytelnionych wywołań narzędzi, obejmujące wykonawcę, narzędzie, sprawdzone argumenty lub bezpieczne odwołania, wynik i zapis potwierdzenia.
Zwracaj opisowe błędy bez danych wrażliwych, które umożliwiają naprawę bez wycieku informacji.

Celowo testuj nieprawidłowy stan: produkt wyprzedaje się po wyborze, sesja wygasa, pokój staje się niedostępny, zmienia się autoryzacja albo to samo żądanie przychodzi dwa razy. Narzędzie powinno odrzucić nieaktualne założenia, odświeżyć widoczne UI i wskazać agentowi bezpieczny kolejny krok. Przywracanie poprawnego działania jest częścią kontraktu, a nie przypadkiem brzegowym, który można odłożyć.

Co WebMCP zmienia w istniejącej stronie internetowej?

Dobra implementacja zmienia mniej, niż sugeruje nazwa. Interfejs dla człowieka pozostaje najważniejszy. Semantyczne formularze, etykiety, komunikaty walidacyjne, obsługa klawiatury i stan dostępności nadal stanowią podstawę. WebMCP nie poprawia bezpośrednio pozycji SEO, nie zastępuje semantycznego HTML ani dostępności i nie powinien być sprzedawany jako funkcja SEO.

Warstwa narzędzi przeglądarkowych dodaje schematy, opisy, cykl życia rejestracji, zabezpieczenia, evale i obowiązek śledzenia specyfikacji. Narzędzia imperatywne powinny otaczać istniejące funkcje dziedzinowe, zamiast tworzyć osobną wersję reguł. Narzędzia deklaratywne powinny opisywać użyteczne formularze, zamiast je ukrywać. Wykrywanie funkcji powinno pozostawiać zwykłą stronę użytkownikom nieobsługiwanych przeglądarek.

Obecne narzędzia są powiązane z widoczną stroną lub webview. Nie są działającym w tle API całej witryny. Rejestracja powinna podążać za ścieżką, uwierzytelnieniem i stanem komponentu, aby dostępna umowa pozostawała zgodna z prawdą. Wylogowanie musi usunąć uwierzytelnione funkcje. Nawigacja nie może pozostawiać aktywnych, nieaktualnych narzędzi.

Sposób odkrywania różni się również zależnie od typu agenta. Agenty wbudowane w przeglądarkę odkrywają narzędzia przez wewnętrzną integrację programu klienckiego przeglądarki. Dla autoryzowanych agentów działających na stronie aktualna wersja robocza Community Group definiuje getTools() do odkrywania udostępnionych narzędzi. Wytyczne Chrome dotyczące API imperatywnego osobno dokumentują executeTool() do wywoływania odkrytego narzędzia. Metoda ta nie jest obecnie zdefiniowana w wersji roboczej Community Group. Nadal mają zastosowanie odpowiednie zabezpieczenia origin i Permissions Policy. Nie oznacza to, że dowolne skrypty na stronie powinny otrzymać szeroki dostęp. Przyznawaj go tylko zamierzonemu origin i kontekstowi oraz śledź zmiany wersji roboczej i implementacji przed wdrożeniem integracji opartej na tych metodach.

Praktycznym kosztem jest ciągłe utrzymanie. Ktoś musi aktualizować schematy po zmianie reguł biznesowych, wycofywać narzędzia po zniknięciu stanów UI, ponownie testować wybory modelu, przeglądać założenia bezpieczeństwa i śledzić zmiany eksperymentalnego API. Progressive enhancement ogranicza skutki tej zmienności.

Czy warto wdrożyć WebMCP już teraz?

Odpowiedź zależy bardziej od procesu i modelu ryzyka niż od entuzjazmu wobec agentów.

Rodzaj strony lub produktu	Zalecane działanie teraz	Powód
Strona z treścią	Obserwuj rozwój. Najpierw popraw semantyczny HTML, dostępność, dane strukturalne i treści dostępne dla robotów.	Strona może nie oferować żadnego ważnego działania, które mogłoby wykonać jej narzędzie.
Strona pozyskująca leady ze złożonym formularzem	Uruchom mały prototyp deklaratywny z widocznym etapem przeglądu.	Przygotowanie formularza ma ograniczony zakres, można je testować i zachować zwykły sposób wysyłania.
Transakcyjny sklep internetowy lub aplikacja rezerwacyjna	Prototypuj jeden wartościowy proces jako progressive enhancement.	Wspólna sesja i stan UI mogą mieć znaczenie, ale zabezpieczenia potwierdzeń i ponowień są niezbędne.
Twórca agentów lub dostawca automatyzacji przeglądarki	Testuj teraz na kilku realistycznych stronach i utrzymuj zestaw evali.	Potrzebujesz dowodów dotyczących wyboru narzędzi, kolejności, rozwiązań awaryjnych i zachowania przeglądarki.
Proces regulowany lub wysokiego ryzyka	Ogranicz się do badań i środowiska sandbox.	Potwierdzenia, audytowalność, ochrona prywatności i obsługa przeglądarek wymagają większej dojrzałości.

W przypadku odpowiedniego prototypu świadomie ogranicz zakres wdrożenia:

Opisz jeden ważny proces użytkownika i jego obecne scenariusze awarii.
Przebuduj współdzieloną logikę biznesową tak, aby interfejs dla człowieka i narzędzie wywoływały te same funkcje.
Najpierw udostępnij narzędzia do odkrywania lub wyszukiwania tylko do odczytu.
Dodaj jedno odwracalne narzędzie zmieniające stan i przetestuj zduplikowane wywołania.
Umieść wyraźne potwierdzenie człowieka przed ostatecznym działaniem wywołującym istotne skutki.
Uruchom deterministyczne testy, probabilistyczne testy ewaluacyjne agentów i scenariusze nadużyć wykorzystujących prompt injection.
Zachowaj wyłącznik awaryjny i monitoruj stan specyfikacji oraz Chrome Origin Trial.

Takie podejście dostarcza użytecznych dowodów, nie uzależniając produktu od eksperymentalnej technologii. Jeśli prototyp nie usprawnia rzeczywistego procesu, usuń go. Lista narzędzi nie jest wynikiem biznesowym.

Czy WebMCP ma przyszłość?

Zweryfikowane sygnały są znaczące, ale ograniczone: istnieje aktywna wersja robocza Community Group, redaktorzy z Microsoft i Google, testy deweloperskie Chrome oraz Origin Trial, publiczne narzędzia i działające wersje demonstracyjne. Żaden z tych faktów nie dowodzi interoperacyjnej obsługi w wydanych przeglądarkach ani popytu ze strony użytkowników.

Moja ocena

Kierunek jest strategicznie interesujący, ponieważ jawna umowa narzędziowa może zmniejszyć zależność agenta od kruchej obsługi UI, a jednocześnie zachować w procesie stronę, sesję i widoczny dla użytkownika interfejs. W przypadku opartych na współpracy procesów w przeglądarce jest to lepsze dopasowanie architektoniczne niż założenie, że każda interakcja powinna przenieść się do zdalnej integracji z czatem.

Przyszłość WebMCP nadal zależy od pięciu nierozstrzygniętych kwestii: obsługi przez różne przeglądarki, dostępności agentów w rzeczywistych środowiskach użytkowników, UX bezpieczeństwa jasno komunikującego zamiar i potwierdzenie, ergonomii programistycznej ułatwiającej zarządzanie cyklem życia i schematami oraz wykazanego popytu na procesy wspierane przez agentów. Niespełnienie choćby jednego z tych warunków może ograniczyć WebMCP do eksperymentów lub wyspecjalizowanych agentów.

Na podstawie obecnych dowodów nie przewidywałbym powszechnej adopcji, nowych kanałów ruchu, wypierania platform handlowych ani wzrostu wydajności. Zainwestowałbym dość, aby zrozumieć ten model, prototypować tam, gdzie kontekst przeglądarki rzeczywiście ma znaczenie, i zachować możliwość wymiany integracji.

Lista gotowości do wdrożenia WebMCP

Przed udostępnieniem pierwszego narzędzia upewnij się, że:

Źródła i dalsza lektura

Twierdzenia wrażliwe na zmianę stanu sprawdzono 22 lipca 2026 na podstawie źródeł pierwotnych: