MCP vs REST: kiedy co wygrywa dla integracji agentów AI

#MCP vs REST: kiedy co wygrywa dla integracji agentów AI

Traktowanie MCP i REST jako alternatyw to zła rama. Siedzą na różnych warstwach: REST to transport plus konwencje, MCP to typowany protokół zaprojektowany pod konsumenta LLM. Realna decyzja to z którą powierzchnią rozmawia każdy konsument i jak dwie powierzchnie dzielą backend. Ten artykuł podaje framework, którego używam przy wycenie integracji AI dla projektów WordPress i WooCommerce.

Artykuł osadzony jest w filarze budowa serwera MCP.

#TL;DR

• MCP i REST są komplementarne, nie alternatywne.
• REST wygrywa dla deterministycznych klientów z hardkodowanym zestawem akcji i dokumentacją OpenAPI.
• MCP wygrywa dla agentów LLM potrzebujących discovery narzędzi w runtime i typowanych envelope’ów mutujących.
• Default produkcyjny to REST jako system of record, MCP jako powierzchnia agenta z przodu.
• Ten sam backend, dwie powierzchnie, jedna prawda.

#Czym są oba protokoły

REST. Styl architektoniczny z dysertacji Roya Fieldinga z 2000 roku (źródło dysertacji), zwykle wyrażany przez HTTP z czasownikami i URL-ami zasobów. WordPress udostępnia REST API pod /wp-json/wp/v2/ (handbook REST API WordPressa); WooCommerce rozszerza go pod /wp-json/wc/v3/. Dokumentacja to zwykle OpenAPI (specyfikacja OpenAPI), a SDK są generowane z schematu w build-time.

MCP. Protokół oparty na JSON-RPC 2.0, ogłoszony przez Anthropic 25 listopada 2024 (ogłoszenie Anthropic) do łączenia hostów LLM (Claude Desktop, IDE, własne runtime’y agentów) z danymi i narzędziami. Trzy prymitywy: tools (wywoływalne funkcje), resources (odczytywalne dokumenty), prompts (szablony serwerowe). Discovery dzieje się w runtime przez tools/list; agent uczy się dostępnych możliwości każdej sesji.

Z dystansu kształty wyglądają podobnie. Pod obciążeniem szybko się rozjeżdżają.

#Macierz decyzyjna

Sześć czynników, które oceniam, zanim wybiorę powierzchnię dla danej akcji:

Macierz mówi mi, który protokół jest preferowany dla jednej akcji, a nie dla całego API. Większość projektów ląduje rozdzielona.

#Gdzie REST wyraźnie wygrywa

Sklep pobierający stronę kategorii. Hardkodowany przeciw /wp-json/wp/v2/categories?slug=widgets. Kształt znany, nagłówki cache działają, CDN może cache’ować po URL-u.

Integracja ERP partnera synchronizująca magazyn dziennie. Zespół partnera czyta OpenAPI, generuje typowane SDK, planuje cron na 03:00 UTC. Chcą stabilnych URL-i, przewidywalnych kształtów odpowiedzi i kodów statusu HTTP. MCP dodałby złożoność bez wartości.

Publiczny anonimowy ruch odczytu. Crawler SEO uderzający w strony produktów, agregator porównywarek pobierający feedy. REST plus rate limiting obsługuje ten przypadek najbardziej dojrzałą infrastrukturą.

Dostarczanie webhooków. WooCommerce wystrzeliwuje woocommerce_order_status_completed do endpointa partnera. Endpoint partnera to odbiorca REST. MCP to zły kształt, bo agent nie jest w pętli; odbiorca to system deterministyczny.

#Gdzie MCP wyraźnie wygrywa

Agent LLM działający na swobodną intencję użytkownika. “Znajdź mi wodoodporną kurtkę poniżej 800 zł, która dojedzie do Warszawy.” Agent z góry nie wie, jaką kombinację filtrów zastosować; musi introspektować dostępne narzędzia, czytać opisy, decydować. REST daje mu 47 parametrów query w trzech endpointach i żadnego sygnału, który zastosować.

Akcje mutujące, gdzie idempotencja ma znaczenie. Tworzenie zamówienia z LLM-a jest najgłośniejszym przykładem. Narzędzie MCP order.intent z typowanym schematem wejścia i kluczem idempotencji to ciaśniejszy kontrakt niż swobodne wywołanie POST /wp-json/wc/v3/orders. Retry są bezpieczne z założenia, a nie z konwencji.

Powierzchnia narzędzi ewoluująca często. Dodanie nowego filtra wyszukiwania lub nowego typu produktu oznacza wypuszczenie nowego narzędzia MCP z blokiem describe; agent podchwytuje je przy następnym tools/list bez zmian kodu po stronie agenta. Przy REST każda zmiana to skoordynowane wydanie SDK.

Wieloetapowe przepływy agenta. “Sprawdź, czy SKU AC-101 jest na stanie; jeśli nie, zaproponuj trzy alternatywy; jeśli jest, zaproponuj zamówienie.” Każdy krok to jedno wywołanie narzędzia; agent je komponuje. Przy REST agent musi zakuć kształt przepływu w prompcie.

#Gdzie leży granica

Dla typowego projektu WooCommerce rysuję granicę tak:

Handlery narzędzi serwera MCP wołają te same endpointy /wp-json/wc/v3/, których używają konsumenci REST. Jedno źródło prawdy dla warstwy danych, dwie powierzchnie dla dwóch typów konsumenta.

#Kompromisy auth

Uwierzytelnianie REST jest dobrze przeorane: tokeny bearer, OAuth 2.x, basic auth do developmentu. Konwencja mówi “posiadacz tokena może to, co dokumentacja pozwala.” Doszlifowanie scope’ów dzieje się per endpoint na poziomie aplikacji.

MCP odsyła do tych samych wyborów warstwy transportu, ale SDK zachęca do tagowania scope’ów per narzędzie. Pojedynczy token OAuth może nieść orders:read bez orders:write, a serwer MCP wymusza to przy każdym wywołaniu narzędzia. Wzorce OpenAPI wspierają tę samą ideę przez securityDefinitions i security per operacja, ale w praktyce większość API REST dokumentuje pojedynczy globalny scope i pozostawia aplikacji rozwiązanie drobniejszej granulacji.

Konkretnie dla integracji agentów mapowanie scope’u per narzędzie w MCP jest realnym ergonomicznym zyskiem, pasującym też do wymagań RODO o minimalizację danych. Użytkownik nadaje agentowi orders:read; agent dosłownie nie potrafi wywołać order.cancel, bo serwer MCP odrzuca go z forbidden przed uruchomieniem handlera. Powierzchnia auth jest pod spodem ta sama co REST, ale kontrakt jest czytelniejszy zarówno dla użytkownika, jak i dla agenta.

#Cache

REST ma dekady infrastruktury cache HTTP: nagłówki Cache-Control, rewalidacja ETag, reguły Vary, cache na CDN-ie, w przeglądarce, w pośrednich proxy. Odpowiedź GET /wp-json/wc/v3/products?stock_status=instock z Cache-Control: public, max-age=60 cache’uje się na edge bez dodatkowej pracy.

MCP nie ma nic z tego. Odpowiedzi narzędzi jadą jako payloady JSON-RPC w żądaniach POST. Nagłówki cache HTTP nie wchodzą. Cache musi się dziać na poziomie aplikacji, w handlerze narzędzia, przeciw jawnemu kluczowi wywiedzionemu z wejścia. To jest OK, gdy handlery serwera MCP same cache’ują wywołanie REST w górę (co robię na produkcji), ale oznacza, że warstwa cache to twój problem do zaprojektowania.

To najsilniejszy argument za zostawieniem publicznego ruchu odczytu na REST, a do MCP kierowaniem tylko ruchu agenta. Infrastruktura cache HTTP jest zbyt cenna, by ją oddać dla powierzchni publicznej.

#Wzorzec hybrydowy

Domyślna architektura, którą wdrażam dla stron WordPress i WooCommerce z ambicjami agenta AI:

                            ┌──────────────────┐
                            │  WordPress core  │
                            │   + WooCommerce  │
                            │   (origin REST)  │
                            └────────┬─────────┘
                                     │
                    ┌────────────────┼────────────────┐
                    │                │                │
            ┌───────▼────────┐  ┌────▼─────┐  ┌──────▼──────┐
            │ Publiczne REST │  │ Webhook  │  │ Serwer MCP  │
            │ (cache na CDN) │  │ delivery │  │  (Workers)  │
            └───────┬────────┘  └────┬─────┘  └──────┬──────┘
                    │                │                │
            ┌───────▼────────┐  ┌────▼─────┐  ┌──────▼──────┐
            │ Sklep, feedy   │  │ Endpointy│  │ Agent LLM   │
            │ cenowe, public │  │ partn.   │  │ (Claude,    │
            │ API            │  │          │  │  ChatGPT,   │
            │                │  │          │  │  własny)    │
            └────────────────┘  └──────────┘  └─────────────┘

Ten sam origin WordPressa. Trzy powierzchnie, trzy profile konsumenta. Handlery serwera MCP wołają te same endpointy REST, które cache’uje powierzchnia publiczna; dostarczanie webhooków dzieli z logiką inwalidacji serwera MCP te same hooki zdarzeń WordPressa.

Granica między MCP a REST to decyzja wdrożeniowa, a nie kodowa. Warstwa danych (baza WooCommerce, endpointy REST) jest dzielona. Warstwa prezentacji (typowane narzędzia vs zasoby JSON) jest rozdzielana.

#Częste błędy

Próba, by MCP robiło robotę REST. Cache’owanie publicznych stron katalogu przez MCP jest złe. Użyj REST plus CDN.

Próba, by REST robiło robotę MCP. Dokumentowanie powierzchni akcji przyjaznej LLM w OpenAPI plus oczekiwanie, że agent “sobie poradzi”, daje kruche wyniki. Agentom lepiej idzie z discovery narzędzi MCP.

Dwie równoległe warstwy danych. Jeśli handlery MCP reimplementują logikę biznesową, zamiast wołać origin REST, każde upgrade’owanie WordPressa psuje obie powierzchnie. Trzymaj warstwę danych w WordPressie; trzymaj powierzchnie protokołu cienkie.

Zapomnienie o koszcie. Serwer MCP to dodatkowa jednostka wdrożeniowa, dodatkowa strategia auth, dodatkowa rzecz do monitorowania. Nie wdrażaj go, jeśli twoim jedynym konsumentem jest integracja ERP partnera; wdroż OpenAPI i nazwij to skończonym.

#Gdzie to siedzi w klastrze

Ten artykuł pokrywa decyzję na poziomie protokołu. Po przebieg implementacji sięgnij do budowy serwera MCP dla WooCommerce. Po strategię auth do wzorców uwierzytelniania MCP. Po projekt typowanych narzędzi do pisania typowanych narzędzi katalogu z Zod dla MCP. Po ścieżkę migracji z istniejącego API do migracji API WordPress do MCP. Filar to budowa serwera MCP.

Wycena indywidualna, bo właściwy kształt zależy od tego, których konsumentów obsługujesz i które akcje wymagają kontraktów klasy agent.