WebMCP: udostępnianie narzędzi strony internetowej, aby agenty przestały skrapować DOM

Strony internetowe zostały zaprojektowane z myślą o kliknięciach użytkowników, formularzach i API. Coraz częściej „użytkownikiem” może być agent sztucznej inteligencji, który w ogóle nie korzysta z interfejsu wizualnego. Agenty, które przeszukują drzewa DOM lub sterują przeglądarkami, zawodzą, gdy zmienia się struktura zapisu. WebMCP (Web Model Context Protocol), zaproponowany w ekosystemie Chrome, ma na celu umożliwienie stronom bezpośredniego udostępniania strukturyzowanych narzędzi agentom – nazw, danych wejściowych, wyników oraz informacji o tym, kiedy je wywołać – dzięki czemu automatyzacja staje się jawna, a nie domyślna.

Czym jest WebMCP?

Mówiąc krótko, WebMCP pozwala stronie publikować narzędzia przeznaczone dla agentów, zamiast liczyć na to, że narzędzia do przeszukiwania będą trafnie zgadywać.

Bез WebMCP agent musi improwizować w obliczu nieprzejrzystego interfejsu:

AI Agent → Reads HTML → Guesses → Clicks → Hopes it works

Z WebMCP ta sama intencja staje się wyraźnym wezwaniem do użycia narzędzia:

AI Agent → Reads structured tools → Executes correctly

Dokumentacja Chrome przedstawia zalety WebMCP jako szybkość, niezawodność i precyzję w interakcjach z agentami.

Dlaczego istnieje WebMCP

Rozważ rezerwację hotelu. Ten kruchy proces otwiera stronę, znajduje pola wprowadzania danych, interpretuje daty, kliknie przycisk wyszukiwania i analizuje wyniki — jest wrażliwy na zmiany w DOM. Dzięki WebMCP agent wywołuje ustrukturyzowaną operację:

searchHotels({
 location: "Tokyo",
 checkIn: "2026-08-10",
 checkOut: "2026-08-15",
 guests: 2
})

Żadnej archeologii XPath, żadnej rotacji selektorów CSS, żadnych objazdów wizualnych dla rutynowych procesów — tylko bezpośrednia realizacja polecenia.

Jak działa WebMCP

Dwie uzupełniające się API:

1. API imperatywne

JavaScript wyraźnie rejestruje narzędzia:

navigator.webMCP.registerTool({
  name: "create-event",
  description: "Creates a calendar event",
  inputSchema: {
    type: "object",
    properties: {
      title: { type: "string" },
      date: { type: "string" }
    }
  },
  execute: async ({ title, date }) => {
    return await createCalendarEvent(title, date);
  }
});

Agenty otrzymują nazwę narzędzia, jego przeznaczenie, wymagane dane wejściowe oraz ścieżkę wykonania — logika frontendu eksportowana jako możliwości do wywołania.

2. API deklaratywne

Priorytet ma HTML, szczególnie w przypadku form:

<form webmcp-tool="book-flight">
  <input name="from" />
  <input name="to" />
  <input name="date" />
</form>

Czas wykonywania przenosi formę w ustrukturyzowane narzędzie, dzięki czemu istniejące aplikacje mogą stać się kompatybilne z agentami przy niewielkich zmianach w markupu.

WebMCP kontra MCP

Zamieszanie jest powszechne. Praktyczny podział: WebMCP skupia się na interfejsie użytkownika; MCP jest przeznaczony dla systemów i usług backendowych. Jednym z modeli pojęciowych jest traktowanie MCP jako „mózgu” po stronie serwera, a WebMCP jako „ciała” interfejsu. Razem obejmują one całe narzędzia typu full-stack agent, bez konieczności wykonywania każdej czynności poprzez niestabilną automatyzację przeglądarki.

Przypadki użycia w praktyce

1. E-commerce

Klient prosi o buty do biegania w określonym budżecie oraz możliwość dokonania zakupu. Możliwe do wykorzystania narzędzia obejmują:

searchProducts()
filterProducts()
addToCart()
applyCoupon()
checkout()

Agent kończy proces bez konieczności przewijania list.

2. Rezerwacje podróży

Szukanie lotów, porównywanie hoteli, rezerwowanie transportu naziemnego, dodawanie ubezpieczenia – wszystko za pomocą narzędzi, a nie kruchych makr.

3. Dashboardy SaaS

Paneli analityczne mogą prezentować takie funkcje jak:

generateReport()
downloadCSV()
inviteMember()
changeBillingPlan()

Copiloty wewnątrz aplikacji wywołują wtedy te same funkcje, które ludzie widzą jako przyciski.

4. Systemy CRM

Zamiast dziesięciu ekranów pełnych kliknięć:

createLead()
assignSalesRep()
scheduleFollowUp()

5. Obsługa klienta

Anuluj subskrypcje, domagaj się zwrotów pieniędzy, śledź przesyłki za pomocą sprawdzonych narzędzi, a nie metod opartych na HTML.

Dlaczego deweloperzy powinni się tym przejmować

Praca nad interfejsem przechodzi od prostego malowania pikseli do tworzenia narzędzi dostępnych dla agentów. Odpowiedzialności skupiają się na jasnym nazewnictwie, solidnych schematach i niezawodnej realizacji. Przedstawienie projektu funkcji wygląda mniej tak:

Build components for humans

a bardziej tak:

Build components for humans + machines

Najlepsze praktyki

Zachowuj jednoznaczność narzędzi

manageEverything()

createInvoice()
sendInvoice()
downloadInvoice()

Jasność pomaga agentom działać dokładniej.

Używaj jasnych nazw

Niejasne etykiety:

doTask()

Nazwy odzwierciedlające intencję:

submitExpenseClaim()

Zmniejsz obciążenie poznawcze

Nie zmuszaj modelu do wstępnego obliczania tego, co aplikacja już wie. Unikaj:

durationInMinutes

Lepiej akceptuj surowe dane, które backend może znormalizować:

startTime: "10:00"
endTime: "12:00"

Grzecznie radź sobie z błędami

Agenty próbują ponownie. Narzędzia powinny być bezpieczne podczas prób ponawienia — istotna jest idempotentność.

Kwestie bezpieczeństwa

Jeśli agenty mogą wykonywać narzędzia, wroga iniekcja skryptów z fałszywymi narzędziami stanowi problem badawczy. Do środków łagodzących należą weryfikacja pochodzenia, audyt rejestracji, ograniczenia uprawnień oraz potwierdzenia użytkownika dotyczące skutków ubocznych. Nie ufaj rejestracjom ślepo.

Bardziej szeroki kontekst

WebMCP funkcjonuje w ramach szerszej koncepcji agentic web: strony udostępniają swoje możliwości, agenci je rozumieją, ludzie delegują zadania, dzięki czemu praca jest wykonywana szybciej. Zespoły już tworzą API dla programistów; kolejnym krokiem są narzędzia przeznaczone dla agentów. Ci, którzy wcześnie przyjmują tę technologię i pytają „które elementy tej aplikacji powinny stać się narzędziami AI?”, będą kształtować następną falę rozwoju architektury sieciowej – podobnie jak REST, GraphQL, WebSockets i komponenty serwerowe przeszły z niszowych rozwiązań na standard. Technologia jest jeszcze w początkowej fazie, ale kierunek jej rozwoju trudno zignorować.

Szlak wdrażania w istniejących aplikacjach

Najpierw oznacz jedną ważną formę lub krok procesu płatności za pomocą deklaratywnej API, zmierz skuteczność działania agenta w porównaniu ze starym scraperem, a następnie rozszerz narzędzia imperatywne o te procesy, które wymagają specjalnej weryfikacji. Zachowaj ludzką kontrolę przy płatnościach oraz zmianach w koncie, które mogą mieć negatywne skutki, dopóki dane telemetryczne nie potwierdzą bezpieczeństwa takich działań. Traktuj schematy narzędzi jak publiczne API: sprawdzaj nazwy, weryfikuj ich wersje i odrzucaj rejestracje niepewnych skryptów.