WebMCP, MCP na poziomie usługi czy zwykłe użycie przeglądarki: gdzie należą narzędzia agentów

Na pierwszy rzut oka WebMCP wydaje się rozsądny. Użytkownik jest już zalogowany, agent działa w przeglądarce, a strona może podać, jakie działania są dostępne, dzięki czemu agent nie musi zgadywać, jakie pola i przyciski istnieją. Problemem jest to, gdzie znajduje się ta interfejs. Gdy wkłada się wysiłek w stworzenie aplikacji użytecznej dla agentów, czy funkcje te powinny być udostępniane przez samą stronę, czy przez usługi znajdujące się pod nią? I co dodaje interfejs narzędzi na poziomie strony do ogólnych narzędzi przeglądarki?

Te dwa pytania stanowią podstawę poniższej oceny.

Czym jest WebMCP

Dzięki WebMCP strona rejestruje ustrukturyzowane narzędzia, które kompatybilny agent może wywołać za pośrednictwem przeglądarki. Każde narzędzie określa, co robi, jakie dane przyjmuje oraz jaki kod je uruchamia. Rejestracja odbywa się w JavaScript lub za pomocą form HTML z adnotacjami. Chrome dokumentuje tę koncepcję jako proponowany standard, którego testy początkowe rozpoczną się wraz z wersją Chrome 149, a API może ulec zmianie.

Wyobraźmy sobie stronę do wyszukiwania lotów. Bez WebMCP agent czyta stronę, znajduje pole z destynacją, ustawia daty i naciska „Szukaj”. Dzięki WebMCP strona mogłaby opublikować narzędzie o nazwie search_flights, które przyjmuje destynację i daty. Agent jedynie wpisuje argumenty, a aplikacja przeprowadza wyszukiwanie.

Należy zachować trzy odrębne ścieżki: MCP na poziomie usług, WebMCP oraz zastosowanie w zwykłych przeglądarkach. Nic nie zmusza do wyboru jednej z nich, a jeden agent może korzystać z narzędzia usługowego dla jednego produktu, narzędzia strony dla innego, a bezpośrednio sterować przeglądarką w przypadku trzeciego.

Problemy architektoniczne

Pierwszą reakcją jest przekonanie, że WebMCP przenosi kwestie związane z usługami do warstwy prezentacyjnej. W typowej aplikacji biznesowej wyszukiwanie towarów, zmiana rezerwacji lub składanie zamówienia kończy się na usłudze backendowej, a przeglądarka i tak wywołuje odpowiedni endpoint, który wykonywać to zadanie. Dlaczego więc definiować kontrakt przeznaczony dla agenta wewnątrz strony, zamiast obok tej usługi?

Naturalną alternatywą jest wykorzystanie istniejącego już kontraktu usługowego, takiego jak specyfikacja OpenAPI lub definicja gRPC, na której budowana jest interfejs MCP. Zaletą jest tu możliwość pełnej kontroli nad nim. Zespół odpowiedzialny za działalność biznesową może zarządzać wersjami, testować i nadzorować kontrakt przeznaczony dla agentów, a interaktywne agenty, zadania zbiorcze oraz zaplanowane procesy mogą go wszystkie wykorzystywać.

Otoczenie wewnętrznego punktu końcowego narzędziem strony nie sprawia, że obowiązki związane z tym kontraktem stają się lżejsze. Agenci otrzymują informacje o operacji wraz z oczekiwanymi danymi wejściowymi i zachowaniem, a procesy ulegają awarii, jeśli to zachowanie się zmieni. Niezależnie od tego, gdzie jest udostępnione narzędzie, zespół musi zdecydować, jaką kompatybilność i wsparcie ono zapewnia, a umieszczenie interfejsu w warstwie webowej samo w sobie nie zmniejsza tych obowiązków.

Bliższe przyjrzenie się temu tematowi podważa niektóre z tych początkowych założeń.

• Przeglądarka przechowuje stan rzeczywisty. Edytor może zawierać niezapisany projekt, aktywny wybór lub lokalne operacje, które nie mają odpowiednika na serwerze, a traktowanie klienta jako pustej obudowy ignoruje to wszystko.
• Logikę nie trzeba duplikować. Narzędzie może wywołać tę samą funkcję klienta co przycisk i przez nią dotrzeć do tego samego punktu końcowego na serwerze. Prawdziwym problemem jest dodatkowy kontrakt narzędzia z własnym cyklem życia oraz sposób, w jaki z biegiem czasu mogą się wokół niego gromadzić reguły biznesowe.

Przepływy między kilkoma ekranami to trudny przypadek. Wybór kilku lotów, przypisanie pasażerów oraz weryfikacja rezerwacji przed jej wysłaniem mogą być znacznie tańsze, jeśli wykorzysta się istniejące mechanizmy koordynacji klienta. Sekwencja napisana wyłącznie dla agenta rodzi pytanie, które elementy stanowią prezentację, a które reguły biznesowe. Kryteria dostępności i upoważnienia powinny znajdować się w usłudze, a gdy narzędzie strony i narzędzie usługi są sprzeczne, ktoś musi zająć się tym niezgodnością oraz wspólnym zestawem sprawdzeń umownych.

Trasa usługi jest trudniejsza, niż się wydaje. Automatyczne generowanie narzędzi na podstawie setek punktów końcowych API nie przynosi użytecznej interfejsu dla agenta. Opisy muszą być sformułowane z myślą o agencie, odpowiedzi muszą mieć ograniczenia co do długości, niektóre operacje powinny zostać połączone, a osoba odpowiedzialna musi zdecydować, co ma zostać udostępnione.

Również stopień dojrzałości ma znaczenie. Oczekuje się pewnego stopnia eksperymentowania, ale interfejs oparty na zmieniającej się API przeglądarki dodaje kolejne źródło prac konserwacyjnych.

Dlatego bardziej precyzyjne stanowisko brzmi tak, że trwała operacja biznesowa powinna być zarządzana najbliżej usługi, która ją implementuje, a umieszczenie jej kontraktu na stronie wymaga konkretnego powodu.

Ponowne wykorzystanie sesji versus uprawnienia delegowane

Korzyści z autoryzacji wynikają z pracy w przeglądarce z zalogowanym użytkownikiem, a WebMCP oraz zwykła przeglądarka korzystają z tych samych możliwości. Porównanie to stawia tę wygodę w opozycji do uprawnień do usług delegowanych. To, co dodają specjalne narzędzia WebMCP w porównaniu z zwykłą interakcją z przeglądarką, to zupełnie inna kwestia, omówiona dalej.

Gdy agent kliknie w element sterujący na stronie zalogowanej kontem użytkownika, aplikacja wysyła swoją prośbę w ramach istniejącej sesji, a narzędzie WebMCP uruchomione bezpośrednio może korzystać z tej samej sesji. Żadna z tych struktur nie wymaga oddzielnego upoważnienia delegowanego pomiędzy hostem agenta a usługą.

Zalety to rozprzestrzeniają się na różne aplikacje. Przepływ pracy obejmujący pięć usług może wymagać pięciu upoważnień, pięciu cykli życia tokenów oraz pięciu zestawów wymagań integracyjnych, plus procedur rejestracji klienta zależnych od każdej z usług. Jeśli użytkownik jest już zalogowany na wszystkich pięciu stronach, ponowne wykorzystanie tych sesji pozwala uniknąć dużej części tych konfiguracji.

Nazywanie tego bezpłatną autoryzacją byłoby przesadą. Żywa sesja ma swój własny cykl życia bezpieczeństwa, a zalogowanie się nie oznacza zgody na wszystko, co agent może spróbować zrobić. Mimo to oszczędność wynikająca z integracji jest rzeczywista. Iniekcja poleceń i niechciane działania nie zostaną rozwiązane poprzez wybór określonej warstwy, ponieważ obie ścieżki wymagają zabezpieczeń, takich jak potwierdzenie przed wykonaniem istotnych operacji, z różnym stopniem ekspozycji i egzekwowania, dlatego każdy projekt musi samodzielnie ocenić te ryzyka.

W jaki sposób CIMD zmniejsza tę luki

Dostęp na poziomie usługi również się poprawia. Dokumenty metadanych identyfikatora klienta (CIMD) rozwiązują jeden z problemów związanych z protokołem OAuth: jak zupełnie nowy klient identyfikuje się przed serwerem autoryzacji, który nigdy wcześniej z nim nie spotkał się. Klient używa adresu URL typu HTTPS jako swojego identyfikatora, a ten adres dostarcza dokument metadanych zawierający informacje takie jak dozwolone adresy URI do przekierowania. Serwer wspomagający pobiera i sprawdza ten dokument, co eliminuje konieczność wcześniejszej rejestracji każdej pary klient-serwer. Specyfikacja autoryzacji MCP z listopada 2025 roku zaleca wspieranie formatu CIMD i preferuje go nad dynamiczną rejestracją klientów, gdy nie ma wcześniej zarejestrowanych danych o klientach.

W przypadku pięciu usług CIMD zapewnia wsparcie na wszystkich pięciu serwerach autoryzacji, co eliminuje konieczność wcześniejszej rejestracji. Wymagania autoryzacyjne oraz cykle życia tokenów dla poszczególnych usług pozostają bez zmian, chociaż istniejące uprawnienia lub sesje mogą zmniejszyć liczbę pytań, więc niekoniecznie będzie potrzeba pięciu nowych logowań. Same decyzje autoryzacyjne nie są dotknięte przez CIMD.

Kontekst, cykl życia i odkrywanie

Niesoхранiony dokument pokazuje wartość lokalnego stanu przeglądarki. Narzędzie edytujące wybrany akapit w nieukończonym projekcie pracuje ze stanem, którego usługa wcześniej nie widziała, co stanowi bardziej konkretny powód do udostępnienia narzędzia na stronie niż przekierowania operacji backendowej.

Problem polega na tym, że lokalny stan wiąże narzędzia z stroną. Gdy użytkownik przechodzi gdzie indziej lub zamyka stronę, agent może musieć najpierw ponownie otworzyć aplikację i odbudować kontekst. Sesja logowania może przetrwać zamknięcie strony, natomiast znika niesoхранiony stan lub narzędzia, które tam znajdowały się.

Odkrywanie to odrębna kwestia: jak agent dowiaduje się, co oferuje dana strona? Dokumentowane ograniczenia Chrome stanowią, że strona musi zostać odwiedzona, zanim będą znane jej narzędzia WebMCP. Znany punkt końcowy MCP można zapytać bezpośrednio, bez udziału interfejsu użytkownika, ale znalezienie takiego punktu na podstawie zwykłego adresu internetowego to odrębne wyzwanie. Metadane OAuth pozwalają jedynie znaleźć serwer autoryzacji dla już znanego zasobu chronionego, bez uniwersalnego spisu możliwości MCP.

SEP-2127, zatytułowany MCP Server Cards, proponuje standardowy sposób publikowania ustrukturyzowanych metadanych serwera przez HTTP, aby klienci mogli odkrywać interfejsy usług przed nawiązaniem połączenia MCP i bez konieczności utrzymywania strony przeznaczonej dla użytkowników. To obiecujący kierunek rozwoju. W chwili pisania tego tekstu wniosek jest nadal otwarty, więc stanowi jedynie propozycję rozwiązania brakującego w obecnym stanie rzeczy, a nie rozwiązanie przyjęte powszechnie, które można zakładać wszędzie.

Żadna ze stron nie ma oczywistej przewagi w zakresie odkrywania informacji – narzędzia oparte na stronach wymagają wizyty na stronie, natomiast odkrywanie usług z dowolnego adresu nie ma jeszcze uniwersalnych zasad. Żaden z tych poziomów również nie gwarantuje dobrego zarządzania, ponieważ narzędzia WebMCP mogą być dobrze przetestowane i utrzymywane, podczas gdy narzędzia służące do obsługi usług mogą być źle zaprojektowane. Prawdziwym pytaniem jest kwestia odpowiedzialności oraz to, jakie procesy pracy musi obsługiwać dany interfejs.

Agenty przeglądarek już działają bez niego

Warto sprawdzić, co agent przeglądarki może poznać bez WebMCP. W ramach jednej sesji na komputerze z narzędziami do przeglądarek preferowane były działania na elementach oparte na dostępności, gdzie to możliwe, z wykorzystaniem zrzutów ekranu jako kontekstu wizualnego lub jako rozwiązania awaryjnego, a informacje o dostępności zwracane dla strony dokumentacyjnej były pomocne. Jest to obserwacja specyficzna dla danej sesji, a nie stwierdzenie dotyczące każdej wersji lub ustawień domyślnych.

Integracja dostarczyła agentowi ustrukturyzowany opis renderowanej interfejsu, zawierający pola tekstowe, przyciski, etykiety, wartości i stany, a narzędzia zorientowane na DOM były dostępne do wykonywania odpowiednich zadań. Większa część treści strony pojawiła się w formie ustrukturyzowanego tekstu, a nie tak, jak przewidywałyby oczekiwania oparte głównie na zrzutach ekranu. W przypadku prostego formularza wyszukiwania agent mógł otrzymać coś w tym rodzaju.

1 textbox “Destination”, value: “Tokyo”
2 button “Search flights”, enabled

Na tej podstawie agent może zidentyfikować pole destynacji, kliknąć przycisk „Szukaj lotów” i sprawdzić aktualny stan. Semantyka HTML oraz etykiety dostępności już zawierają dużą część znaczenia interfejsu. To, jaką wersję strony otrzymuje model, zależy od integracji, a nie od nazwy modelu, a dokumentacja OpenAI dotycząca używania komputera pokazuje przykłady integracji, w których zrzuty ekranu trafiają do modelu, a działania są zwracane za pośrednictwem narzędzi dostarczonych przez aplikację.

Wynikiem jest to, że agenty mogą obsługiwać stronę bez WebMCP, co zmniejsza ilość elementów, które muszą zaimplementować twórcy stron. To jednak nie decyduje o tym, czy WebMCP jest przydatny. Drzewo dostępności wymienia elementy sterujące, natomiast dobrze zaprojektowane narzędzie może opisać całą operację wraz z jej parametrami, redukując konieczność interakcji i domysłów. Tam, gdzie agent przeglądarki pracuje za pośrednictwem dziesięciu elementów sterujących, aplikacja mogłaby zaoferować jedno narzędzie do wykonywania tej czynności. Chrome przedstawia WebMCP jako element postępowego ulepszania i zawiera inspektor do testowania narzędzi.

W ramach tej oceny nie przeprowadzono kontrolowanego porównania z użyciem i bez narzędzi WebMCP, więc jest to ocena architektoniczna, a nie wynik dotyczący wydajności. Sprawiedliwy werdykt wymagałby pomiaru czasu ukończenia zadania, liczby interakcji oraz czasu trwania w różnych procesach pracy. Jeden udany demo to dobry punkt wyjścia, ale nie odpowiada na to szersze pytanie.

To, co można wdrożyć, zależy również od tego, jakie interfejsy kontroluje zespół. WebMCP wymaga współpracy strony, a integracja usług potrzebuje dostępnego, upoważnionego interfejsu usługowego. W przypadku aplikacji zewnętrznych, które nie oferują żadnego z tych elementów, jedynym możliwym rozwiązaniem może być zwykłe korzystanie z przeglądarki.

Jak to wygląda w praktyce

Punkty wyjścia wynikające z tego wszystkiego to:

• Narzędzia na poziomie usług nadają się do trwałych operacji biznesowych, szczególnie w przypadku procesów pracujących bez nadzoru lub przez długi czas.
• WebMCP jest odpowiedni, gdy ma znaczenie stan lokalnej aplikacji lub gdy ponowne użycie autoryzowanego workflow klienta pozwala zaoszczędzić wiele pracy związanej z integracją.
• Zwykłe korzystanie z przeglądarki obejmuje przypadki, w których brakuje dedykowanych narzędzi, zwłaszcza aplikacje poza kontrolą zespołu.

Wciąż istnieje niepokój, gdy WebMCP staje się domyślnym miejscem dla funkcji, które już mają wyraźne granice usługowe. Wygoda korzystania podczas sesji to silny argument na rzecz takiej implementacji, ale nie powinna sama decydować o architekturze długoterminowej.

Dowody, które mogłyby zmienić to spojrzenie, pokazałyby, że dla określonej aplikacji narzędzia zdefiniowane na poziomie strony znacznie przewyższają standardowe funkcje przeglądarki, oferując niższe całkowite koszty w porównaniu z tworzeniem i utrzymywaniem interfejsu usługowego – koszty te obejmują autoryzację, konserwację, zarządzanie oraz procesy pracy, których interfejs nie może obsłużyć.

WebMCP funkcjonuje najlepiej, gdy zachodzą trzy warunki: aktywna, uwierzytelniona sesja, cenne dane lokalne oraz procesy klienta nadające się do ponownego użycia. Zwykłe korzystanie z przeglądarki również umożliwia ponowne wykorzystanie sesji, więc pozostaje otwarte pytanie, jakie konkretne narzędzia przyczyniają się do tego efektu. Narzędzie strony, które jedynie przekazuje operację do usługi, nadal wymaga uzasadnienia dla przechowywania na stronie kontraktu skierowanego do agenta.