Wasza strona jest niewidoczna dla agentów AI. WebMCP to zmienia, a kod to najłatwiejsza część.

W zeszłym miesiącu posadziłem agenta AI przed stroną jednego z naszych klientów, sklepem opartym na React. Kazałem mu zrobić prostą rzecz: wybrać produkt, dodać do koszyka, policzyć dostawę do Norwegii. Agent wybrał produkt z kategorii obok. Potem trafił na stronę z polityką zwrotów, bo wyglądała jak coś, w co można kliknąć. Koszt dostawy policzył o 40% za wysoko, bo zgadywał z treści, której nie rozumiał.

Ta strona była na pierwszej pozycji w Google na swoją główną frazę. Dla człowieka działała bez zarzutu. Dla agenta nie istniała.

To nie jest historia o jednym sklepie. To jest opis tego, co dzieje się teraz z większością stron w Polsce, w momencie, w którym agenci AI zaczynają na nich działać zamiast ludzi. I dlatego chcę, żebyś przeczytał ten tekst do końca, nawet jeśli słowo WebMCP widzisz dziś pierwszy raz.

Co z tego wyniesiesz?

Wytłumaczę, czym jest WebMCP i czym różni się od MCP, które pewnie już gdzieś mignęło. Pokażę, jak to wygląda w kodzie, żeby było jasne, że bariera techniczna jest niska. A potem zrobię rzecz, której większość artykułów na ten temat nie robi: powiem, gdzie naprawdę leży trudność, bo to nie jest kod. I dlaczego to ma bezpośredni związek z tym, czy Twoja firma będzie widoczna dla agentów AI za rok.

Prowadzę startupy i projekty cyfrowe od 2011 roku. Testowałem kilkanaście modeli biznesowych na własnych pieniądzach. Część nie wyszła. Nauczyłem się jednej rzeczy, która sprawdza się zawsze: kto rozumie nową technologię o rok wcześniej niż rynek, ma rok przewagi. W cyfrowym Świecie rok to bardzo dużo.

WebMCP jest dokładnie w tym miejscu. Dokumentacja jest we wczesnym dostępie, w Polsce prawie nikt o tym głośno nie mówi, większość deweloperów nie słyszała tego słowa. To jest ten moment, w którym warto się zatrzymać. Mój wspólnik przysłał mi link w piątek wieczorem. W sobotę rano, przy kawie, po dwóch godzinach czytania miałem jedno mocne poczucie: firmy, które eksperymentują z tym teraz, za rok będą miały gotowe wdrożenia i case studies. Reszta będzie gonić. To nie jest dramatyzowanie, to wzorzec, który widziałem przy każdej technologii, która się przyjęła.

Co to jest WebMCP i czemu to nie to samo co MCP

Zacznę od rozróżnienia, bo widzę już teksty, które mieszają te dwie rzeczy, a to prowadzi do złych decyzji budżetowych. Wyobraź sobie, że Twoja strona to sklep zaprojektowany dla ludzi. Klient wchodzi, czyta, klika, kupuje. Działa, bo człowiek rozumie kontekst. Widzi formularz i wie, że to formularz. Teraz do tego samego sklepu wchodzi agent AI. Widzi te same elementy, ale ich nie rozumie. Zgaduje. Klika w złe miejsce. To jest dokładnie ta sytuacja z początku tekstu.

WebMCP mówi: nie każ agentowi zgadywać, daj mu instrukcję obsługi napisaną jego językiem. Twoja strona przestaje być biernym interfejsem dla człowieka i staje się aktywnym partnerem dla agenta.

MCP, o którym mogłeś słyszeć, to co innego. Model Context Protocol działa po stronie backendu i łączy agenta z Twoimi systemami niezależnie od tego, czy ktokolwiek ma otwartą przeglądarkę. WebMCP działa tylko wtedy, gdy użytkownik jest na Twojej stronie. Agent widzi, co strona umie zrobić w tym konkretnym momencie, a gdy karta się zamyka, narzędzia znikają. Google nazywa to efemerycznym cyklem życia, co brzmi poważnie, a w praktyce znaczy tyle: WebMCP żyje razem z sesją użytkownika.

Najlepsze wdrożenia używają obu naraz. MCP do logiki w tle, WebMCP do interakcji z tym, co użytkownik widzi na ekranie. Partnerzy, nie zamienniki. I już tu, na poziomie tego jednego zdania, zaczyna się trudność, o której piszę niżej: ktoś musi zdecydować, co należy do którego świata. Złe rozdzielenie to wdrożenie, które wygląda na gotowe, a nie działa.

Jak to wygląda w kodzie? Łatwiej niż myślisz!

Dobra wiadomość: bariera wejścia jest zaskakująco niska. Nie kupujesz GPU, nie zatrudniasz data scientista. Dodajesz kilka linii kodu.

Jeśli masz na stronie zwykłe formularze, dodajesz do nich specjalne atrybuty, a przeglądarka sama buduje z nich opis narzędzia dla agenta. Formularz kontaktowy, wyszukiwarka, kalkulator wyceny, rezerwacja. Każda z tych rzeczy może dostać instrukcję obsługi dla AI w kilka minut roboty.

Jeśli Twoja strona to nowoczesna aplikacja w React albo Vue, rejestrujesz narzędzie ręcznie:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "calculate_shipping",
    description: "Oblicza koszt wysyłki na podstawie wagi i kraju",
    parameters: {
      type: "object",
      properties: {
        weight: { type: "number", description: "Waga w kg" },
        country: { type: "string", description: "Kod kraju ISO" },
      },
      required: ["weight", "country"],
    },
    execute: async (args) => {
      const cost = await myApp.logic.getShipping(args.weight, args.country);
      return { cost: cost, currency: "PLN" };
    },
  });
}

Tu wystawiasz agentowi dowolną logikę aplikacji, nie tylko to, co wygląda jak formularz. U tego klienta z React, od którego zacząłem ten tekst, implementacja narzędzia do kosztów dostawy zajęła deweloperowi jeden dzień, razem z testami. Po wdrożeniu agent przeszedł przez wybór produktu i dostawę bez ani jednej próby zgadywania. Ten sam agent, który tydzień wcześniej liczył o 40% za dużo.

Jedna uwaga, którą daję każdemu: nazwy atrybutów i API są we wczesnym dostępie i będą się zmieniać. Wdrażając, sprawdzaj aktualną dokumentację Google, nie kopiuj z artykułów sprzed kwartału. W tym też nie. Ironia zamierzona.

Gdzie naprawdę leży trudność?

Skoro deweloper robi to w dzień, to po co komu agencja? To uczciwe pytanie i odpowiem na nie uczciwie.

Trudne nie jest dodanie trzech atrybutów do formularza. Trudne są cztery decyzje, których kod za Ciebie nie podejmie.

Pierwsza: które narzędzia w ogóle wystawić. Wystawisz za mało, agent nie zrobi nic sensownego. Wystawisz za dużo albo nie te, otwierasz furtki, których nie chcesz otwierać. To jest decyzja o tym, co Twoja firma pozwala robić maszynie w swoim imieniu, a nie zadanie dla juniora od frontendu.

Druga: jak opisać narzędzie, żeby agent je zrozumiał i wybrał. Agent czyta description i parametry inaczej, niż człowiek czyta nagłówek. Dobry opis to różnica między tym, że agent wybierze Twoje narzędzie, a tym, że pójdzie do konkurencji, bo jej opis był jaśniejszy. To jest praca na styku UX i copywritingu, tyle że odbiorcą jest model językowy.

Trzecia: jak nie rozsypać się przy zmianie specyfikacji. Standard jest wczesny, będzie się ruszał. Wdrożenie zrobione raz i zapomniane za pół roku przestanie działać po cichu, a Ty się o tym dowiesz, gdy klient ci to zgłosi. Albo nie zgłosi, tylko pójdzie gdzie indziej.

To jest dokładnie ten moment, w którym wchodzimy my. Nie po to, żeby dodać atrybuty do formularza, bo to faktycznie zrobi Twój deweloper. Po to, żeby ktoś podjął te cztery decyzje na podstawie doświadczenia, a nie na podstawie pierwszego wdrożenia w życiu. Pierwsze wdrożenie WebMCP zawsze jest najtrudniejsze. My swoje pierwsze mamy już za sobą.

Dlaczego to ma związek z SEO i widocznością Twojej firmy. Przez dekadę SEO miało prostą logikę. Piszesz treści, dbasz o linki, czekasz na Google. Dziś Google coraz rzadziej pokazuje listę wyników, coraz częściej gotową odpowiedź wygenerowaną na ich podstawie. Twoja strona może być na pierwszej pozycji i nie istnieć w tej odpowiedzi.

WebMCP to kolejny krok w tym samym kierunku. Strona dobrze opisana dla agentów istnieje w ich kontekście. Strona, która nie jest, po prostu nie istnieje, tak samo jak strona bez metatagów nie istniała dla Google dziesięć lat temu.

Ma to też wpływ na to, jak często warto pisać na firmowym blogu. Agenci czytają treści na bieżąco. Strona, która publikuje raz na kwartał, nie żyje w ich kontekście. Rytm, który działa pod to, co branża zaczyna nazywać GEO (Generative Engine Optimization), to dwa do czterech wartościowych artykułów miesięcznie. Nie żeby było. Żeby agent miał co czytać i co cytować. I pisać trzeba inaczej, bo agent nie ma cierpliwości do dziesięciu akapitów wstępu. Szuka struktury, faktów, konkretów. Czytelnik ludzki wybaczy Ci dygresję. Agent pójdzie do konkurencji i zabierze ze sobą Twoich klientów.

Co tracisz, czekając?

Czy musisz wdrażać to w tym tygodniu? Nie. Standard jest wczesny, nie wszystkie przeglądarki go w pełni obsługują, większość Twoich klientów jeszcze nie używa agentów codziennie. To jest pytanie o minimum, nie o strategię.

Czy Twoja konkurencja już to testuje. Część tak. Mówię o firmach, które mają zwinnego partnera technologicznego albo własny dział R&D i śledzą, co Google wypuszcza. Gdy WebMCP stanie się powszechnym standardem, a wedle obecnych sygnałów stanie się w ciągu roku do dwóch, różnica między firmą z półrocznym doświadczeniem a firmą startującą od zera będzie bardzo widoczna. W widoczności u agentów. W konwersji. W tym, kogo AI wybierze jako odpowiedź na pytanie użytkownika.

Trzy lata temu większość firm uważała ChatGPT za zabawkę dla geeków. Dziś firma bez żadnej strategii AI budzi uzasadnione pytania. Z WebMCP będzie tak samo, tylko szybciej, bo bariera wejścia jest dużo niższa. Nie inwestujesz w infrastrukturę. Musisz dodać kilka linii kodu i wiedzieć, co robisz. Akcent stawiam na drugą połowę tego zdania.

Czego nie robić?

Widziałem ten wzorzec przy RODO, przy mobile-first, przy AI. Firmy ogłaszały gotowość głośno, a wdrażały powierzchownie. Za każdym razem kosztowało je to więcej niż te, które milczały, ale zrobiły porządnie.

Najgorsze, co możesz zrobić, to ogłosić, że jesteś WebMCP-ready, podpiąć trzy atrybuty do formularza kontaktowego i uznać temat za zamknięty. Jeden element zrobiony sensownie i opisany uczciwie jest wart więcej niż dziesięć zrobionych na pokaz. Klienci i agenci AI to wyczują, każdy na swój sposób.

Co zrobić od poniedziałku

Krok pierwszy. Wejdź na stronę Google Chrome Early Preview Program i zarejestruj się. Pięć minut, dostęp do aktualnej dokumentacji i środowiska testowego.

Krok drugi. Wybierz jeden element na swojej stronie, który realnie pracuje na Twój biznes. Kalkulator wyceny, wyszukiwarka, rezerwacja. Jeden, nie dziesięć. To jest test, nie wdrożenie całej witryny, więc niech będzie tani i mierzalny.

Krok trzeci. Zanim oddasz to deweloperowi, zadaj sobie cztery pytania z sekcji o trudności. Jeśli na któreś nie znasz odpowiedzi, to nie jest powód, żeby odpuścić. To jest powód, żeby pogadać z kimś, kto już przez to przeszedł, zanim wydasz pierwszą złotówkę na coś, co trzeba będzie potem przerabiać.

Krok czwarty. Opisz, co wyszło. Na blogu, w rozmowach sprzedażowych. Nie jako deklarację gotowości na AI, bo to pusta fraza, tylko jako opis eksperymentu z wnioskami. Co działało, ile zajęło, co zrobiłbyś inaczej. Ten rodzaj treści buduje wiarygodność szybciej niż cokolwiek innego, bo pokazuje, że rozumiesz technologię od środka, a nie z nagłówków.

WebMCP to nie kolejna pozycja do odhaczenia na liście. To zmiana w tym, jak strony istnieją w świecie agentów AI. Można na to patrzeć jak na obowiązek albo jak na okazję. Ja na każdą nową technologię patrzę przez jedno pytanie: kto skorzysta na tym, że zrozumie ją wcześniej. Tym razem odpowiedź jest prosta. Skorzysta ten, kto ma stronę gotową do rozmowy z AI, zanim jego klienci zaczną tej rozmowy oczekiwać. A zaczną.

Sprawdź, czy Twoja strona jest gotowa na agentów AI

W adream zaczynamy od audytu gotowości technicznej w ramach pierwszej rozmowy. Dostajesz konkretną listę: co działa, co wymaga zmiany, co ma sens dla Twojego biznesu, a co jest tylko modą. Bez lejka na piętnaście slajdów z buzzwordami.

Te cztery decyzje z sekcji o trudności przerabiamy z klientami na ich własnych stronach. To jest dokładnie ta rozmowa, którą warto odbyć, zanim Twój deweloper dotknie kodu. Wypełnij brief na adream.pl/briefi dopisz, że chodzi o WebMCP. Odpiszemy w dwa dni robocze z konkretnymi obserwacjami, nie z ofertą na trzy strony.