Języki

WebMCP

WebMCP pozwala stronie internetowej udostępnić ustrukturyzowane narzędzia agentowi AI w przeglądarce. Dowiedz się, czym różni się od MCP, co wspiera Chrome, zagrożenia bezpieczeństwa i kiedy warto czekać.

Opublikowano po raz pierwszy: 17 lip 2026 · Ostatnia aktualizacja: 3 sie 2026 · Advanced
Języki
AIAutor:AI v2
1 sygnał dowodowy na tej stronie

WebMCP to eksperymentalny interfejs API przeglądarki, który pozwala otwartej stronie internetowej oferować ustrukturyzowane narzędzia agentowi AI. Jest przydatny do ograniczonych działań na stronie, a nie do odkrywania stron ani rankingów. Od 17 lipca 2026 r. jest to szkic Community Group i próba origin Chrome 149; obecne przykłady Chrome używają document.modelContext, podczas gdy navigator.modelContext jest przestarzały w Chrome 150.

TL;DR — WebMCP udostępnia narzędzia należące do strony z document.modelContext agentowi w aktywnym kontekście przeglądania. Imperatywne API rejestruje nazwę, opis, wejście JSON Schema, adnotacje i asynchroniczne wywołanie zwrotne; narzędzia mogą być zależne od stanu i wyrejestrowywane za pomocą AbortSignal. Chrome dokumentuje również deklaratywną warstwę formularzy, ale szkic Community Group z 10 lipca 2026 r. nadal oznacza swoją sekcję deklaratywną jako TODO. Funkcja jest w próbie origin Chrome 149, a nie stabilnym, wieloprzeglądarkowym standardzie. Traktuj ją jako progresywne ulepszenie, a nie infrastrukturę SEO, i zabezpiecz ją jako uwierzytelnioną powierzchnię aplikacji.

Evidence for this claim Chrome documents declarative form annotations such as toolname and tooldescription, but the declarative section of the July 10, 2026 Community Group draft is still marked TODO. Scope: secure browser context Confidence: high · Verified: WebMCP Draft Community Group Report

Jak WebMCP działa w przeglądarce

Użyteczny cykl życia WebMCP zaczyna się i kończy na stronie. Strona rejestruje tylko te działania, które są ważne w jej bieżącym stanie; agent już działający w tym kontekście przeglądania odkrywa i wywołuje jedno z nich; strona wykonuje swoją normalną logikę aplikacji, aktualizuje widoczny dla człowieka interfejs i zwraca ograniczony wynik. Gdy stan się zmienia, strona usuwa narzędzia, które już nie mają zastosowania. Evidence for this claim The imperative API registers named, described, schema-constrained callbacks and supports state-aware cleanup with AbortSignal plus tool-set change notifications. Scope: Current draft and Chrome experiment; API details may change before stable release. Confidence: high · Verified: WebMCP ModelContext API Chrome: WebMCP Imperative API

WebMCP tools should follow the page's real state: register a valid action, execute the same logic as the UI, and remove it when the action is no longer available. Źródło: Patrick Stox — WebMCP

Five numbered steps run left to right. First, the page registers a name, description, input schema, and callback. Second, an agent already in the page context discovers it. Third, the agent invokes it with validated structured arguments. Fourth, the page reuses its normal application logic and updates the visible interface. Fifth, it returns a bounded result or safe error. A branch from execution shows that state changes or navigation should unregister the tool with AbortSignal and notify observers through toolchange.

© Patrick Stox LLC · CC BY 4.0 ·

Ten stanowy cykl życia jest jednym z powodów, dla których WebMCP nie powinien stać się statycznym zrzutem każdej funkcji w pakiecie JavaScript. Narzędzie, które jest niemożliwe w widocznym interfejsie, powinno zwykle być niedostępne również dla agenta.

WebMCP a MCP: dwie różne granice działania

Nazwy zachęcają do zamieszania, ale granica operacyjna jest inna. WebMCP żyje w pętli zdarzeń dokumentu i bieżącej sesji przeglądarki. Zdalny MCP żyje na granicy integracji aplikacji AI i zwykle sięga do trwałego serwera backendowego. Evidence for this claim WebMCP is designed for tools owned by an active page and its browser context, while remote MCP commonly connects an AI application to a persistent backend server. Scope: Architecture-selection guidance, not a rule that prevents an application from using both technologies. Confidence: high · Verified: Chrome: When to use WebMCP and MCP

WebMCP owns page-context actions; remote MCP owns durable application-to-server integrations. Many products will use both. Źródło: WebMCP

The left lane shows WebMCP: a browser agent interacts with an open web page, which owns a JavaScript tool and current visible session state. The page must be open for those tools to exist. The right lane shows remote MCP: an AI application connects through an MCP client to a persistent MCP server, which can remain available outside a browser tab. The two lanes are complementary rather than replacements.

© Patrick Stox LLC · CC BY 4.0 ·

InterfejsGdzie żyjeKiedy jest odkrywanyStrona musi być otwarta?Najlepsze dopasowanie
WebMCPAktywny dokument przeglądarkiPo odwiedzeniu strony przez klientaTakBieżący stan interfejsu i działania strony
Zdalny MCPKlient AI i serwer MCPPoprzez konfigurację klienta/serwera lub odkrywanieNieTrwałe narzędzia, dane i przepływy pracy backendu
Punkt końcowy Web/APIBackend aplikacjiPoprzez integrację specyficzną dla aplikacjiNieStabilny programowy dostęp dla znanych konsumentów
Dane strukturalneZnaczniki stronyPodczas przetwarzania stronyZwykle pobierane jako treśćOpisywanie encji i znaczenia strony, nie wykonywanie działań
llms.txtStatyczny plik tekstowyGdy klient zdecyduje się go zażądaćNie wymaga aktywnej kartyProponowane wskazówki dotyczące treści; nie wywoływalna powierzchnia narzędzi
Automatyzacja przeglądarkiAgent/kontroler interpretujący interfejsPo załadowaniu i sprawdzeniu stronyTakZastępcze rozwiązanie, gdy nie istnieje jawne narzędzie strony

Nie wybieraj na podstawie akronimu. Wybieraj na podstawie właściciela działania. Jeśli działanie wymaga bieżącego DOM, zaznaczenia, koszyka lub stanu interfejsu, WebMCP może pasować. Jeśli musi działać w tle, na wielu stronach lub bez otwartej karty, użyj API lub zdalnego MCP.

API imperatywne

API imperatywne rejestruje narzędzie przez document.modelContext.registerTool(). Narzędzie zawiera unikalną nazwę, opis, schemat JSON Schema, wywołanie zwrotne execute oraz opcjonalne adnotacje. Chrome dokumentuje również getTools(), executeTool() do testowania oraz zdarzenie toolchange. Evidence for this claim Current Chrome documentation uses document.modelContext and says navigator.modelContext is deprecated beginning in Chrome 150. Scope: Chrome implementation guidance checked July 17, 2026; version and API-name claims expire quickly. Confidence: high · Verified: Chrome: WebMCP Imperative API

Ten ilustracyjny kandydat pokazuje zamierzony kształt przyszłego pilotażu Walidatora Schematów. Nie działa na tej stronie, a API może się zmienić przed stabilną wersją:

if (document.modelContext) {
  const registration = new AbortController();

  await document.modelContext.registerTool({
    name: 'validate_schema',
    description: 'Validate pasted JSON-LD and return bounded issues.',
    inputSchema: {
      type: 'object',
      properties: {
        markup: {
          type: 'string',
          description: 'JSON-LD markup to validate.',
          maxLength: 50000
        }
      },
      required: ['markup'],
      additionalProperties: false
    },
    annotations: {
      readOnlyHint: true,
      untrustedContentHint: true
    },
    execute: async ({ markup }) => {
      const result = await validateWithTheSameEngineAsTheUI(markup);
      renderResultInTheVisibleUI(result);
      return minimizeValidationResult(result);
    }
  }, { signal: registration.signal });

  // When this page state no longer supports validation:
  // registration.abort();
}

Ważna architektura to nie opakowanie. Chodzi o to, że wywołanie zwrotne wywołuje ten sam walidator co widoczny interfejs, limity po stronie serwera i autoryzacja nadal obowiązują, a odpowiedź jest celowo zminimalizowana. Wykrywanie funkcji zachowuje pełny przepływ pracy człowieka w nieobsługiwanych przeglądarkach.

Używaj document.modelContext, a nie nieaktualnych przykładów opartych na navigator.modelContext; Chrome oznacza to drugie jako przestarzałe począwszy od Chrome 150. Datuj tę poradę, ponieważ funkcja pozostaje eksperymentalna.

Evidence for this claim Current Chrome documentation uses document.modelContext; navigator.modelContext is deprecated in Chrome 150. Scope: browser document Confidence: high · Verified: WebMCP Imperative API

API deklaratywne ma niezgodność ze standardami

Chrome dokumentuje podejście deklaratywne, które adnotuje zwykłe formularze atrybutami takimi jak toolname, tooldescription i toolparamdescription. Dokumentuje również opcjonalny toolautosubmit; w przeciwnym razie użytkownik klika Wyślij. SubmitEvent.agentInvoked identyfikuje przesłanie wywołane przez agenta. Evidence for this claim Chrome documents declarative WebMCP form annotations, but the July 10, 2026 Community Group draft says its Declarative WebMCP section is entirely TODO. Scope: A direct comparison between Chrome implementation documentation and the current draft; it does not imply Chrome's experimental implementation is unavailable. Confidence: high · Verified: Chrome: WebMCP Declarative API WebMCP: Declarative WebMCP

Jednak raport Community Group z 10 lipca mówi, że sekcja Declarative WebMCP jest “entirely a TODO” i pozostawia algorytm formularz-do-JSON-Schema niezdefiniowany. To nie oznacza, że eksperyment Chrome jest fikcyjny. Oznacza, że dokumentacja implementacji wyprzedza normatywny szkic. Traktuj znaczniki deklaratywne jako eksperymentalną powierzchnię Chrome, a nie ustalony międzyprzeglądarkowy HTML.

Evidence for this claim Chrome documents declarative WebMCP form annotations, but the July 10, 2026 Community Group draft says its Declarative WebMCP section is entirely TODO. Scope: A direct comparison between Chrome implementation documentation and the current draft; it does not imply Chrome's experimental implementation is unavailable. Confidence: high · Verified: Chrome: WebMCP Declarative API WebMCP: Declarative WebMCP

Na razie zwykłe semantyczne formularze pozostają trwałą podstawą. Eksperymentalna warstwa adnotacji powinna je ulepszać, nigdy nie zastępować etykiet, walidacji, dostępności, potwierdzenia ani autoryzacji po stronie serwera.

Odkrywanie narzędzi, cykl życia i granice między pochodzeniami

Obecne API ma kilka granic, które warto zaprojektować jawnie:

  • Kontekst przeglądarki: eksperyment Chrome wymaga kontekstu przeglądarki. Klient odwiedza witrynę, zanim odkryje jej narzędzia.
  • Dynamiczna dostępność: rejestruj narzędzia, gdy są ważne, i przerywaj ich rejestrację, gdy stan lub nawigacja je unieważnia. Obserwatorzy mogą nasłuchiwać zdarzenia toolchange.
  • To samo pochodzenie domyślnie: polityka uprawnień tools domyślnie ustawia 'self'. Iframe’y między pochodzeniami wymagają jawnej delegacji, takiej jak allow="tools".
  • Dwustronna zgoda między pochodzeniami: narzędzie może użyć exposedTo, aby wymienić dozwolone bezpieczne pochodzenia, podczas gdy wywołujący żąda narzędzi z nazwanych pochodzeń za pomocą fromOrigins. Jedna strona wyrażająca zgodę nie wystarczy.
  • Progresywne ulepszanie: nieobsługiwany lub wyłączony WebMCP musi pozostawić zwykłą stronę w pełni użyteczną.
Evidence for this claim WebMCP tool exposure is origin-isolated and controlled by the tools Permissions Policy; cross-origin iframes require explicit delegation. Scope: browser document Confidence: high · Verified: WebMCP Imperative API

To przydatne mechanizmy platformy, ale nie zamieniają ryzykownego działania aplikacji w bezpieczne.

Bezpieczeństwo: sesja przeglądarki podnosi stawkę

Agent przeglądarki może działać w uwierzytelnionej sesji użytkownika. To może być funkcja—dostęp do bieżącego koszyka, konta lub obszaru roboczego—i zagrożenie. Chrome i szkic omawiają wstrzykiwanie promptów, mylące metadane narzędzi, zanieczyszczone wyniki narzędzi, zbyt szerokie parametry, wyciek prywatności, ekspozycję między pochodzeniami i nadużycie zalogowanej autoryzacji. Evidence for this claim WebMCP tool hints can communicate read-only and untrusted-output intent, but they do not eliminate prompt injection, misleading metadata, privacy leakage, cross-origin risk, or misuse of authenticated browser authority. Scope: Threat-model and defensive guidance; application authorization and confirmation remain implementation responsibilities. Confidence: high · Verified: WebMCP security and privacy considerations Chrome: WebMCP tool security Chrome: Agent security considerations

Traktuj każde narzędzie jako publiczny punkt końcowy aplikacji z nietypowym wywołującym:

  1. Zachowaj wąski zakres narzędzia. Jedno zadanie, jawne dane wejściowe, ścisłe wyliczenia i długości, bez ukrytego parametru „zrób wszystko”.
  2. Wymuszaj autoryzację w logice aplikacji. Agent nie uzyskuje większych uprawnień niż zalogowany użytkownik, a podpowiedź nie jest pozwoleniem.
  3. Oddziel odczyty od zapisów. readOnlyHint i untrustedContentHint komunikują ryzyko; nie egzekwują go.
  4. Wymagaj widocznego potwierdzenia dla konsekwencji. Zakupy, wysyłki, usunięcia, wiadomości i zmiany konta wymagają punktu kontrolnego zrozumiałego dla człowieka.
  5. Minimalizuj dane wyjściowe. Zwracaj tylko to, czego wymaga zadanie; nigdy nie ujawniaj danych sesji, surowych nagłówków, sekretów ani niepowiązanych rekordów.
  6. Traktuj dane wyjściowe jako niezaufane. Ciąg zwrócony przez jedno narzędzie może stać się danymi wejściowymi do późniejszego rozumowania modelu. Nie pozwól, aby przemycał instrukcje lub uprawnienia.
  7. Rejestruj granicę. Rejestruj narzędzie, klasę danych wejściowych, decyzję autoryzacyjną, potwierdzenie, klasę wyniku, błąd, pochodzenie i cykl życia bez rejestrowania sekretów.

Bezpieczne pytanie nie brzmi: „Czy agent może to wywołać?”. Brzmi: „Czy udostępniłbym to jako przejrzany endpoint wywołującemu, który może źle zrozumieć instrukcje i przekazywać niezaufany tekst?”

Testuj kontrakty i zachowanie agenta osobno

Wytyczne Chrome dotyczące ewaluacji oddzielają deterministyczne testy produktu od probabilistycznych testów agenta. Evidence for this claim WebMCP testing should combine deterministic contract and UI-state tests with probabilistic evaluation of agent tool selection and use. Scope: Chrome's evaluation guidance; teams must define product-specific tasks, models, risks, and thresholds. Confidence: high · Verified: Chrome: Evals for WebMCP Oba mają znaczenie:

Testy deterministyczne powinny weryfikować rejestrację, odrzucanie schematów, poprawne i niepoprawne dane wejściowe, autoryzację, limity szybkości, skutki uboczne, kształt błędów, minimalizację danych wyjściowych, parytet interfejsu, zachowanie przy wyrejestrowaniu oraz fallback dla nieobsługiwanych przeglądarek.

Ewaluacje probabilistyczne powinny mierzyć, czy reprezentatywni agenci odkrywają właściwe narzędzie, unikają nieistotnych narzędzi, wybierają poprawne parametry, proszą o wyjaśnienie, gdy jest to wymagane, respektują potwierdzenia, zatrzymują się po sukcesie i opierają się adwersarialnym opisom lub danym wyjściowym.

Nie używaj jednego promptu demonstracyjnego jako bramki wydania. Udane wywołanie zwrotne dowodzi, że kod się wykonał; nie dowodzi, że modele wybierają go niezawodnie ani że działanie jest bezpieczne.

Cloudflare Browser Run: przydatne laboratorium, nie włączenie

Cloudflare dokumentuje wsparcie WebMCP w eksperymentalnej puli laboratoryjnej Browser Run i mówi, że sesje laboratoryjne nie powinny być używane do obciążeń produkcyjnych. Jego strona z 23 kwietnia zawiera również starsze nazwy testów z epoki Chrome, więc używaj tej strony jako dowodu na bieżącą ofertę produktową Cloudflare — a nie jako autorytetu dla najnowszego kształtu API WebMCP. Evidence for this claim Cloudflare Browser Run offers experimental lab sessions that can consume and test page-provided WebMCP tools, but the page still owns tool registration and Cloudflare says lab sessions are not for production workloads. Scope: Cloudflare product documentation last updated April 23, 2026; its example API names lag current Chrome documentation and should not be used as the API authority. Confidence: high · Verified: Cloudflare Browser Run: WebMCP

Cloudflare może zapewnić sesję przeglądarki i ścieżkę agenta, która korzysta z narzędzi. Nie może wywnioskować bezpiecznego kontraktu dla Twojej aplikacji ani zarejestrować narzędzi należących do strony, których nie zbudowałeś.

Proponowany pilotaż patrickstox.com: Walidator schematu

Schema Markup Validator jest dobrym kandydatem na przyszły pilotaż, a nie działającą implementacją WebMCP. Ma już ograniczone dane wejściowe wklejane, deterministyczną logikę, ustrukturyzowane problemy i widoczny wynik. Przyszłe narzędzie validate_schema mogłoby ponownie użyć tego samego silnika walidacji co interfejs i istniejący zestaw zdalnych narzędzi MCP.

Pilotaż powinien poczekać, aż API przeglądarki osiągnie stabilną, nieeksperymentalną wersję i przejdzie świeży przegląd bezpieczeństwa. Pierwsza wersja powinna być tylko do odczytu, wykrywająca funkcje, ograniczona pod względem danych wejściowych, minimalizująca odpowiedzi i niedostępna na powierzchniach podglądu, administracyjnych lub tylko dla właściciela. Ta witryna nie obecnie deklaruje wsparcia WebMCP.

Decyzja: buduj, eksperymentuj, czekaj lub pomiń

SytuacjaDecyzja
Wymagana jest stabilna obsługa przeglądarki dla przepływu pracy klientaPoczekaj i zachowaj pełny normalny interfejs użytkownika/API
Masz ograniczone działanie tylko do odczytu i możesz uruchomić prywatne laboratoriumEksperymentuj, z wykrywaniem funkcji i bez zależności produkcyjnych
Zadanie wymaga wykonania w tle lub bezgłowegoUżyj API lub zdalnego MCP
Strona tylko publikuje treściPomiń WebMCP; ulepsz semantyczny, dostępny HTML
Działanie zapisuje, kupuje, wysyła, usuwa lub ujawnia prywatne daneNie pilotażuj pochopnie; wymagaj osobnego modelu zagrożeń i projektu potwierdzenia
Stabilna implementacja zostanie wydana, a wszystkie testy kontraktowe/bezpieczeństwa/parytetu przejdąRozważ stopniowy pilotaż produkcyjny

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.