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 skjemaer med atferdsannotasjoner 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. Siden revisjonen 2026-07-28 har protokollen ingen økter: hver forespørsel bærer protokollversjonen og klientens funksjoner, og klienten henter listen på nytt når den bufrede kopien utløper eller et endringsvarsel kommer.

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. Når en ordre endrer status, sender en WooCommerce-webhook hendelsen til et endepunkt hos partneren. Endepunktet er en HTTP-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 query-parametere spredt over flere 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. Et MCP-verktøy order.intent med et typet inndataskjema, en obligatorisk parameter idempotency_key og destructiveHint: false forteller agenten og klienten hva kallet gjør før det kjører. Protokollen garanterer ikke idempotens: det er handleren som må avvise en ny ordre med samme nøkkel. Forskjellen fra et fritt POST /wp-json/wc/v3/orders-kall ligger i en kontrakt modellen kan lese.

En verktøyoverflate som endres ofte. Et nytt søkefilter eller en ny produkttype betyr at du publiserer et nytt MCP-verktøy med description og inputSchema. Serveren sender notifications/tools/list_changed til klienter som har åpnet subscriptions/listen, og agenten plukker opp verktøyet 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

I WordPress har REST API-et tre dokumenterte veier (autentisering i REST API-et). Cookie-autentisering er for kode som kjører på selve nettstedet og krever en nonce for handlingen wp_rest, sendt i headeren X-WP-Nonce; uten nonce kjører forespørselen som en anonym bruker, selv om du er innlogget. Application Passwords har vært en del av core siden WordPress 5.6 og fungerer med HTTP Basic, bare over HTTPS. OAuth 1.0a og JSON Web Tokens kommer via plugins. Finjustering av tilganger skjer per rute, i brukerens capabilities og i permission_callback på hvert endepunkt.

Autorisasjon i MCP er valgfri og gjelder HTTP-transportene; med stdio hentes legitimasjonen fra miljøet. Når den brukes, er MCP-serveren en OAuth 2.1 resource server, må publisere Protected Resource Metadata (RFC 9728) og godtar bare tokens utstedt for seg selv: klienten oppgir serveren i parameteren resource (RFC 8707), og serveren avviser tokens med et annet publikum. Serveren kan heller ikke godta eller sende videre andre tokens, så den autentiserer seg mot WordPress med egen legitimasjon, for eksempel et Application Password for en bruker med en begrenset rolle.

Scopes fungerer som i ethvert OAuth-API, med to regler som er nyttige for agenter. Serveren kan returnere bare verktøyene tokenets scopes tillater i tools/list. Og når et kall trenger mer, svarer den HTTP 403 med error="insufficient_scope" og de nødvendige scopes i headeren WWW-Authenticate, slik at klienten kan be om ny autorisasjon med et utvidet sett. Brukeren gir agenten orders:read; agenten ser ikke engang order.cancel, og hvis den prøver å kalle verktøyet, får den 403 før handleren kjører. OpenAPI beskriver det samme med securitySchemes og security per operasjon (OpenAPI-spesifikasjonen), men i praksis dokumenterer mange REST API-er ett globalt scope og overlater finere granularitet til applikasjonen.

For agentintegrasjoner er denne kartleggingen av scopes per verktøy en reell ergonomisk gevinst, som også passer med GDPR-kravet om dataminimering. Under panseret er mekanismen den samme OAuth som REST allerede kjenner, men kontrakten blir lettere å lese for både brukeren og agenten.

#Hvordan caching av MCP-svar skiller 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.

I MCP kom en del av dette med revisjonen 2026-07-28 (caching i MCP). Resultatene fra tools/list, prompts/list, resources/list, resources/templates/list og resources/read må ha ttlMs, som fungerer som max-age, og cacheScope, med verdiene public og private, tilsvarende dem i Cache-Control. Resultater fra tools/call, som utgjør mesteparten av trafikken fra en agent, er ikke på den listen. De sendes som JSON-RPC-payloads inne i POST-forespørsler, og HTTP-cache-headere gjelder ikke. Caching av kallene 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.

#MCP-verktøyannotasjoner mot idempotente HTTP-verb

I REST ligger sikkerheten til en operasjon i selve verbet. RFC 9110 definerer GET, HEAD, OPTIONS og TRACE som trygge metoder, og PUT, DELETE og de trygge metodene som idempotente: flere like forespørsler har samme tiltenkte effekt som én. POST er ikke idempotent. En proxy, en crawler eller et bibliotek for nye forsøk kan avgjøre hva som trygt kan gjentas bare ut fra metoden, uten å lese kroppen.

MCP sender alt som tools/call inne i en POST, så verbet sier ingenting. Informasjonen flyttes til verktøydefinisjonen. Skjemaet i spesifikasjonen definerer fire boolske annotasjoner i ToolAnnotations:

Standardverdiene er pessimistiske: et verktøy uten annotasjoner behandles som et som kan skrive, ødelegge og ikke er idempotent. Spesifikasjonen sier at alle disse egenskapene er hint som ikke garanterer en tro beskrivelse av atferden, og at en klient ikke skal ta beslutninger ut fra annotasjoner fra servere den ikke stoler på. Siden om tools anbefaler i tillegg et menneske i sløyfen som kan avvise et kall, og bekreftelse før sensitive operasjoner.

I en WooCommerce-butikk ser det slik ut: product.search får readOnlyHint: true, order.cancel får destructiveHint: true, og idempotensen til order.intent sikres i handleren med en nøkkel serveren sjekker, ikke av annotasjonen. Annotasjonen hjelper klienten å avgjøre når den skal be om bekreftelse. Den erstatter ikke pliktene spesifikasjonen gir serveren: validere alle inndata, håndheve tilgangskontroll, begrense antall kall og rense utdata.

#Hvordan MCP rapporterer feil sammenlignet med HTTP-statuskoder

Et REST API melder feil med statuskoden: 400 for en feilformet forespørsel, 401 uten gyldig autentisering, 403 uten tilgang, 404 for en rute som ikke finnes. Spesifikasjonen for tools skiller mellom to nivåer. Protokollfeil (ukjent verktøy, en forespørsel som ikke oppfyller skjemaet for tools/call, serverfeil) kommer som vanlige JSON-RPC-feil, for eksempel med koden -32602. Kjørefeil (feil i API-et oppstrøms, dato i feil format, brudd på en forretningsregel) kommer i et resultat med isError: true og en tekstmelding.

Spesifikasjonen anbefaler at klienter sender kjørefeil videre til modellen, fordi de inneholder informasjon som lar den rette argumentene og prøve igjen. I en MCP-server som pakker inn WordPress REST API, bør en 400-valideringsfeil fra WordPress bli et resultat med isError: true som navngir den manglende parameteren, ikke en protokollfeil modellen ikke kan rette.

#Oppdagelse i WordPress REST API mot tools/list i MCP

WordPress REST beskriver også seg selv, bare på en annen måte. Sidene på nettstedet sender en Link-header med rel="https://api.w.org/" som peker til roten av API-et, og roten under /wp-json/ returnerer et objekt med tilgjengelige namespaces (wp/v2, wc/v3 og de fra plugins), rutene og en authentication-nøkkel med støttede metoder (oppdagelse i REST API-et). En OPTIONS-forespørsel til en rute returnerer skjemaet for ruten, skrevet i et delsett av JSON Schema draft 4 (skjema i REST API-et).

Forskjellen ligger i hvem som leser. WordPress-indeksen er laget for en utvikler eller en SDK-generator: den lister alle registrerte ruter, og hver av dem godtar globale parametere som _fields (delvise svar, med nestede egenskaper siden WordPress 5.3), _embed (lenkede ressurser i samme svar) og _envelope (globale parametere). Samlinger pagineres med per_page opptil 100 og returnerer totalene i headerne X-WP-Total og X-WP-TotalPages (paginering). Alt dette passer en programmert klient, men en modell som får hele indeksen, bruker kontekst på å velge mellom ruter den aldri kommer til å bruke.

tools/list i MCP returnerer bare det serveren har valgt å eksponere, hvert verktøy med description, inputSchema (JSON Schema 2020-12 som standard) og eventuelt outputSchema. Spesifikasjonen tillater at listen varierer etter tokenets scopes og ber om en deterministisk rekkefølge, slik at klienten kan cache den og modellen får nytte av prompt-cachen. En MCP-server for WordPress er i praksis et kuratert utvalg av /wp-json/-indeksen, med beskrivelser skrevet for en modell og ikke for en utvikler.

WordPress 6.9 la til en mellombrikke, Abilities API. En plugin registrerer en ability med input_schema, output_schema, en valgfri permission_callback og show_in_rest i metadataene. Det er en innebygd måte å beskrive funksjonsenheter med skjema på, og det er nettopp kontrakten en MCP-server trenger for hvert verktøy.

#Hva som endret seg i MCP 2026-07-28 for HTTP-proxyer og lastbalanserere

Revisjonene fra 2025 hadde et initialize-håndtrykk, økter identifisert med headeren Mcp-Session-Id og en SSE-strøm åpnet med GET. Med flere servere bak en lastbalanserer tvinger en økt per tilkobling deg til å sende samme klient til samme server eller dele tilstand mellom serverne, et problem tilstandsløs REST ikke har. Revisjonen 2026-07-28 fjernet alle tre. Hver forespørsel bærer protokollversjonen og klientens funksjoner i _meta. Den som trenger tilstand mellom kall, for eksempel en handlekurv, returnerer en eksplisitt identifikator fra ett verktøy og tar den imot som argument i de neste kallene.

Transporten Streamable HTTP speiler nå også metadata i headere. MCP-Protocol-Version og Mcp-Method er obligatoriske i hver POST, Mcp-Name også i tools/call, resources/read og prompts/get, og et verktøy kan merke parametere med x-mcp-header for å eksponere dem som Mcp-Param-{navn}. En WAF eller en gateway kan dermed rute eller begrense antall kall per verktøy uten å lese JSON-kroppen. Hvis en header ikke stemmer med kroppen, svarer serveren 400 med feilen HeaderMismatch (-32020). Spesifikasjonen fraråder å merke sensitive parametere på denne måten, fordi headerne er synlige for mellomledd.

For den som allerede drifter et REST API bak et CDN, kommer de to overflatene nærmere hverandre i drift: de samme reglene for ruting og rate limiting per header gjelder for begge. HTTP-cache gjelder fortsatt ikke for tools/call, fordi hvert kall er en POST.

#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å.