Wyjaśnienie WebMCP: umożliwienie stronom internetowym publikowania narzędzi zamiast agentom wykonującym klikania w interfejsach użytkownika.

Załóżmy mały projekt poboczny, w którym agent AI musi samodzielnie obsługiwać aplikację internetową. Pierwsza wersja działa w taki sam sposób jak większość agentów przeglądarki: agent uzyskuje dostęp do aplikacji i decyduje, co robić, na podstawie tego, co pokazuje strona. W przypadku prostej aplikacji do zarządzania zadaniami prośba może brzmieć „Dodaj ‘Kup jajka’ do mojej listy”. Aby to zrealizować, agent musi przejrzeć stronę, znaleźć pole wprowadzania danych, ustalić, który przycisk wysyła formularz, kliknąć w niego, a następnie sprawdzić wynik.

To działa, ale wymaga zbyt dużo wysiłku. Aplikacja już doskonale wie, co powinno się stać. Za tym przyciskiem znajduje się funkcja, za tą funkcją – API, a sama operacja polega na jednym prostym wywołaniu:

add_todo(title)

Dlaczego więc agent powinien wpatrywać się w interfejs i zgadywać, jak wykonać coś, co aplikacja może już opisać? W tym momencie WebMCP zaczyna mieć sens. Przepływ działa mniej więcej w ten sposób:

User request
     ↓
AI agent
     ↓
WebMCP tool
     ↓
Application logic
     ↓
UI updates

Interfejs nadal istnieje dla ludzkich odwiedzających. Agent nie musi go dekodować, aby wykonać jakąś akcję. To zmienia sposób postrzegania całego problemu. Pytanie może nie brzmieć, jak sprawić, by sztuczna inteligencja lepiej korzystała z stron internetowych, lecz jak sprawić, by strony internetowe lepiej informowały sztuczną inteligencję o tym, co potrafią zrobić.

Dwa sposoby, w jakie agenci korzystają dziś z sieci, oraz ich ograniczenia

Agent, który musi działać na danej stronie, ma obecnie dwa powszechne podejścia.

Pierwszym jest automatyzacja przeglądarki. Agent robi zrzuty ekranu, określa, co można kliknąć, przesuwa kursor, wypełnia pola, klikuje, sprawdza, co się stało, i powtarza ten proces. Przypomina to obserwowanie osoby obsługującej przeglądarkę, i ma te same wady: jest powolny, zużywa tokeny i łatwo się psuje. Niewielka zmiana układu, ukryty menu, interakcja dostępna tylko przy nadaniu kursora lub dodatkowy krok w procesie mogą zaburzyć działanie agenta.

Druga opcja to specjalnie stworzony serwer MCP napisany pod Twoje aplikację. Dla narzędzi zapewnia to o wiele lepsze doświadczenie. Koszt pojawia się w inny sposób, ponieważ agent musi najpierw wiedzieć o istnieniu serwera i do niego się połączyć. Gdy każda strona internetowa dostarcza własną, dostosowaną integrację, takie rozwiązanie nie jest skalowalne. To praktyczny limit podejścia opartego na specjalnych serwerach MCP.

To tworzy luki – automatyzacja przeglądarki jest zbyt pośrednia, a integracje dostosowane są zbyt ręczne. WebMCP ma na celu wypełnienie tej przestrzeni pomiędzy nimi.

Czym właściwie jest WebMCP

Mówiąc prościej, WebMCP umożliwia stronie internetowej poinformowanie agenta AI: „Oto czego możesz dokonać na tej stronie”. Zamiast żeby agent zastanawiał się, który przycisk nacisnąć, strona przekazuje mu listę dostępnych działań.

Na przykład sklep internetowy mógłby udostępnić takie narzędzia:

search_products()
get_product_details()
add_to_cart()

Agent przeglądający stronę samodzielnie znajduje dostępne narzędzia i używa do nich strukturyzowanych danych, które każde z nich wymaga. Nie trzeba niczego wcześniej rejestrować w agencie. Narzędzia są odkrywane dynamicznie na stronie internetowej, i to właśnie jest najważniejsze. Strona przestaje być zwykłym zbiorem stron i zaczyna oferować konkretne funkcje.

Przykład z życia: aplikacja Todo

Weźmy prostą aplikację do zarządzania zadaniami. Bez WebMCP agent musiałby sprawdzić stronę, znaleźć pole wprowadzania tekstu, wpisać w nim treść, zlokalizować przycisk „Dodaj”, kliknąć go i ponownie przeczytać zaktualizowany interfejs.

Dzięki WebMCP aplikacja może publikować cztery narzędzia:

add_todo(title)
list_todos()
toggle_todo(id)
delete_todo(id)

Agent nie potrzebuje już żadnej wiedzy na temat układu wizualnego. Wie, co potrafi zrobić aplikacja. Dema zbudowane dokładnie w ten sposób pokazało aplikację typu Todo, która udostępniała cztery narzędzia, przy czym połączony agent odczytywał ich schematy i natychmiast wywoływał add_TODO. Polecenie agentowi dodania do listy „Muszę kupić jajka” uruchomiło wywołanie tego narzędzia, a nowy element pojawił się w aplikacji.

Model mentalny jest znacznie prostszy: interfejs użytkownika jest przeznaczony dla ludzi, narzędzia dla agentów, a oba działają w ramach tej samej aplikacji.

Jak wygląda definicja narzędzia

Tutaj inżynierowie frontendu znajdą to interesujące. Implementacja w tym demie rejestruje narzędzia za pośrednictwem navigator.modelContext. Każde narzędzie składa się z kilku elementów:

{
  name: "add_todo",
  description: "Add a todo item",
  inputSchema: {
    // structured inputs
  },
  execute: async (input) => {
    // application logic
  }
}

Kształt jest spójny: nazwa, opis, schemat danych wejściowych oraz funkcja wykonawcza, która realizuje zadanie, zwykle poprzez wywoływanie API backendowych już dostępnych w aplikacji. Ten ostatni element ma znaczenie – WebMCP nie wymaga przepisywania logiki biznesowej przeznaczonej do AI. Istniejąca aplikacja pozostaje systemem wykonującym operację, a agent jedynie uzyskuje uporządkowany sposób na jej uruchomienie.

Problem z autoryzacją

Sytuacja staje się poważna, gdy aplikacja przestaje być narzędziem do ćwiczeń. Wyobraźmy sobie takie narzędzia:

get_profile()
update_profile()
create_order()
cancel_order()
transfer_money()

Nieznany agent nie powinien mieć możliwości swobodnego wywoływania tych funkcji. Druga demonstracja w tym samym materiale zajmuje się dokładnie tym problemem za pomocą OAuth. Narzędzia WebMCP działają na bazie zalogowanej aplikacji, więc użytkownicy, którzy się nie zalogowali, nie mogą wykonywać chronionych działań.

To ma znaczenie, ponieważ agenci pochodzą z różnych rodzajów klientów: przeglądarki z funkcjami AI, agentów desktopowych lub innych aplikacji typu agent. Standardowy mechanizm taki jak OAuth znacznie ułatwia ochronę warstwy funkcji we wszystkich tych przypadkach, w porównaniu z koniecznością tworzenia osobnego procesu logowania dla każdej integracji. Gdy strony udostępniają agentom swoje funkcje, autoryzacja staje się częścią doświadczenia użytkownika agenta od samego początku, a nie dodatkowym poprawką wprowadzaną później.

Nowe pytanie dla projektowania interfejsu użytkownika

Przez lata architektura frontendu opierała się na jednym łańcuchu: interfejs, stan, API, backend. WebMCP wprowadza kolejne pytanie: jakie funkcje powinna ta aplikacja udostępniać agentowi?

Brzmi to drobnie, ale może to zmienić sposób projektowania funkcji. Przycisk „Dodaj do koszyka” to interakcja z człowiekiem. Ten wywołanie to natomiast funkcja aplikacji:

add_to_cart(productId, quantity)

Oba rozwiązania mogą ostatecznie zostać zaprojektowane razem. Użytkownicy otrzymują dopracowany interfejs, a agenci – uporządkowany interfejs umożliwiający korzystanie z funkcji, przy czym oba kończą w tej samej logice biznesowej.

Chodzi nie tylko o szybkość

Istnieje głębszy powód, dla którego to ma znaczenie, niż tylko szybsze agenty. Gdy agent pracuje za pomocą zrzutów ekranu i kliknięć, sam interfejs stanowi umowę, a każda zmiana w nim może sparaliżować działanie agenta. Dzięki WebMCP definicja narzędzia staje się częścią tej umowy.

To wprowadza nowy zestaw kwestii do zakresu obowiązków dewelopera frontendu: nazwy narzędzi, opisy, schematy danych wejściowych, zachowanie podczas wykonywania zadań oraz zasady autoryzacji. Praca przestaje polegać wyłącznie na projektowaniu ekranów – zaczyna obejmować również projektowanie sposobu, w jaki oprogramowanie prezentuje się inteligentnym systemom.

Nadal w początkowej fazie

Należy podkreślić jedną ważną kwestię. WebMCP pozostaje propozycją w wersji wstępnej i nie jest ustalonym standardem sieciowym. Dema zostało przeprowadzone w Chrome Beta z włączonym WebMCP za pomocą flag przeglądarki, a prelegent jasno stwierdził, że API może się jeszcze zmienić. Budowa architektury produkcyjnej wokół niego w tym momencie byłaby przedwczesna. Eksperymentowanie z nim to inna sprawa, ponieważ idea leżąca u jego podstaw jest szersza niż obecne API.

Strony internetowe są budowane od dziesięcioleci w oparciu o jedno założenie: po drugiej stronie znajduje się człowiek. WebMCP jest jednym z pierwszych eksperymentów, które to zakład kwestionują. Aplikacje internetowe wkrótce będą musiały odpowiedzieć na dwa pytania: jak powinien to używać człowiek? I jak powinien to używać agent AI? Pierwsze pytanie doprowadziło do powstania nowoczesnej inżynierii frontendu. Drugie może wpłynąć na to, co pojawi się w przyszłości.

Literatura pokrewna

• Wyjaśnienie WebMCP: Dostarczanie narzędzi agentom AI w przeglądarce zamiast domysłów — WebMCP umożliwia stronie internetowej określenie narzędzi dostępnych dla agentów AI. Jak je zarejestrować, ocenić ryzyko, przetestować w Chrome oraz zarządzać bezpieczeństwem, a także jaki jest stan wsparcia przeglądarek w 2026 roku.
• Playwright czy agenci przeglądarki? Gdzie nadal dominuje automatyzacja oparta na skryptach — Porównanie skryptów Playwright z agentami przeglądarki napędzanymi MCP: kruchość, determinizm, koszty, przykładowe zadanie z fakturą, narzędzia do obserwacji, zagrożenia bezpieczeństwa oraz ramy decyzyjne.