WebMCP, serwer MCP i markdown: strona firmy gotowa na agentów AI

Od 6 października 2026 agent AI może na naszej stronie pobrać ofertę, cennik i realizacje jako dane, przeczytać każdą stronę w markdownie i wypełnić formularz zapytania, który potem wysyła człowiek. Wdrożyliśmy WebMCP w origin trial Chrome, serwer MCP strony, wersje markdown wszystkich adresów i sygnały treści w robots.txt. Lighthouse w kategorii Agentic Browsing zalicza teraz wszystkie siedem testów, łącznie z trzema testami WebMCP. Poniżej opisujemy, co dokładnie zmieniliśmy, jak to sprawdzić i jak liczymy zapytania wysłane przez agentów.

Jak wyglądała strona dla agenta przed zmianami?

Czytał HTML i drzewo dostępności, czyli uproszczony opis strony, z którego korzystają też czytniki ekranu, i na tej podstawie zgadywał, które pole do czego służy. W Pogotowiu IT Lighthouse 13.5 oznaczył drzewo jako źle zbudowane: pole wyboru pakietu nie miało etykiety, więc agent widział listę z cenami bez nazwy. W pozostałych formularzach etykiety nie były powiązane z polami, a pola nie miały autouzupełniania e-maila ani telefonu. Narzędzi WebMCP nie było wcale, więc trzy testy WebMCP w Lighthouse dostawały wynik „nie dotyczy”, a agent musiał zgadywać na podstawie samego HTML i etykiet, które nie wskazywały pól.

Chcesz, żeby asystent klienta w ChatGPT, Gemini albo Claude znalazł produkt w Twoim sklepie, sprawdził cenę i przygotował zamówienie bez zgadywania? Pierwszy krok to test agentem. Zobacz ofertę dla sklepów →

Co wdrożyliśmy?

Jak działa WebMCP w formularzu kontaktowym?

Wersja deklaratywna to atrybuty HTML na istniejącym formularzu, a formularz Pogotowia IT wygląda dla agenta jak narzędzie zamow_pogotowie_it z polami imię, firma, e-mail, telefon, pakiet i opis potrzeby. Pakiet przychodzi jako lista wartości z cenami, więc agent nie musi czytać cennika osobno.

<form toolname="zamow_pogotowie_it"
      tooldescription="Wysyła do zespołu ASAPDEVS zapytanie o abonament Pogotowie IT…">
  <input name="email" type="email" autocomplete="email"
         toolparamdescription="Adres e-mail, na który przyjdzie odpowiedź">
  …
</form>

Formularze nie mają atrybutu toolautosubmit, więc agent je wypełnia, a człowiek klika „Wyślij”. Po wysyłce strona oddaje agentowi wynik przez respondWith(): potwierdzenie z adresem e-mail albo treść błędu, a ukryte pole-pułapka na boty jest dla agenta zwykłym parametrem, dlatego przy wysyłce przez agenta je pomijamy. Limit: 5 zgłoszeń na 10 minut z jednego IP.

Narzędzia do odczytu w przeglądarce i przez MCP

Pięć narzędzi korzysta z jednego modułu danych, tego samego, z którego zbudowane są strony: list_offers, list_case_studies, search_blog, get_pricing i get_contact. W przeglądarce rejestrujemy je przez registerTool dopiero wtedy, gdy Chrome ma WebMCP, a dane pobieramy z API przy wywołaniu, więc zwykły odwiedzający nie ładuje ani bajta więcej. Każde narzędzie ma oznaczenie readOnlyHint.

Ten sam zestaw udostępnia endpoint /api/mcp w trybie Streamable HTTP. Sprawdzisz go poleceniem:

npx -y @modelcontextprotocol/inspector --cli https://asapdevs.it/api/mcp \
  --transport http --method tools/list

Serwer nie ma narzędzi do zapisu, więc zapytanie ofertowe dalej wysyła się przez formularz, a ostatnie kliknięcie należy do człowieka.

Markdown każdej strony i sygnały w robots.txt

Każdy adres ma wersję markdown: wystarczy dopisać .md, np. /offers/it-emergency.md, albo wysłać nagłówek Accept: text/markdown. Odpowiedź zaczyna się od tytułu, opisu, adresu kanonicznego i daty aktualizacji, a dalej jest sama treść z nagłówkami, tabelami i linkami, a cała odpowiedź ma noindex. Odpowiedź na nagłówek Accept nie trafia do cache CDN, bo Cloudflare przed naszą stroną nie rozróżnia wariantów HTML po nagłówku Vary.

W robots.txt dodaliśmy politykę Content Signals Cloudflare: search=yes, ai-input=yes, ai-train=yes, bo chcemy, żeby asystenci AI znali naszą ofertę i ją cytowali, więc zgadzamy się na wszystkie trzy zastosowania.

Jak sprawdzić to samo na swojej stronie?

1. Lighthouse 13.3 lub nowszy: npx lighthouse@latest https://twoja-strona.pl --only-categories=agentic-browsing. U nas przed zmianami drzewo dostępności było niezaliczone, a po zmianach przechodzą wszystkie testy, łącznie z trzema testami WebMCP, które wcześniej nie miały czego sprawdzić.
2. Testy WebMCP wymagają Chrome 149+ z flagą chrome://flags/#enable-webmcp-testing albo tokenu z programu origin trial. Nasz token działa do 30 marca 2027 i obejmuje subdomeny, więc u odwiedzających z Chrome 149 lub nowszym WebMCP działa bez żadnej flagi.
3. Test agentem: daj Claude in Chrome zadanie typu „znajdź cenę abonamentu IT i przygotuj zapytanie” i zobacz, gdzie się zatrzymuje.

Jak liczymy zapytania od agentów?

Gdy formularz wysyła agent, przeglądarka ustawia w zdarzeniu wysyłki pole agentInvoked, a my przekazujemy je do GA4 jako parametr agent=webmcp przy konwersji generate_lead, z osobnym wymiarem „Agent AI”. Raport rozdziela ludzi i agentów. Licznik działa od 6 października 2026, a wyniki pierwszego kwartału dopiszemy do tego artykułu.

Czego nie wdrożyliśmy i dlaczego

• agents.txt i agents.json: żaden z nich nie jest standardem. agents.txt ma w IETF dwa niezależne szkice indywidualne (draft-car-agents-txt-wellknown i wygasły draft-srijal-agents-policy), których nie przyjęła żadna grupa robocza, a agents.json to specyfikacja jednej firmy w wersji 0.1. Narzędzia strony opisują już WebMCP i ard.json, które Lighthouse sprawdza.
• NLWeb: pełna wyszukiwarka konwersacyjna ma sens w serwisie z tysiącami podstron i katalogiem produktów, a u nas kilkadziesiąt wpisów obsługuje zwykłe search_blog.
• Protokoły płatności agentów (ACP, UCP, x402): nie sprzedajemy przez stronę. Dla sklepów opisujemy je w ofercie agentic commerce.