O czym jest ten film
- Idea Web MCP: zamiast klikać po interfejsie jak człowiek, agent AI wywołuje akcje udostępnione wprost przez stronę — na przykład sprawdzenie wolnych terminów wizyt.
- Mechanika jest prosta: agent podaje dane wejściowe, strona wykonuje akcję i zwraca wynik.
- Google pokazuje demonstrację rezerwacji w formie porównania na podzielonym ekranie: klasyczny interfejs kontra wywołania narzędzi. Animacja jest rozpisana z góry, więc to nie test szybkości.
- Autor zestawił także prawdziwe wywołanie narzędzia tylko do odczytu (dostępność terminów) z poziomu przeglądarki.
- Web MCP jest eksperymentalne: specyfikacja to szkic, a Chrome oferuje jedynie origin trial i flagę do testów lokalnych.
- Przed decyzją trzeba sprawdzić wsparcie w konkretnej przeglądarce i agencie — i pamiętać, że narzędzia same nie przyciągną agentów: według Google agent musi najpierw odwiedzić stronę, żeby je odkryć.
- Lepsza obsługa to nie to samo co większy ruch, wyższe pozycje czy więcej sprzedaży — wynik zwrócony przez narzędzie nie jest badaniem konwersji.
- Autor prowadzi repozytorium web-mcp: pakiet wiedzy i wzorców dla agentów programistycznych — od oceny zasadności, przez zakres i kod, po integrację i weryfikację; zawiera siedem szablonów oraz plik agents.md.
- Kluczowe zasady: przy płatnych rezerwacjach zatwierdzenie zostaje w aplikacji, a testom poddaje się także błędne dane, anulowanie i awarie.
- Rekomendacja: mały pilotaż z pomiarem wywołań i skuteczności, porównany ze stanem sprzed wdrożenia — a całą decyzję o Web MCP można zacząć od jednego polecenia dla agenta programistycznego.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zamień klikanie na gotowe akcje
Na czym polega: W klasycznym modelu agent musi odnajdywać przyciski i formularze tak jak człowiek. Web MCP odwraca logikę: to strona sama deklaruje, jakie akcje obsługuje, a agent jedynie podaje dane i odbiera wynik.
Jak stosować: Przejrzyj swój kluczowy przepływ i wypisz akcje, które użytkownicy wykonują dziś ręcznie — od tej listy zacznij projektowanie narzędzi.
Na co uważać: Lista kandydatów to nie plan wdrożenia. Najpierw sprawdź, czy dana akcja ma sens jako narzędzie, dopiero potem ją koduj.
2.Zacznij od pytania, czy strona w ogóle potrzebuje narzędzi
Na czym polega: Proces rezerwacji składa się z akcji, które warto ocenić. Strona, na której ludzie wyłącznie czytają artykuł, prawdopodobnie narzędzi nie potrzebuje.
Jak stosować: Zanim sięgniesz po kod, zadaj pytanie wyprzedzające z repozytorium web-mcp: „Czy ta witryna powinna mieć narzędzia?”. Odpowiedź „nie” też jest wartościowym wynikiem.
Na co uważać: Negatywna ocena na starcie oszczędza całą integrację — potraktuj ją jako oszczędność, a nie porażkę projektu.
3.Traktuj Web MCP jako eksperyment, nie standard
Na czym polega: Specyfikacja to dopiero szkic, a Chrome udostępnia funkcję wyłącznie w ramach origin trial i flagi do testów lokalnych.
Jak stosować: Przed podjęciem decyzji sprawdź w dokumentacji, czy właściwa wersja przeglądarki i agenta obsługuje to, czego potrzebujesz — kwestia wsparcia jest częścią decyzji.
Na co uważać: Mechanizmy testowe zmieniają się między wersjami przeglądarki. Nie wiąż produktu z funkcją, która może się jeszcze istotnie zmienić.
4.Narzędzia nie sprowadzą agentów same z siebie
Na czym polega: Według informacji Google agent musi najpierw odwiedzić stronę, żeby w ogóle odkryć jej narzędzia — sama ich rejestracja niczego nie gwarantuje.
Jak stosować: Oddziel od siebie dwa pytania: „czy agent załatwi coś u nas” (interakcja) i „skąd agent w ogóle tu trafi” (widoczność) — projektuj je osobno.
Na co uważać: Nie obiecuj interesariuszom wzrostu ruchu ani pozycji w wynikach na samym fakcie posiadania narzędzi.
5.Wynik narzędzia to nie badanie konwersji
Na czym polega: To, że narzędzie zwróciło wynik, nie mówi nic o sprzedaży, rankingach ani ruchu. Gdyby mówiło, marketing miałby znacznie łatwiej.
Jak stosować: W argumentacji za wdrożeniem używaj tylko twierdzeń, które umiesz zmierzyć — i mierz je względem stanu sprzed zmiany.
Na co uważać: Demonstracje pokazowe, jak porównanie rezerwacji od Google, są rozpisane z góry — nie traktuj ich ani jako testu szybkości, ani dowodu skuteczności.
6.Przy płatnych akcjach zgoda zostaje w aplikacji
Na czym polega: Wszystko, co niesie realne konsekwencje — na przykład płatna rezerwacja — wymaga zatwierdzenia po stronie aplikacji: pokaż użytkownikowi szczegóły operacji i potwierdź dopiero po jego zgodzie.
Jak stosować: Wbuduj jawny krok akceptacji i przekaż agentowi komplet szczegółów tego, co ma się wydarzyć, zanim cokolwiek wykona.
Na co uważać: Wywołania narzędzi przez agenta same w sobie nie są dowodem zgody użytkownika — brak jawnego potwierdzenia to realne ryzyko.
7.Testuj porażki, nie tylko udane scenariusze
Na czym polega: Zarejestrowane narzędzie to dopiero początek. Sprawdzić trzeba również błędne dane wejściowe, anulowanie i sytuacje awaryjne.
Jak stosować: Przepuść przez testy rzeczywistego agenta, z którego będą korzystać użytkownicy, i przygotuj scenariusze negatywne, a nie wyłącznie udaną rezerwację.
Na co uważać: Testy w innym środowisku niż docelowe mogą dawać wyniki, które się nie powtórzą — używaj właściwego agenta i przeglądarki.
8.Mierz, czy narzędzia w ogóle są używane
Na czym polega: W pilotażu zapisuj dwie rzeczy: czy narzędzia rzeczywiście są wywoływane i czy zadanie kończy się powodzeniem.
Jak stosować: Uruchom jeden mały pilotaż i dopiero potem porównuj wyniki z punktem odniesienia, czyli ze stanem sprzed wdrożenia — na tej podstawie formułuj szersze wnioski.
Na co uważać: Przypadki testowe z repozytorium są zdefiniowane, ale nie zostały niezależnie potwierdzone — własna weryfikacja jest obowiązkowa.
9.Repozytorium web-mcp to punkt startowy, nie gotowiec
Na czym polega: Zestaw zawiera siedem opatrzonych komentarzami szablonów, plik agents.md wskazujący agentowi programistycznemu, co ma przeczytać, oraz wskazówki dotyczące weryfikacji.
Jak stosować: Przekaż agentowi programistycznemu jeden prawdziwy przepływ, informacje o agencie, który ma z narzędzi korzystać, oraz swoje ograniczenia — od tego ma zacząć pracę.
Na co uważać: Szablony nie zawierają logiki twojej aplikacji. To użyteczne punkty wyjścia, ale odpowiedzialność za działanie zostaje po stronie twojej witryny.
10.Pierwszy krok zrób jednym poleceniem
Na czym polega: Rekomendacja autora: przekaż agentowi programistycznemu jedno konkretne pytanie — „Czy powinniśmy dodać Web MCP do naszego procesu rezerwacji?” — i zacznij od oceny.
Jak stosować: Jeśli ocena wypadnie pozytywnie, zbuduj wersję na tyle małą, żeby dało się ją zweryfikować w praktyce.
Na co uważać: Przy odpowiedzi „nie” nie forsujsz tematu — po prostu oszczędzasz sobie całej integracji, co też jest dobrym rezultatem.
Redakcyjne tłumaczenie
Sedno pomysłu: strona, która udostępnia akcje, a nie czeka na kliknięcia
Co, gdyby agent sztucznej inteligencji mógł coś załatwić na twojej stronie, nie przechodząc ręcznie przez każdy krok? Właśnie na tym polega Web MCP. Zaraz pokażę, jak to działa.
Zwykle, korzystając z witryny, odnajduję potrzebne przyciski i pola i przedzieram się przez interfejs krok po kroku. Przy Web MCP to strona udostępnia konkretne akcje, które wywołam bezpośrednio — na przykład sprawdzenie wolnych terminów wizyt. Ja podaję dane wejściowe, strona wykonuje akcję i zwraca wynik.
(Informacja dodatkowa: MCP, Model Context Protocol, to otwarty standard łączenia modeli AI z zewnętrznymi narzędziami i danymi. Web MCP przenosi tę ideę na zwykłe strony internetowe.)
Demo od Google — i jedno prawdziwe wywołanie
Zobaczmy, jak to wygląda w praktyce. Google przygotowało demonstrację rezerwacji, która pokazuje obie drogi obok siebie: po jednej stronie proces idzie przez zwykły interfejs, po drugiej agent wywołuje narzędzia. Od razu zaznaczam, że ta animacja jest rozpisana z góry — to nie jest żaden test szybkości.
Wywołaliśmy też, już z poziomu przeglądarki, narzędzie tylko do odczytu, które zwraca dostępność terminów — i dostaliśmy wynik. Czyli: prawdziwe wywołanie narzędzia, choć na materiale demonstracyjnym.
Wciąż eksperyment — wsparcie trzeba sprawdzić
I teraz najważniejszy szczegół. Web MCP jest na etapie eksperymentu. Specyfikacja to szkic, a nie ukończony standard sieciowy. W dokumentacji Chrome opisano origin trial oraz flagę do testów lokalnych. (Informacja dodatkowa: origin trial to mechanizm Chrome pozwalający włączyć eksperymentalną funkcję odwiedzającym konkretną witrynę, zanim stanie się ona stałą częścią przeglądarki.) Zanim więc cokolwiek zaplanujesz, sprawdź dokładnie tę przeglądarkę i tego agenta, na których realnie zamierzasz pracować. Kwestia wsparcia wchodzi w skład decyzji.
Jest i drugie zastrzeżenie: samo dodanie narzędzi nie sprawi, że agenci automatycznie znajdą twoją witrynę. Zgodnie z informacjami Google agent musi najpierw odwiedzić stronę, żeby w ogóle odkryć jej narzędzia.
Lepsza obsługa to nie większa sprzedaż
Lepsza interakcja to jedno pytanie. Większy ruch, wyższe pozycje w wynikach i więcej sprzedaży to zupełnie inne pytania. To, że narzędzie zwróciło wynik, nie jest jeszcze badaniem konwersji. Gdyby było, marketing miałby znacznie łatwiej.
Repozytorium web-mcp: od oceny po integrację
Dlatego właśnie Daniel przygotował repozytorium web-mcp. To pakiet umiejętności i materiałów odniesienia dla agentów programistycznych. (Informacja dodatkowa: agent programistyczny to narzędzie, które pisze i uruchamia kod na podstawie poleceń w języku naturalnym.)
Zestaw zaczyna się od pożytecznego pytania: czy ta strona w ogóle powinna mieć narzędzia? Proces rezerwacji zawiera akcje, które da się ocenić. Strona, na której ludzie wyłącznie czytają artykuł, może ich nie potrzebować.
Jeśli sens istnieje, repozytorium pomaga wyznaczyć zakres narzędzi, napisać kod i połączyć go z twoim frameworkiem. Znajdziesz w nim siedem opatrzonych komentarzami szablonów oraz wskazówki, jak całość zweryfikować. Zacznij od pliku agents.md — wskazuje on agentowi programistycznemu, które materiały ma przeczytać. Przekaż mu jeden prawdziwy proces, informacje o agencie, który ma z narzędzi korzystać, oraz swoje ograniczenia.
Zatwierdzenie zostaje w aplikacji
Przy wszystkim, co niesie realne konsekwencje — na przykład przy płatnej rezerwacji — ostateczne zatwierdzenie trzymaj po stronie aplikacji. Przygotuj szczegóły. Pokaż człowiekowi, co ma się wydarzyć. Potwierdź dopiero wtedy, gdy wyrazi zgodę. Dwa wywołania narzędzi same w sobie nie dowodzą, że użytkownik się zgodził.
Test na rzeczywistym agencie
Potem przetestuj docelowego agenta — łącznie z błędnymi danymi wejściowymi, anulowaniem i awariami. Zarejestrowane narzędzie to dopiero początek.
Jeden mały pilotaż zamiast wielkich obietnic
Moja rekomendacja jest jedna: przeprowadź mały pilotaż. Zapisuj, czy narzędzia w ogóle są wywoływane i czy zadanie kończy się powodzeniem. Zanim padną większe wnioski, porównaj wyniki z punktem odniesienia, czyli ze stanem sprzed zmiany. Przypadki ewaluacyjne z repozytorium są zdefiniowane, ale nie zostały niezależnie potwierdzone. A szablony i tak wymagają twojej logiki aplikacji. To użyteczne punkty startowe — witryna wciąż pozostaje twoja. Linki do repozytoriów znajdziesz poniżej.
Jedno polecenie na start
Przekaż swojemu agentowi programistycznemu jedno polecenie: „Czy powinniśmy dodać Web MCP do naszego procesu rezerwacji?”. Zacznij od oceny. Jeśli odpowiedź brzmi „tak”, zbuduj coś na tyle małego, żeby dało się to sprawdzić. Jeśli brzmi „nie”, właśnie oszczędziłeś sobie całej integracji.