W lutym 2026 Google udostępnił WebMCP w Chrome we wczesnym preview. Standard, który ma pozwolić stronom internetowym wystawiać agentom AI strukturalne narzędzia — zamiast zmuszać agentów do klikania po interfejsie zaprojektowanym dla człowieka. Strona deklaruje: „mam funkcję zarezerwuj_stolik, oto jej parametry”. Agent wywołuje tę funkcję bezpośrednio, bez konieczności rozumienia, gdzie na stronie jest formularz rezerwacji.
W kategorii dobrych pomysłów architektonicznych WebMCP zasługuje na wysoką ocenę. To jest właściwa odpowiedź na realny problem — fakt, że agenci AI dziś klikają po UI zaprojektowanym dla ludzi i czasem klikają nie tam, gdzie powinni. Wystawianie strukturalnych narzędzi rozwiązuje to architektonicznie, nie hackowo.
W kategorii produktów gotowych do produkcyjnego wdrożenia WebMCP w kwietniu 2026 nie istnieje.
Te dwa zdania nie są sprzeczne. Ale w polskim internecie 2026 są łączone w jedno — i to jest temat tego wpisu.
Wpis trzeci z pięciu w serii „Czego nie wdrożycie w 2026 — agentic web między hype a produkcją”. Pierwsze dwa wpisy krytykowały koncepty — pay-per-crawl jako monetyzację, llms.txt jako filar SEO. Tu krytyka jest inna. WebMCP koncepcyjnie jest dobry. Krytyka dotyczy momentu wdrożenia. I sposobu, w jaki ten moment jest dziś sprzedawany.
Co reklamują
W ostatnich miesiącach 2025 i pierwszych 2026 wokół WebMCP powstała wyraźna narracja sprzedażowa. Pojawiła się w trzech formach.
Pierwsza — usługa „wdrożenie WebMCP” jako pozycja w cenniku agencji. Niektóre polskie agencje cyfrowe i konsultanci AI zaczęli oferować to jako gotowy pakiet. Klient płaci, agencja konfiguruje stronę pod WebMCP, klient otrzymuje certyfikat „WebMCP-ready” albo podobne marketingowe wyróżnienie.
Druga — narracja konkurencyjna w branżowych mediach. „Strony bez WebMCP będą niewidoczne dla agentów AI w 2027″. „Konkurencja już wdraża”. „WebMCP to nowy schema.org”. Te zdania krążą w postach na LinkedInie, w branżowych newsletterach, w prezentacjach na konferencjach.
Trzecia — narracja inwestycyjna. WebMCP opisywany jako „kierunek, w którym idzie internet”. Czytelnik dostaje sygnał, że teraz jest moment wejścia. Później będzie za późno. Ten, kto zrobi to pierwszy, wygra.
Wszystkie trzy narracje mają wspólną cechę. Pomijają — albo aktywnie ukrywają — kilka faktów, które po sprawdzeniu dokumentacji Chrome i komunikatów innych przeglądarek stają się oczywiste.
Co naprawdę jest
Cztery rzeczy, których w narracji sprzedażowej nie ma.
Po pierwsze — WebMCP jest w preview, nie w stable. To znaczy: jest dostępny tylko w wybranych kanałach Chrome (Canary, Dev), wymaga włączenia flagi eksperymentalnej, jego API może się jeszcze zmienić w sposób niekompatybilny wstecznie. To nie jest funkcja, na której można budować produkt produkcyjny. To jest funkcja, którą można testować, rozumieć, eksperymentować. Sprzedaż „wdrożenia WebMCP” jako gotowej usługi pomija tę kategorialną różnicę — bo gdyby ją uwzględniała, klient zadałby oczywiste pytanie: „kiedy ta funkcja przestanie być eksperymentalna?”. Odpowiedź na to pytanie nie istnieje.
Po drugie — inne przeglądarki nie zadeklarowały wsparcia. Firefox nie ma WebMCP. Safari nie ma WebMCP. Edge dziedziczy silnik z Chromium, więc technicznie mógłby, ale Microsoft nie ogłosił, że uruchamia tę funkcję w swoich kanałach produkcyjnych. To znaczy, że nawet jeśli twoja strona ma WebMCP idealnie skonfigurowane, agenci działający w 35-40% przeglądarek na rynku nie mają jak z niej skorzystać. Wdrożenie produkcyjne, które działa w jednej trzeciej przypadków, to nie jest wdrożenie produkcyjne. To jest eksperyment.
Po trzecie — brakuje agentów konsumujących wystawione narzędzia w skali. WebMCP zakłada, że po drugiej stronie jest agent, który aktywnie szuka strukturalnych narzędzi i z nich korzysta. Dziś takich agentów w produkcji jest niewiele. ChatGPT Atlas, Claude in Chrome, Comet Perplexity — wszystkie są w różnych stadiach rozwoju, żaden nie obsługuje WebMCP w sposób, który dawałby właścicielowi strony przewidywalny, mierzalny ruch agentowy. To znaczy, że nawet idealne wdrożenie po stronie strony nie ma dziś masowego odbiorcy. Inwestujesz w protokół, którego konsumenci jeszcze nie istnieją w skali.
Po czwarte — brak narzędzi diagnostycznych. Jeśli wdrażasz schema.org z JSON-LD, masz Google Rich Results Test, Schema.org Validator, Yandex Structured Data Validator — narzędzia, które w sekundach powiedzą ci, czy zrobiłeś to dobrze. WebMCP w kwietniu 2026 nie ma takich narzędzi. Nie ma sposobu, żeby z zewnątrz zweryfikować, czy twoja konfiguracja działa tak, jak myślisz. Nie ma dashboardu, który pokazuje, ilu agentów skorzystało z wystawionych narzędzi, jakie wywołania działały, jakie zwracały błędy. Wdrożenie bez warstwy diagnostycznej to wdrożenie w ciemno — nie wiesz, czy zadziałało, dopóki masowo nie zadziała.
Te cztery rzeczy razem tworzą obraz, który nie pasuje do narracji sprzedażowej. Agencja, która sprzedaje „wdrożenie WebMCP” w kwietniu 2026, sprzedaje ci konfigurację funkcji eksperymentalnej, działającej w jednej z czterech przeglądarek, dla agentów, których jeszcze nie ma w skali, bez sposobu sprawdzenia, czy działa.
To może mieć sens jako eksperyment. Nie ma sensu jako produkt.
Dlaczego to nie znaczy, że WebMCP nie jest ważny
Tu jest kluczowa różnica między tym wpisem a poprzednimi dwoma. Pay-per-crawl miał problem strukturalny — ekonomia się nie domyka. llms.txt miał problem dowodu — brak pomiaru skuteczności. WebMCP nie ma żadnego z tych problemów. WebMCP ma tylko problem czasu.
Trzy powody, dla których to przyjmie się prędzej czy później.
Pierwszy — architektonicznie to jest dobre rozwiązanie problemu, który realnie istnieje. Agenci AI, którzy klikają po UI zaprojektowanym dla ludzi, są zawodni. Mogą kliknąć nie ten przycisk, wypełnić nie to pole, zinterpretować nie tak. Wystawianie strukturalnych narzędzi eliminuje ten problem u źródła. Strona deklaruje: „oto akcja, oto parametry, wywołaj poprawnie”. Agent nie zgaduje. To jest właściwy kierunek architektoniczny — nie zniknie tylko dlatego, że dziś nie ma jeszcze adopcji.
Drugi — Chrome ma 65%+ udziału w rynku przeglądarek. Funkcja, która wychodzi z preview do stable w Chrome, automatycznie staje się dostępna dla większości użytkowników internetu. Inne przeglądarki, w obliczu masowej adopcji, zazwyczaj dołączają w ciągu kilkunastu miesięcy. To jest historyczny wzorzec — nie gwarancja, ale silna baza obserwacyjna.
Trzeci — MCP jako protokół (nie WebMCP) już działa produkcyjnie. Model Context Protocol jest używany w Claude Desktop, w narzędziach deweloperskich, w integracjach IDE. To znaczy, że fundament WebMCP — sposób komunikacji między agentem a wystawionym narzędziem — jest sprawdzony w innych kontekstach. Chrome rozszerza istniejący protokół na warstwę webową, nie wymyśla od zera. To zwiększa szansę dojrzenia.
To są trzy mocne argumenty za tym, że WebMCP się przyjmie. Nie kiedy się przyjmie — ale że się przyjmie. Pytanie sprowadza się więc do czasu i do strategii: co robić w 2026, kiedy technologia jest obiecująca, ale nie gotowa.
Co zamiast tego zrobić w 2026
Tu jest istotna zmiana w stosunku do poprzednich wpisów serii. Wcześniejsze wpisy mówiły mniej więcej „wdrażaj ostrożnie, ale głównie skup się na czymś innym”. Wpis o WebMCP mówi co innego: eksperymentuj, ale nie sprzedawaj eksperymentu jako produktu.
Trzy konkretne rekomendacje.
Po pierwsze — udokumentuj istniejące API. Jeśli twoja strona ma jakiekolwiek API (REST, GraphQL, webhooks, cokolwiek), zrób tak, żeby było publicznie dostępne, wersjonowane i opisane przez OpenAPI/Swagger. To jest 80% wartości, którą WebMCP obiecuje, dostępne już dziś, bez czekania na specyfikację, bez ograniczenia do jednej przeglądarki, kompatybilne z każdym agentem, który potrafi czytać API. Schema.org dla danych statycznych, OpenAPI dla akcji dynamicznych — to są fundamenty, które przyjmą każdy nowy protokół, kiedy się pojawi. WebMCP, kiedy dojrzeje, prawdopodobnie i tak będzie wystawiał tę warstwę bezpośrednio z OpenAPI spec. Praca, którą wkładasz dziś, nie pójdzie na marne.
Po drugie — eksperymentuj z WebMCP jako wewnętrznym projektem R&D. Jeśli masz zasoby techniczne i chcesz zrozumieć, jak to działa — zainstaluj Chrome Canary, włącz flagę WebMCP, skonfiguruj na swojej stronie testowej. Naucz się. Zobacz, co działa, co nie działa, gdzie są pułapki. To jest wartościowa wiedza na 2027 rok. Ale traktuj to jako naukę, nie jako produkt sprzedawany klientom. Twoje doświadczenie wyniesione z eksperymentu staje się przewagą konkurencyjną, kiedy przyjdzie moment produkcyjnego wdrożenia. Nie staje się przewagą przez sam fakt, że płaciłeś za usługę agencyjną.
Po trzecie — obserwuj cztery wskaźniki adopcji. WebMCP jako produkt w specyfikacji W3C (dziś tam nie jest). Druga przeglądarka ogłaszająca wsparcie (dziś tylko Chrome). Pierwsze publiczne case study z mierzalnym efektem biznesowym (dziś brakuje). Pojawienie się narzędzi diagnostycznych typu „WebMCP Validator” (dziś nie istnieją). Każdy z tych wskaźników, który się ziści, jest sygnałem, że moment produkcyjny się zbliża. Bez żadnego z nich — pozostajemy w fazie preview.
Czego nie warto robić w 2026: kupować „wdrożenia WebMCP” jako gotowej usługi. Sprzedawać tego klientom. Wpisywać do oferty agencyjnej jako pozycję cennikową. Każda z tych decyzji to jest deklaracja, że eksperymentalna funkcja jest produktem — co po prostu nie jest prawdą.
I kluczowe zdanie. Kupowanie wdrożenia WebMCP jako usługi w 2026 jest analogiczne do kupowania w 2007 roku „wdrożenia HTML5″ — funkcji, która istniała w wybranych przeglądarkach, której specyfikacja nie była jeszcze finalna, której ekosystem nie był gotowy, której większość klientów nie miała jeszcze narzędzi do skonsumowania. Eksperymentowanie z HTML5 w 2007 było rozsądne. Sprzedaż „strony zgodnej z HTML5″ jako produktu w 2007 — była sprzedażą przyszłości jako teraźniejszości.
Dziewięć lat później HTML5 stał się standardem, którego nie da się ominąć. WebMCP może mieć tę samą trajektorię. Pytanie tylko, czy chcesz być tym, kto sprzedaje obietnicę dziś — czy tym, kto sprzedaje produkt, kiedy obietnica zamieni się w fakt.
Kiedy wrócić do tematu
Cztery sygnały, które będą znaczyć, że WebMCP wyszedł z fazy „dobra propozycja” do fazy „produkcyjna technologia”.
Pierwszy — WebMCP wychodzi z preview do stable w Chrome. Bez tego cała dyskusja o produkcyjnym wdrożeniu jest bezprzedmiotowa. Stable oznacza, że specyfikacja jest finalna, API stabilne, kompatybilność wsteczna gwarantowana.
Drugi — druga przeglądarka ogłasza wsparcie. Najlepiej Firefox albo Safari, bo to różne silniki renderingu. Edge na Chromium nie liczy się jako „druga przeglądarka” w tym sensie — bo dziedziczy implementację. Druga niezależna implementacja to sygnał, że standard ma faktyczną adopcję, nie tylko jednego dostawcę.
Trzeci — publiczne case study z mierzalnym efektem biznesowym. Nie wzmianka o wdrożeniu. Nie deklaracja „testujemy”. Konkretna firma pokazująca konkretne dane: ile agentów konsumowało wystawione narzędzia, ile transakcji zostało zrealizowanych przez WebMCP, jaki to miał wpływ na ruch albo przychody. Dziś takich case studies nie ma.
Czwarty — pojawienie się narzędzi diagnostycznych i walidacyjnych. WebMCP Validator, narzędzia Chrome DevTools dla WebMCP, dashboardy analityczne pokazujące ruch przez wystawione narzędzia. Bez tej warstwy każde wdrożenie jest w ciemno.
Do żadnego z tych sygnałów dziś nie doszło. Po pierwszym z nich rozsądnie jest zacząć poważnie planować wdrożenie. Po drugim — można zacząć ostrożnie wdrażać. Po trzecim — można już sprzedawać klientom. Czwarty — to znak, że ekosystem jest dojrzały.
WebMCP jest dobrą propozycją. Może być standardem za rok, za dwa lata, za pięć. Dziś jest funkcją w preview Chrome. Eksperymentuj. Ucz się. Czekaj. Ale nie sprzedawaj jako gotowego produktu, rozwiązującego wszystkie problemy agent-readiness, bo gotowy produkt to nie jest. Zresztą to tylko jedna ze składowych całego tematu.
