Mają podobną nazwę. Rozwiązują podobny problem. Działają w zupełnie innych miejscach.
Gdy po raz pierwszy widzisz WebMCP, naturalny odruch to: „to pewnie nowa wersja MCP”. Albo: „skoro mam MCP, to WebMCP mi nie potrzebne”. Oba wnioski są błędne — i ten artykuł wyjaśnia dlaczego.
Zacznijmy od problemu który oba rozwiązują
Agent AI który ma coś zrobić w internecie, musi jakoś „rozmawiać” z zewnętrznymi systemami. Zamówić produkt, wyszukać dane, zapisać użytkownika do newslettera.
Problem: każda strona, każde API, każde narzędzie działa inaczej. Agent musi wiedzieć jak wywołać konkretną akcję — jaki endpoint, jakie parametry, jaki format odpowiedzi.
Bez żadnego standardu agent zgaduje. Robi screenshoty. Klika w DOM. Łamie się przy każdej zmianie CSS.
Zarówno MCP jak i WebMCP dają agentowi kontrakt — „tu jest lista rzeczy które możesz wywołać i jak to zrobić”. Różnica jest w tym gdzie ten kontrakt żyje.
MCP — kontrakt po stronie serwera
MCP (Model Context Protocol) to protokół opracowany przez Anthropic, otwarty dla całego ekosystemu. Działa między modelem AI a serwerem narzędzi — gdzieś poza przeglądarką, po stronie backendu.
Wyobraź sobie agenta który ma dostęp do Twojej bazy klientów, kalendarza i systemu mailingowego. MCP definiuje jak agent pyta serwer: „jakie narzędzia masz?” i jak serwer odpowiada: „mam getCustomer, createEvent, sendEmail„. Agent wywołuje narzędzie, serwer wykonuje akcję.
MCP działa niezależnie od przeglądarki. Agent może działać w terminalu, w aplikacji desktopowej, w automatyzacji n8n — i MCP działa wszędzie tam gdzie jest połączenie z serwerem MCP.
Webflux.pl ma działający endpoint MCP: webflux.pl/wp-json/webflux/v1/mcp. Zewnętrzny agent — Claude przez API, n8n, dowolny klient MCP — może przez ten endpoint zapytać słownik o definicję pojęcia, pobrać listę artykułów, sprawdzić strukturę serwisu. Bez przeglądarki, bez DOM, bez screenshotów.
WebMCP — kontrakt po stronie przeglądarki
WebMCP to standard przeglądarkowy — propozycja W3C, wdrażana przez Chrome i Edge. Działa wewnątrzprzeglądarki, na konkretnej stronie którą użytkownik właśnie ogląda.
Strona rejestruje narzędzia przez document.modelContext.registerTool(). Agent działający w przeglądarce — rozszerzenie Chrome, Copilot w Edge, Claude w Chrome — może te narzędzia wykryć i wywołać.
Kluczowe: WebMCP wymaga przeglądarki z włączoną flagą i agenta który rozumie ten standard. Dziś to Chrome Canary za flagą WebMCP for testing. Za kilka miesięcy — stabilny Chrome i Edge.
Tabela różnic
| MCP | WebMCP | |
|---|---|---|
| Gdzie działa | Serwer ↔ agent | Przeglądarka ↔ agent w przeglądarce |
| Kto to zrobił | Anthropic (otwarty standard) | Google + Microsoft (W3C) |
| Stan w 2026 | Dojrzały, szeroko wspierany | Early preview, Chrome Canary |
| Agent kliencki | Claude API, n8n, terminal | Claude w Chrome, Copilot w Edge |
| Wymaga przeglądarki | Nie | Tak |
| Wymaga backendu | Tak (serwer MCP) | Nie (JS na stronie wystarczy) |
| Kontekst użytkownika | Nie (agent działa autonomicznie) | Tak (agent widzi co robi użytkownik) |
Kiedy potrzebujesz MCP
Budujesz agenta który działa automatycznie — bez udziału użytkownika w przeglądarce. Automatyzacja w n8n, skrypt który codziennie pobiera dane, asystent AI który odpowiada na maile. Agent musi mieć dostęp do Twoich narzędzi i danych przez serwer.
Masz serwis contentowy lub narzędziowy który chcesz udostępnić agentom zewnętrznym — ChatGPT przez Custom Actions, Claude przez MCP client, własne przepływy. Stawiasz serwer MCP i dajesz agentom kontrakt.
Webflux.pl ma MCP endpoint — i dlatego zewnętrzne narzędzia mogą odpytywać słownik, pobierać definicje pojęć, sprawdzać strukturę serwisu bez WebMCP.
Kiedy potrzebujesz WebMCP
Chcesz żeby agent działający w przeglądarce razem z użytkownikiem mógł wykonywać akcje na Twojej stronie bez DOM scraping. Użytkownik rozmawia z Copilotem przeglądając Twój sklep — agent wywołuje addToCart bezpośrednio, nie zgadując gdzie jest przycisk.
Twoja strona ma formularze i akcje których nie chcesz owijać w backend MCP. Zamiast budować serwer, dodajesz kilka atrybutów HTML albo 20 linijek JS — i akcja jest dostępna dla agenta w przeglądarce.
Budujesz aplikację webową (nie tylko serwis contentowy) gdzie agent jest częścią doświadczenia użytkownika — asystent który pomaga w nawigacji, wypełnia formularze, dostosowuje widok.
A jeśli masz oba?
Możesz — i często ma to sens. MCP obsługuje zewnętrznych agentów i automatyzacje. WebMCP obsługuje agentów w przeglądarce podczas aktywnej sesji użytkownika.
Dla webflux.pl to wygląda tak: MCP endpoint pozwala zewnętrznemu agentowi pobrać definicję z słownika. WebMCP pozwoliłoby agentowi w Chrome wywołać simplifyArticle i dostosować treść artykułu do poziomu czytelnika — na żywo, w przeglądarce, bez wychodzenia ze strony.
Oba istnieją jednocześnie. Oba robią różne rzeczy.
Krótko
MCP to API dla agentów działających po stronie serwera. WebMCP to API dla agentów działających po stronie przeglądarki. Podobna nazwa, inny adres w stosie, inne przypadki użycia.
Jeśli Twój agent działa w n8n albo przez Claude API — potrzebujesz MCP. Jeśli Twój agent siedzi w pasku bocznym Chrome i pomaga użytkownikowi który właśnie przegląda Twoją stronę — potrzebujesz WebMCP.
Następny artykuł: Pierwsze demo WebMCP — 98 kroków, 8 kroków i co to znaczy dla agentic web
