Co zmienia się na stronie firmowej po wdrożeniu WebMCP i od czego zacząć

Wdrożenie WebMCP na stronie firmowej polega na dodaniu opisów do formularzy i akcji w HTML, które agent AI odczytuje zamiast próbować domyślić się, do czego służy każdy formularz. Praca nie zmienia wyglądu strony, nie wpływa na pozycjonowanie i nie wymaga przepisywania kodu od zera. Zakres zależy przede wszystkim od liczby formularzy, bo każdy opisujemy osobno i precyzyjnie.

Jeden z klientów prowadzi hurtownię materiałów wykończeniowych. Jego handlowcy zaczęli zauważać, że zapytania przysyłane przez asystentów AI klientów trafiają przez ogólny formularz kontaktowy i są wypełnione chaotycznie: w polu "Firma" pojawia się indeks produktu, w polu "Wiadomość" trzy zdania bez ilości i bez adresu dostawy. Agent po prostu zgadywał, co gdzie wpisać. Po wdrożeniu WebMCP każdy formularz na tej stronie ma opis słowny, który agent czyta wprost. Nie zgaduje. Wypełnia pole "Ilość w metrach kwadratowych" liczbą, pole "Indeks katalogowy" kodem z cennika, i wysyła zapytanie z kompletnymi danymi. Handlowcy dostają zgłoszenia, z którymi można od razu pracować.

To jest sedno WebMCP: nie nowa funkcja na stronie, lecz warstwa opisów dla agentów.

Co agent AI widzi na Waszej stronie bez WebMCP

Bez WebMCP agent odczytuje stronę podobnie jak przeglądarka tekstowa. Analizuje nagłówki, etykiety pól formularzy, tekst przycisków, tytuł strony. Jeśli macie formularz z polem "Wiadomość" i przyciskiem "Wyślij zapytanie", agent nie ma pewności, czy to ogólny formularz kontaktowy, prośba o ofertę na produkt, czy może zapis na serwis. Wypełnia na podstawie kontekstu ze strony, który bywa niejednoznaczny.

Formularze wieloetapowe to osobny problem. Agent wypełnia krok pierwszy, klika dalej, a przy dynamicznie ładowanych kolejnych ekranach często traci kontekst, co ma zrobić dalej.

Wyszukiwarki produktów są jeszcze trudniejsze. Agent widzi pola filtrów, ale nie wie, w jakim formacie wpisać parametr techniczny ani jakie wartości są dopuszczalne. Albo szuka produktu i nic nie znajduje, bo wpisał "biały matowy" zamiast kodu "RAL 9010".

Po wdrożeniu WebMCP każda akcja na stronie ma opis, który agent czyta bezpośrednio. Nie interpretuje. Nie zgaduje. Działa jak programista, który dostał dokumentację zamiast strony do przeanalizowania od zera.

Które akcje klientów na stronie opisujemy dla agenta

Zanim ktoś dopisze pierwszą linię kodu, robimy razem krótką inwentaryzację: co klient realnie robi na Waszej stronie? Na typowej stronie produkcyjnej lub usługowej lista wygląda tak:

• wysłanie zapytania ofertowego z parametrami produktu lub usługi
• zamówienie próbki, katalogu drukowanego lub dokumentacji technicznej
• zapis na szkolenie, webinar lub wizytę serwisową z wyborem terminu
• sprawdzenie statusu zlecenia lub zamówienia po podaniu numeru
• pobranie certyfikatu, karty produktowej lub cennika po podaniu danych kontaktowych
• wyszukanie produktu według parametrów technicznych
• kontakt z konkretnym działem ze wskazaniem tematu sprawy

Każda z tych akcji to osobne narzędzie dla agenta. Jeden formularz kontaktowy "dla wszystkiego" jest najgorszym punktem startowym, bo agent nie wie, kiedy i w jakim celu go użyć. Przy inwentaryzacji u wspomnianej hurtowni znaleźliśmy przy okazji dwa formularze, które od miesięcy wysyłały dane w nikąd, bo ktoś zmienił adres mailowy i nie zaktualizował konfiguracji. Taki przegląd ma sens niezależnie od WebMCP.

Jak wygląda opis formularza: atrybuty HTML i navigator.modelContext

WebMCP działa przez dwa mechanizmy. Można je stosować razem albo osobno, w zależności od budowy strony.

Pierwszy to atrybuty dodawane bezpośrednio do formularzy w HTML. Trzy ważne:

• toolname: unikalna nazwa narzędzia, którą agent używa do wywołania formularza, np. zapytanie-ofertowe-materialy albo zamowienie-probki.
• tooldescription: opis słowny, co ten formularz robi i kiedy agent powinien go użyć. Przykład: "Formularz zapytania ofertowego na materiały budowlane. Użyj, gdy klient prosi o wycenę konkretnego produktu lub zestawu produktów."
• toolparamdescription: atrybut na każdym polu input, select lub textarea, opisujący, co wpisać i w jakim formacie. Na polu z ilością brzmi to na przykład: "Ilość w metrach kwadratowych, liczba całkowita, np. 150".

Na WordPressie atrybuty dodajemy przez filtry PHP do popularnych wtyczek formularzy, takich jak Contact Form 7, WPForms czy Gravity Forms, albo bezpośrednio w szablonie bloku. Na stronach pisanych własnym kodem wchodzimy w szablony HTML. Programista nie pisze tych opisów sam: to wspólna praca, bo opis musi oddawać intencję biznesową, a to wiesz Ty, a nie programista.

Drugi mechanizm to JavaScript przez navigator.modelContext. To API przeglądarki, które pozwala dynamicznie rejestrować narzędzia, których nie da się opisać samym HTML. Kalkulator wyceny, wyszukiwarka według parametrów technicznych, sprawdzenie dostępności terminu w kalendarzu: każde z nich można zarejestrować jako narzędzie z opisem, jakie parametry przyjmuje i co zwraca. Ta metoda jest potrzebna tam, gdzie interakcja dzieje się po stronie JavaScriptu, bez przeładowania strony.

Przeglądarka bez obsługi WebMCP ignoruje te atrybuty i wywołania JavaScript. Nic się nie psuje. Formularz wygląda i działa tak samo dla każdego użytkownika klikającego ręcznie.

Co firma przygotowuje po swojej stronie przed wdrożeniem

Dostęp do strony to podstawa. Panel CMS, czyli WordPress admin, własny panel administracyjny albo dostęp do repozytorium z kodem. Bez tego nie ma jak edytować formularzy ani szablonów.

Potrzebna jest lista formularzy. Nie tylko tych z menu głównego, ale wszystkich: formularze na stronach produktowych, w strefie klienta, w procesie zamówienia, na stronach kampanii. Na witrynach budowanych latami, przez różne agencje, formularze potrafią być rozrzucone wszędzie. Inwentaryzację robimy razem, bo Ty wiesz, których z nich realnie używają klienci i które generują zapytania warte uwagi.

Trzecia rzecz: informacja o tym, kto odbiera zapytania i dokąd trafiają. Formularz zapytania ofertowego idzie na mail do handlowców? Jest wpinany do CRM? Trafia bezpośrednio do systemu zamówień? Wdrożenie WebMCP nie zmienia żadnego z tych backendów. Opisujemy to, co już istnieje. Ale musimy wiedzieć, jak to działa, żeby opis dla agenta był zgodny z rzeczywistością i nie tworzył fałszywych oczekiwań.

Czwarta, ważna rzecz: decyzja, które formularze opisujemy dla agentów, a które nie. Formularz logowania do strefy klienta to raczej zły kandydat do opisu dla zewnętrznych agentów. Formularz zapytania ofertowego: jak najbardziej. Formularz serwisowy dostępny tylko dla zarejestrowanych klientów: zależy, jak jest zabezpieczony. To decyzja właściciela lub menedżera, nie programisty.

Lista kontrolna: od przeglądu do pierwszych testów z agentem

Realizujemy to w tej kolejności:

• Inwentaryzacja formularzy i akcji na stronie: zebranie listy z adresem URL, celem każdego formularza i informacją, dokąd trafia wysyłka.
• Decyzja o zakresie: które opisujemy dla agentów, które pomijamy, które przy okazji naprawiamy lub wyłączamy.
• Napisanie opisów toolname, tooldescription i toolparamdescription: wspólna praca, bo opis musi oddawać, jak formularz jest używany w praktyce, a to wiesz Ty, nie programista.
• Implementacja atrybutów HTML: na WordPressie przez filtry lub edytor, na własnym kodzie bezpośrednio w szablonach.
• Rejestracja narzędzi dynamicznych przez navigator.modelContext: tam, gdzie samo HTML nie wystarczy.
• Testy prawdziwym agentem: sprawdzamy, czy agent poprawnie identyfikuje narzędzia, wypełnia pola we właściwym formacie i wysyła formularze.
• Dodanie pomiaru wysyłek od agentów: ukryte pole lub parametr w URL, żeby odróżnić zgłoszenia od agentów od tych od ludzi.
• Poprawki po testach: po pierwszej rundzie zwykle jeden lub dwa opisy wymagają doprecyzowania.

Do testów używamy agenta podłączonego do Chrome (wersja z origin trial) lub Edge. Dajemy mu zadanie takie, jakie mógłby dostać od prawdziwego klienta: "wyślij zapytanie o wycenę 50 sztuk wieszaków w wersji matowej do działu handlowego". Agent powinien sam znaleźć właściwy formularz, wypełnić pola w odpowiednim formacie i wysłać. Jeśli zamiast pola "Indeks produktu" wpisuje tam opis słowny, to sygnał, że toolparamdescription dla tego pola wymaga poprawki.

Pomiar wysyłek od agentów: po co i jak to zrobić od razu

Pomiar warto wdrożyć przy okazji wdrożenia opisów, nawet jeśli dzisiaj ruch agentów jest jeszcze minimalny. Do każdego formularza dodajemy ukryte pole z wartością identyfikującą WebMCP albo parametr w URL akcji formularza, np. utm_source=agent i utm_medium=webmcp. W Google Analytics, w CRM albo w systemie zgłoszeń widać potem, które zapytania przyszły od agentów.

Co z tą liczbą? Na początku to kilka wysyłek tygodniowo, może mniej. Ciekawsze jest to, co agenci pytają: czy pytają o produkty z aktualnej oferty, czy wypełniają pola w sensowny sposób, czy dane są kompletne i użyteczne. To informacja, którą można wykorzystać do poprawienia opisów albo do decyzji, które formularze opisać w następnej kolejności. Firmy, które mają te dane od początku, widzą wyraźnie moment, gdy ruch agentów zaczyna rosnąć.

Stan specyfikacji WebMCP i co to oznacza dla firmy teraz

WebMCP to projekt specyfikacji przygotowywany przez Google i Microsoft w grupie W3C Community Group. Nie jest to jeszcze zatwierdzony standard. Chrome ma WebMCP w fazie origin trial, Edge też testuje. Wejście do stabilnych wersji przeglądarek planowane jest na koniec 2026 roku. Safari nie zapowiedziało wsparcia.

Dla firmy, która wdraża WebMCP teraz, znaczy to jedno: robicie to z wyprzedzeniem. Przeglądarka bez WebMCP ignoruje atrybuty toolname i tooldescription całkowicie. Strona działa normalnie dla każdego, kto odwiedza ją bez obsługi WebMCP. Nie ma ryzyka, że coś się posypie dla użytkowników korzystających z Safari czy Firefox.

MCP, na którym opiera się WebMCP, to otwarty standard łączenia asystentów AI z programami, rozwijany pod opieką Linux Foundation. Nie jest to zamknięty ekosystem jednego producenta. Agenci AI z różnych firm, którzy obsługują protokół MCP, będą mogli korzystać z opisów na Waszej stronie bez żadnych dodatkowych integracji.

Jedno ograniczenie warto powiedzieć wprost. WebMCP opisuje akcje dostępne na stronie przez przeglądarkę, nie zastępuje API. Jeśli chcecie, żeby agent miał dostęp do danych z Waszego systemu w czasie rzeczywistym, na przykład do aktualnych stanów magazynowych albo historii zamówień konkretnego klienta, to jest osobny temat: integracja przez MCP Server po stronie backendu. WebMCP na stronie to warstwa widoczna przez przeglądarkę: opisuje to, co klient mógłby kliknąć ręcznie. To dobry punkt startowy, na którym buduje się dalej.

W Polsce praktycznie nikt nie oferuje jeszcze wdrożeń WebMCP dla firm, więc strony opisane teraz będą gotowe zanim ruch agentów stanie się codziennością w branży.

Jeśli macie stronę z formularzami i chcecie sprawdzić, ile z nich warto opisać w pierwszej kolejności, zapraszamy na 15 minut rozmowy o WebMCP. Możemy też pokazać, jak to wygląda na przykładach, w realnych wdrożeniach.