MCP for RESTen af os

Hvis du har været i nærheden af AI-værktøjer på det seneste, har du sikkert hørt om MCP'er. Jeg ser dog en masse spørgsmål som "er MCP ikke bare et fancy REST API?", og jeg forstår godt hvorfor. På overfladen ligner de hinanden. Begge involverer klienter og servere, der udveksler data. Men at sammenligne MCP med REST er lidt som at sammenligne en telefonsamtale med at sende en fax (ja, jeg er gammel). Begge kommunikerer information, men de fungerer på fundamentalt forskellige måder.

Lad mig gennemgå, hvad MCP faktisk er, hvorfor det findes, og hvordan det adskiller sig fra det RESTful paradigme, vi alle er blevet fortrolige med.

Hvad er MCP?

Anthropic lancerede Model Context Protocol tilbage i november 2024 som en åben standard til at forbinde LLM'er og AI-assistenter til forskellige datakilder. Vi taler APIer, databaser, indholdsrepositorier, udviklingsværktøjer - hvad du end kan komme i tanke om.

I sin kerne er protokollen bare en standardiseret måde for en klient og en server at kommunikere på, som giver sikker, realtids to-vejskommunikation mellem AI-systemer og eksterne værktøjer. Før MCP havde hvert AI-værktøj brug for tilpassede connectors til hver datakilde. Anthropic kaldte det "M×N-integrationsproblemet", og det var et vedligeholdelsesmareridt.

Jeg vil ikke gennemgå hele specifikationen her, for det er ikke det, dette indlæg handler om. Hvis du vil have detaljerne, ligger den fulde spec på modelcontextprotocol.io.

Men den grundlæggende arkitektur for en MCP-integration ser nogenlunde sådan ud:

Host (Claude, Cursor, osv.)
  └── Client ←→ MCP-protokol ←→ Server ←→ Dine data/APIer

• Hosts er applikationer som Claude Desktop, Claude Code, Cursor eller Windsurf
• Clients lever inde i hosten, og hver håndterer direkte kommunikation med én MCP-server
• MCP-protokollen er den standardiserede grænseflade, der bruges til kommunikation mellem klient og server
• MCP-servere er applikationer, der eksponerer specifikke kapabiliteter til klienter gennem protokollaget

Denne modulære tilgang gør MCP vedligeholdbar og giver en høj grad af separation of concerns, hvor hver del har et klart ansvar.

En stateful protokol

Her bliver det interessant, og her begynder MCP for alvor at afvige fra det, du er vant til med RESTful APIer.

REST er stateless af design. Hvert kald står alene. Du sender dit auth-token, dine parametre, din kontekst - alt sammen, hver eneste gang. Serveren glemmer, at du eksisterer mellem kaldene.

MCP opretholder session-state. Tidligere kald former, hvordan fremtidige kald håndteres. Når en AI fejlsøger din kode, kan den åbne filer, køre tests, se fejl og foreslå rettelser uden hukommelsestab mellem hvert trin. Sessionen husker. Det er ikke bare bekvemmelighed. Det ændrer fundamentalt, hvad der er muligt.

Med REST, hvis du vil have en AI til at "se på mine seneste commits, forstå mønstrene og foreslå, hvor fejlen kan være", orkestrerer du flere uafhængige kald og syr manuelt konteksten sammen. Med MCP flyder den kontekst naturligt, fordi sessionen opretholder den.

Er det altid bedre? Nej. Statelessness skalerer smukt. State introducerer kompleksitet, memory-overhead, hovedpine med session-håndtering. Der er reelle trade-offs her, og hvis nogen fortæller dig, at MCP er strengt overlegent, sælger de noget.

MCP består af to lag:

Data-laget - definerer JSON-RPC 2.0-protokollen for klient-server-kommunikation:

• Livscyklusstyring
• Server-features
• Client-features
• Utility-features

Transport-laget - definerer, hvordan kommunikation og dataudveksling faktisk foregår:

• Stdio-transport (til lokale integrationer)
• Streamable HTTP-transport (til fjernservere)

Livscyklusstyringsdelen er det, vi vil fokusere på i dette blogindlæg. Den håndterer kapabilitetsforhandling mellem klient og server under initialisering. Begge sider erklærer, hvad de understøtter, og det former hele sessionen. Det er en fundamental forskel fra REST, hvor hvert kald er uafhængigt.

De tre primitiver (plus lidt ekstra)

MCP-servere kan eksponere disse tre kerneprimitiver:

Tools - Eksekverbare funktioner, som AI-agenter kan kalde for at udføre handlinger. Når du beder Claude om at søge i din kodebase eller oprette en fil, er det et tool-kald.

Resources - Datakilder, der giver kontekstuel information til AI-værktøjer og -agenter. De fungerer nogenlunde som RESTful APIer og eksponerer data, AI'en kan læse.

Prompts - Skabeloner, der hjælper med at strukturere kommunikationen med en LLM. De giver testede, genbrugelige instruktioner til specifikke opgaver.

Men her bliver det interessant. Fordi MCP er stateful, kan servere også lave kald tilbage til klienten:

Sampling - Giver servere mulighed for at anmode om LLM-completions gennem klienten. Serveren kan sige "jeg har brug for, at modellen analyserer den her kode", og klienten orkestrerer den completion og returnerer resultatet til serveren.

Elicitation - Giver servere mulighed for at anmode om yderligere information fra brugere. Hvis AI'en udfylder en formular og har brug for afklaring, kan den spørge.

Logging - Giver servere mulighed for at sende log-beskeder tilbage til klienter til debugging.

Denne tovejskommunikation er det, der får MCP til at føles som en løbende samtale i stedet for isolerede request-response-cyklusser.

Sådan ser en simpel interaktion ud. Klienten opdager først, hvad serveren kan, og kalder derefter et tool:

Client → Server: initialize (protokolversion, kapabiliteter)
Server → Client: initialize response (server-kapabiliteter)

Client → Server: tools/list
Server → Client: [{name: "search_files", description: "...", inputSchema: {...}},
                  {name: "read_file", description: "...", inputSchema: {...}},
                  {name: "run_tests", description: "...", inputSchema: {...}}]

Client → Server: tools/call {name: "search_files", arguments: {query: "auth"}}
Server → Client: {content: [{type: "text", text: "Fandt 3 match..."}]}

Læg mærke til opdagelsestrinnet. Klienten behøver ikke vide, hvilke tools der findes på forhånd. Den spørger, og serveren fortæller den det. Det er fundamentalt anderledes end REST, hvor du hardcoder endpoint-stier.

MCP vs REST: De reelle forskelle

Jeg forstår, hvorfor folk sammenligner MCP med REST-API'er. De er begge integrationsteknologier, der forbinder klienter til ressourcer. Men de griber problemet an fra fuldstændig forskellige vinkler.

Feature	MCP	RESTful API
State-håndtering	Stateful sessioner med vedligeholdt kontekst	Stateless - hvert kald er uafhængigt
Forbindelsestype	Vedvarende, session-baseret	Request-response, forbindelse pr. kald
Kommunikation	Tovejs (server kan anmode fra klient)	Envejs (klient anmoder, server svarer)
Protokol	JSON-RPC 2.0	HTTP-metoder (GET, POST, PUT, DELETE)
Opdagelse	Dynamisk - klient opdager tilgængelige tools ved runtime	Statisk - endpoints defineret i dokumentation
Konteksthåndtering	Indbygget kontekstbevidsthed på tværs af kald	Kontekst skal sendes med hvert kald
Målgruppe	AI-agenter og LLM'er	Traditionelle softwareapplikationer
Integrationsmønster	Kapabilitetsforhandling, derefter løbende dialog	Dokumentér endpoints, implementér, vedligehold

Opdagelsesdelen bliver massivt undervurderet af folk, der affejer MCP-servere. REST-API'er eksponerer endpoints. Du læser dokumentation, du lærer, hvad der er tilgængeligt, du skriver kode, der kalder specifikke stier. MCP-servere eksponerer kapabiliteter, som klienter opdager dynamisk. AI'en lærer, hvad der er tilgængeligt, og finder selv ud af, hvordan det bruges. Det betyder noget, fordi det vender om på, hvem der skal forstå integrationen. Med REST skal dine udviklere kende API'en. Med MCP finder AI'en selv ud af det (med passende guardrails).

Den stateful natur er også en stor differentiator. REST-API'er er stateless af design. Hvert kald står alene og skal indeholde al nødvendig kontekst. Det fungerer fint til forudsigelige, idempotente operationer, men det kræver en masse arbejde, hvis du har brug for samtalehukommelse. Med MCP påvirker tidligere kald, hvordan fremtidige kald håndteres. Når en AI fejlsøger din kodebase, åbner den en fil, kører tests, identificerer fejl og foreslår rettelser uden at miste overblikket over, hvad den lige har gjort. Sessionen opretholder bevidstheden hele vejen igennem.

Hvornår det betyder noget, og hvornår det ikke gør

Hvis du bygger traditionelle webservices, så bliv ved med REST. Seriøst. Det er kampafprøvet, skalerer horisontalt, har årtiers tooling, og enhver udvikler på kloden ved, hvordan det virker. MCP gør intet af det forældet.

Hvis du bygger AI-native applikationer, hvor agenter skal interagere med flere services, mens de bevarer kontekst, løser MCP reelle problemer. Alternativet er at bygge tilpasset orkestrering for hver model-service-kombination, hvilket netop er det "M×N-integrationsproblem", der motiverede MCP i første omgang.

Det mest interessante tilfælde: du vil sandsynligvis have begge dele. Dine MCP-servere vil formentlig wrappe dine eksisterende REST-API'er. REST håndterer de faktiske operationer. MCP tilføjer det AI-venlige lag ovenpå. Den underliggende service ændrer sig ikke. Du tilføjer en grænseflade optimeret til en anden type forbruger.

Sikkerhedsmodellen

Autorisationslaget følger etablerede mønstre. OAuth 2.1, audience-bundne tokens, PKCE. Har du implementeret OAuth før, vil intet her overraske dig.

Det sagt, ser jeg et par antimønstre derude, der er værd at nævne.

Specifikationen forbyder eksplicit token passthrough - et antimønster, hvor din MCP-server accepterer tokens fra en klient og videresender dem til nedstrøms-API'er uden at validere, at de blev udstedt til din server.

Sig, du bygger en MCP-server, der wrapper GitHubs API. En doven implementering tager måske bare det token, klienten sender, og sender det videre til GitHub. Det bryder hurtigt sammen: din server kan ikke skelne mellem klienter, dine audit-logs viser den forkerte identitet, og hvis nogen stjæler et token, kan de bruge din server som en proxy til at exfiltrere data.

Løsningen: MCP-servere må kun acceptere tokens, der er eksplicit udstedt til dem. Din server autentificerer klienter og bruger derefter sine egne credentials med nedstrøms-API'er.

Lokale MCP-servere kører på din maskine med dine rettigheder. Når du installerer én, downloader og eksekverer du kode. Specifikationen anbefaler sandboxing og eksplicitte samtykkeflows før eksekvering, men håndhævelsen afhænger fuldstændig af din klient. Hvis din klient lader dig et-klik-installere servere fra utroværdige kilder uden at gennemgå, hvilke kommandoer de kører, er det et problem. Afhjælpningen her er ikke på protokolniveau. Det handler om at være bevidst om, hvad du installerer, og forstå, at en MCP-server har samme adgang til dit system, som du selv har.

Session-håndtering betyder mere, end man skulle tro. MCP-sessioner er stateful, hvilket betyder, at session-ID'er bliver værdifulde mål. Specifikationen nævner at binde session-ID'er til brugerspecifik information og bruge sikker tilfældig generering. Hvis du bygger en MCP-server, der håndterer flere brugere, er det eksplicit nævnt som noget, du ikke må gøre, at behandle session-ID'er som autentificering. Sessioner identificerer forbindelser. Autorisation validerer kald. At blande dem sammen åbner op for kapring.

Scope-design er der, hvor de fleste implementeringer vil begå fejl. Fristelsen er at anmode om brede tilladelser på forhånd for at undgå gentagne samtykke-prompts. Specifikationen anbefaler det modsatte: start med minimale scopes, og eskalér gradvist, når privilegerede operationer forsøges. Et stjålet token med snævert scope begrænser skadesomfanget. Et stjålet token med files:* og admin:* er et helt andet problem.

De sværere spørgsmål står ikke i specifikationen. Nogle sikkerhedsforskere har rejst bekymringer ud over autorisationslaget: tool poisoning (ondsindede servere, der eksponerer farlige kapabiliteter), lookalike tools der erstatter betroede, og den bredere angrebsflade ved AI-agenter med adgang til værktøjer. Det er reelle diskussioner, men de handler om det agentiske paradigme generelt. Så hvilke servere stoler du på? Hvordan evaluerer du en server, før du forbinder til den? Hvilke godkendelsesflows giver mening for dine brugere? Protokollen giver dig primitiverne. Tillidsmodellen er din egen at bygge.

Bundlinjen

MCP er ikke REST, og at behandle det som REST vil føre dig til at træffe dårlige beslutninger. Det er en protokol designet til AI-agenter, der har brug for stateful, tovejs kommunikation med værktøjer og datakilder.

Har alle systemer brug for dette? Absolut ikke. Hvis din integration er ligetil request-response, forbliver REST det rette valg.

Men hvis du bygger systemer, hvor AI-agenter skal opretholde kontekst på tværs af komplekse multi-trins arbejdsgange, eller hvor du vil have AI til dynamisk at opdage og bruge kapabiliteter uden hardkodede integrationer, løser MCP det rigtige problem.

Protokollen er åben, økosystemet vokser, og store spillere investerer. Om det betyder noget for dig, afhænger fuldstændig af, hvad du bygger.

Vil du dykke ned i det, er den fulde spec meget læsevenlig og velbeskrevet. Start der frem for at stole på andenhånds-forklaringer. Denne inklusive.