MCP vs REST: når hva vinner for integrasjon av AI-agenter

#MCP vs REST: når hva vinner for integrasjon av AI-agenter

Å behandle MCP og REST som alternativer er feil ramme. De ligger på forskjellige lag: REST er transport pluss konvensjoner, MCP er en typet protokoll laget for en LLM som konsument. Den egentlige beslutningen er hvilken overflate hver konsument snakker med, og hvordan de to overflatene deler en backend. Denne artikkelen gir rammeverket jeg bruker når jeg avgrenser AI-integrasjoner for WordPress- og WooCommerce-prosjekter.

Artikkelen hører til pilarsiden utvikling av MCP-servere.

#Kort oppsummert

• MCP og REST utfyller hverandre, de er ikke alternativer.
• REST vinner for deterministiske klienter med hardkodede handlinger og OpenAPI-dokumentasjon.
• MCP vinner for LLM-agenter som trenger oppdagelse av verktøy under kjøring og typede konvolutter for muterende handlinger.
• Standard i produksjon er REST som system of record og MCP som agentoverflate foran.
• Samme backend, to overflater, én sannhetskilde.

#Hva er MCP og hva er et REST API

REST. En arkitekturstil fra Roy Fieldings doktoravhandling fra 2000 (kilden til avhandlingen), vanligvis uttrykt over HTTP med verb og ressurs-URL-er. WordPress eksponerer et REST API under /wp-json/wp/v2/ (håndboken for WordPress REST API); WooCommerce utvider det under /wp-json/wc/v3/. Dokumentasjonen er som regel OpenAPI (OpenAPI-spesifikasjonen), og SDK-er genereres fra skjemaet ved bygging.

MCP. En protokoll basert på JSON-RPC 2.0 som Anthropic kunngjorde 25. november 2024 (kunngjøringen fra Anthropic) for å koble LLM-verter (Claude Desktop, IDE-er, egne agentmiljøer) til data og verktøy. Tre primitiver: tools (funksjoner som kan kalles), resources (dokumenter som kan leses), prompts (maler levert av serveren). Oppdagelse skjer under kjøring via tools/list; agenten lærer de tilgjengelige funksjonene på nytt i hver økt.

På avstand ser formene like ut. Under belastning skiller de lag raskt.

#Beslutningsmatrise for MCP eller REST API

Seks faktorer jeg vurderer før jeg velger overflate for en gitt handling:

Matrisen forteller meg hvilken protokoll som er å foretrekke for én handling, ikke for hele API-et. De fleste prosjekter ender opp delt.

#Når et REST API passer bedre enn MCP

En nettbutikk som henter en kategoriside. Hardkodet mot /wp-json/wp/v2/categories?slug=widgets. Formen er kjent, cache-headerne gjør jobben, og CDN-et kan cache per URL.

En partners ERP-integrasjon som synkroniserer lager daglig. Partnerteamet leser OpenAPI, genererer en typet SDK og setter opp en cron-jobb klokken 03:00 UTC. De vil ha stabile URL-er, forutsigbare svarformer og HTTP-statuskoder. MCP ville lagt til kompleksitet uten verdi.

Offentlig, anonym lesetrafikk. En SEO-crawler som treffer produktsider, en prissammenligningstjeneste som henter produktfeeder. REST pluss rate limiting håndterer dette med den mest modne infrastrukturen som finnes.

Levering av webhooks. WooCommerce sender woocommerce_order_status_completed til et endepunkt hos partneren. Endepunktet er en REST-mottaker. MCP er feil form, fordi agenten ikke er med i sløyfen; mottakeren er et deterministisk system.

#Når MCP passer bedre enn REST

En LLM-agent som handler på brukerens frie intensjon. “Finn en vanntett jakke under 200 euro som kan sendes til Oslo.” Agenten vet ikke på forhånd hvilken kombinasjon av filtre den skal bruke; den må undersøke de tilgjengelige verktøyene, lese beskrivelsene og bestemme seg. REST gir den 47 query-parametere fordelt på tre endepunkter og ingen pekepinn om hvilke som skal brukes.

Muterende handlinger der idempotens betyr noe. Å opprette en ordre fra en LLM er det tydeligste eksemplet. MCP-verktøyet order.intent med et typet inndataskjema og en idempotensnøkkel er en strammere kontrakt enn et fritt POST /wp-json/wc/v3/orders-kall. Nye forsøk er trygge per design, ikke per konvensjon.

En verktøyoverflate som endres ofte. Et nytt søkefilter eller en ny produkttype betyr at du publiserer et nytt MCP-verktøy med en describe-blokk; agenten plukker det opp ved neste tools/list uten kodeendringer på agentsiden. Med REST er hver endring en koordinert SDK-utgivelse.

Agentarbeidsflyter i flere steg. “Sjekk om SKU AC-101 er på lager; hvis ikke, foreslå tre alternativer; hvis den finnes, foreslå en ordre.” Hvert steg er ett verktøykall, og agenten setter dem sammen. Med REST må agenten hardkode arbeidsflyten i prompten.

#MCP og REST i en WooCommerce-butikk

For et typisk WooCommerce-prosjekt trekker jeg grensen slik:

Verktøyhandlerne i MCP-serveren kaller de samme /wp-json/wc/v3/-endepunktene som REST-konsumentene bruker. Én sannhetskilde for datalaget, to overflater for to typer konsumenter.

#Autentisering og OAuth-scopes i MCP og REST

Autentisering i REST er godt utprøvd: bearer-tokens, OAuth 2.x, basic auth under utvikling. Konvensjonen er at “den som har tokenet kan gjøre alt dokumentasjonen sier.” Finjustering av scopes skjer per endepunkt på applikasjonsnivå.

MCP lener seg på de samme valgene i transportlaget, men SDK-en oppmuntrer til å merke scopes per verktøy. Ett OAuth-token kan bære orders:read uten orders:write, og MCP-serveren håndhever det ved hvert verktøykall. OpenAPI-mønstre støtter den samme ideen via securityDefinitions og sikkerhet per operasjon, men i praksis dokumenterer de fleste REST API-er ett globalt scope og lar applikasjonen ordne finere granularitet selv.

For agentintegrasjoner spesielt er kartleggingen av scopes per verktøy i MCP en reell ergonomisk gevinst, som også passer med GDPR-kravet om dataminimering. Brukeren gir agenten orders:read; agenten kan bokstavelig talt ikke kalle order.cancel, fordi MCP-serveren avviser kallet med forbidden før handleren kjører. Under panseret er autentiseringen den samme som i REST, men kontrakten er lettere å lese for både brukeren og agenten.

#Hvordan skiller caching av MCP-svar seg fra HTTP-cache i REST?

REST har flere tiår med HTTP-cache-infrastruktur: Cache-Control-headere, ETag-revalidering, Vary-regler, caching på CDN-kanten, i nettleseren og i mellomliggende proxyer. Et svar på GET /wp-json/wc/v3/products?stock_status=instock med Cache-Control: public, max-age=60 caches på kanten uten ekstra innsats.

MCP har ingenting av dette. Verktøysvar sendes som JSON-RPC-payloads inne i POST-forespørsler. HTTP-cache-headere gjelder ikke. Caching må skje på applikasjonsnivå, inne i verktøyhandleren, mot en eksplisitt nøkkel utledet fra inndataene. Det fungerer fint når handlerne i MCP-serveren selv cacher REST-kallet oppstrøms (slik jeg gjør i produksjon), men det betyr at cachelaget er ditt ansvar å designe.

Dette er det sterkeste argumentet for å beholde offentlig lesetrafikk på REST og bare sende agenttrafikk gjennom MCP. HTTP-cache-infrastrukturen er for verdifull til å gi opp for den offentlige overflaten.

#Hvordan kjøre MCP og REST på én WordPress-backend?

Standardarkitekturen jeg leverer for WordPress- og WooCommerce-nettsteder med ambisjoner om AI-agenter:

                            ┌──────────────────┐
                            │  WordPress core  │
                            │   + WooCommerce  │
                            │   (REST origin)  │
                            └────────┬─────────┘
                                     │
                    ┌────────────────┼────────────────┐
                    │                │                │
            ┌───────▼────────┐  ┌────▼─────┐  ┌──────▼──────┐
            │  Public REST   │  │ Webhook  │  │ MCP server  │
            │ (cache at CDN) │  │ delivery │  │ (Workers)   │
            └───────┬────────┘  └────┬─────┘  └──────┬──────┘
                    │                │                │
            ┌───────▼────────┐  ┌────▼─────┐  ┌──────▼──────┐
            │ Storefront,    │  │ Partner  │  │  LLM agent  │
            │ price feeds,   │  │ endpoints│  │  (Claude,   │
            │ public APIs    │  │          │  │  ChatGPT,   │
            │                │  │          │  │  custom)    │
            └────────────────┘  └──────────┘  └─────────────┘

Samme WordPress-origin. Tre overflater, tre konsumentprofiler. Handlerne i MCP-serveren kaller de samme REST-endepunktene som den offentlige overflaten cacher; webhook-leveringen deler de samme WordPress-hookene som invalideringslogikken i MCP-serveren lytter på.

Grensen mellom MCP og REST er en driftsbeslutning, ikke en kodebeslutning. Datalaget (WooCommerce-databasen, REST-endepunktene) deles. Presentasjonslaget (typede verktøy mot JSON-ressurser) deles opp.

#Vanlige arkitekturfeil med MCP og REST

Å la MCP gjøre jobben til REST. Å cache offentlige katalogsider gjennom MCP er feil. Bruk REST pluss CDN.

Å la REST gjøre jobben til MCP. Å dokumentere en LLM-vennlig handlingsoverflate i OpenAPI og forvente at agenten “finner ut av det” gir skjøre resultater. Agenter klarer seg bedre med verktøyoppdagelsen i MCP.

To parallelle datalag. Hvis MCP-handlerne implementerer forretningslogikken på nytt i stedet for å kalle REST-origin, knekker hver WordPress-oppgradering begge overflatene. Hold datalaget i WordPress og protokolloverflatene tynne.

Å glemme kostnaden. En MCP-server er en ekstra driftsenhet, en ekstra autentiseringsstrategi og en ting til å overvåke. Ikke lever en hvis den eneste konsumenten din er en ERP-integrasjon hos en partner; lever OpenAPI og si deg ferdig.

#Relaterte temaer

Denne artikkelen dekker beslutningen på protokollnivå. Gjennomgangen av implementeringen finner du i bygge en MCP-server for WooCommerce. Autentiseringsstrategien står i autentiseringsmønstre for MCP. Designet av typede verktøy beskrives i typede katalogverktøy med Zod for MCP. Migreringsveien fra et eksisterende API finner du i migrere et WordPress-API til MCP. Tjenestesiden er utvikling av MCP-servere.

Prisen er individuell, fordi riktig form avhenger av hvilke konsumenter du betjener og hvilke handlinger som krever kontrakter på agentnivå.