Próbowałem zmusić Claude w Chrome do wywołania narzędzia WebMCP. Oto co się wydarzyło.
To nie jest artykuł o tym jak WebMCP działa w teorii. To jest zapis eksperymentu — z błędami, naprawami i momentem w którym wszystko zaskoczyło.
Założenie
Artykuł o retrieval na webflux.pl jest trudny. Napisany dla kogoś kto już wie czym jest okno kontekstu i context rot. Właściciel małego sklepu go nie przetworzy. Uczeń szkoły średniej tym bardziej.
Pomysł: zarejestrować na stronie narzędzie WebMCP simplifyArticle które zwraca wersję artykułu dostosowaną do poziomu czytelnika. Cztery poziomy — uczeń, biznes, oryginalny, inżynier. Agent w Chrome wywołuje narzędzie, dostaje odpowiednią wersję.
Demo które pokazuje czym WebMCP różni się od „agent czyta stronę”.
Krok 1 — rejestracja narzędzia
20 linijek JavaScript. document.modelContext.registerTool() z nazwą, opisem i schematem parametrów. Endpoint PHP który zwraca właściwą wersję artykułu jako JSON. Wersję przygotowaną wcześniej, bez połączenia z zewnętrznym LLM – to założenie na potrzeby eksperymentu, nie konfiguracja której nie można zmienić.
Pierwsze podejście — błąd. window.ai.registerTool nie istnieje. API zmieniło się między Chrome 146 a Chrome 150 — stary navigator.modelContext zastąpiony przez document.modelContext.
Po korekcie — konsola pokazuje:
[WebMCP Demo] ✓ Narzędzie "simplifyArticle" zarejestrowane.
Poziomy: uczen | biznes | oryginal | inzynierNarzędzie widoczne. document.modelContext.getTools() zwraca tablicę z jednym elementem — simplifyArticle, z opisem, schematem i origin: "https://webflux.pl".
Rejestracja webMCP
Krok 2 — test z Claude w Chrome
Otwieram panel Claude. Piszę: „Użyj narzędzia simplifyArticle z poziomem uczen i pokaż mi wynik”.
Claude zaczyna działać.
98 kroków.
Analizuje stronę. Szuka elementów DOM. Próbuje odczytać strukturę artykułu. Naprawia format odpowiedzi API. Szuka narzędzia wszędzie — tylko nie w document.modelContext.
Przerywam po 98 krokach. Claude nie wywołał narzędzia WebMCP. Nie dlatego że narzędzie nie istnieje — istnieje, widać je w konsoli. Dlatego że Claude w Chrome na ten moment nie patrzy na document.modelContext przy wykonywaniu zadań.
Krok 3 — diagnoza
Claude po 98 krokach wystawia diagnozę:
Narzędzie simplifyArticle jest prawidłowo zarejestrowane w document.modelContext. Problem: endpoint backendowy nie jest dostępny — WordPress przechwytuje żądania do tej ścieżki.
Trafna diagnoza — zła ścieżka do pliku PHP. Podałem webflux.pl/webmcp/.. zamiast pełnej ścieżki przez wp-content. WordPress przechwycił request i zwrócił 301 na stronę główną.
Naprawiam ścieżkę w JS. Jeden parametr.
Krok 4 — 8 kroków
Wracam do Claude. Ten sam prompt: „Użyj narzędzia simplifyArticle z poziomem uczen i pokaż mi wynik”.
8 kroków.
Narzędzie simplifyArticle zostało pomyślnie wywołane z poziomem uczen.
Poziom: Dla ucznia
Opis: Prosto, bez żargonu, z analogią z życia
Retrieval — po co agent "szuka" zamiast "pamiętać"?
Wyobraź sobie że masz do napisania wypracowanie o dinozaurach...Pełna treść. Poprawna wersja. 8 kroków zamiast 98.
Poziom uczeń webMCP
Co to znaczy
Różnica 98 vs 8 nie wynika z tego że drugi prompt był mądrzejszy. Wynika z tego że za drugim razem endpoint działał— narzędzie mogło zostać wywołane.
To jest właśnie sedno WebMCP. Gdy strona prawidłowo wystawia narzędzie i agent może je wywołać — nie ma potrzeby zgadywania struktury DOM, analizowania HTMLa, szukania formularzy. Agent dostaje funkcję z nazwą i schematem. Wywołuje ją. Dostaje wynik.
Jest jedno „ale” które warto powiedzieć wprost: Claude w Chrome na ten moment nie wykrywa narzędzi WebMCP automatycznie. Wywołał simplifyArticle dlatego, że poprosiliśmy go o to z nazwy. Automatyczne discovery — „agent wchodzi na stronę i sam widzi jakie narzędzia są dostępne” — to kolejny krok który zależy od implementacji po stronie klienta.
Standard istnieje po stronie strony.
Stan WebMCP w czerwcu 2026
Narzędzie rejestruje się w 5 minut. document.modelContext.getTools() działa w Chrome Canary z odpowiednio ustawioną flagą. Narzędzie jest widoczne i możliwe do wywołania.
Automatyczne discovery przez agentów — w trakcie implementacji. Chrome 149 origin trial otwiera WebMCP dla szerszego testowania. Stabilny Chrome i Edge — kilka miesięcy.
To jest dobry moment żeby eksperymentować. Zły moment żeby sprzedawać klientom „wdrożenie WebMCP” jako gotowy produkt.
Kod eksperymentu
Jeśli chcesz odtworzyć demo na własnej stronie — kod endpointu PHP i rejestracji narzędzia JS jest w następnym artykule serii.
Następny artykuł: WebMCP — implementacja krok po kroku dla serwisu na WordPress
