MCP-arkitektur: Komplet teknisk gennemgang med diagrammer

MCP-arkitektur er det grundlæggende sæt af komponenter og kommunikationsregler, der gør MCP (Model Context Protocol) mulig. MCP er en open source-standard, og MCP-arkitektur er den underliggende infrastruktur, som den kører på.

Enhver MCP-arkitektur indeholder og er bygget op omkring tre kernekomponenter: en vært, en klient og en server. MCP’s kommunikationsramme beskrives ofte som bestående af et datalag og et transportlag. Datalaget er det sæt regler, der bestemmer, hvordan beskeder formateres (MCP-anmodninger sendes i JSON-RPC 2.0). Transportlaget overfører disse beskeder og bruger Streaming HTTP til eksterne forbindelser.

MCP-arkitektur er en serverramme, der implementerer Model Context Protocol, en åben standard for at forbinde AI-modeller med værktøjer, ressourcer som databaser og prompts, der udvider inputkonteksten. Disse kaldes samlet »primitiver«. I sidste ende gør MCP-arkitektur det muligt for LLM’er at finde ud af, hvilke værktøjer der er tilgængelige, og udføre arbejdsprocesser, uden at det kræver løbende opdateringer på klientsiden.

Diagram over MCP-arkitektur: en AI-applikation udveksler anmodninger med en MCP-server, som stiller værktøjer, ressourcer og prompts til rådighed.

Siden Anthropic introducerede MCP-arkitekturen, er den blevet udbredt i AI-arbejdsprocesser. Det skyldes i høj grad, at den erstatter mere vedligeholdelsestunge systemer, såsom dem, der er bygget op omkring flere API-forbindelser, uden at gå på kompromis med ydeevnen. Fordi al tilgængelig funktionalitet ligger bag MCP-serveren, kræves der kun én forbindelse, og opdateringer og tilføjelser er straks tilgængelige for klientapplikationen.

MCP giver LLM’er mulighed for at finde og kalde de værktøjer, prompts og ressourcer, der er tilgængelige for dem, enten på værtsapplikationens lokale system eller fra en ekstern udbyder.

For værktøjer, som giver adgang til ekstern funktionalitet, indebærer opdagelse, at værten foretager et tools/list-kald til MCP-serveren for at finde ud af, hvilke værktøjer der er tilgængelige. LLM’en (eller i nogle tilfælde værten) kan derefter læse beskrivelserne af de tilgængelige værktøjer og anmode om dem efter behov. Prompts og ressourcer bruger en lignende proces.

Diagram over MCP-arkitekturens komponenter: en vært, der indeholder en LLM, en orkestrator og en klient, forbinder til en MCP-server i to trin, først opdagelse og derefter anmodninger, og MCP-serveren stiller værktøjer, ressourcer og prompts til rådighed.

Det står i modsætning til skræddersyet API-baseret arkitektur, som har været normen inden for softwareudvikling, hvor funktionalitet uden for appen skulle kaldes via dedikerede forbindelser med præcist formaterede anmodninger.

Værtsapplikationen er den centrale orkestreringsplatform og forbinder til en LLM. Velkendte værktøjer som Perplexity og Claude Desktop kan fungere som værter i et MCP-system.

I en simpel arbejdsproces stiller brugeren et spørgsmål via chatgrænsefladen. Værtens orkestratorkomponent tilføjer derefter kontekst til spørgsmålet og fortæller LLM’en, hvilke MCP-primitiver der er tilgængelige, sammen med en beskrivelse af deres funktioner.

Klienten er en softwarekomponent i AI-applikationen. MCP giver en standardgrænseflade, som klienten kan bruge til at kommunikere med interne og eksterne MCP-servere ud fra værtens eller LLM’ens instruktioner. Dens opgave er at oprette en forbindelse, formatere JSON-RPC-beskeder, sende anmodninger og modtage svar.

Begreberne »MCP-vært« og »MCP-klient« bruges nogle gange i flæng. Det er dog en nyttig skelnen, fordi en vært, såsom Perplexity, kan orkestrere flere MCP-klienter på én gang. En kompleks AI-arbejdsproces kan kræve adgang til snesevis eller endda hundredvis af separate MCP-servere, og hver af dem bruger en separat forbindelse.

Diagram over en MCP-vært, såsom Perplexity, der orkestrerer tre MCP-klienter, som hver er forbundet til sin egen MCP-server, f.eks. en database, filer eller en ekstern API.

Serveren stiller alle de værktøjer til rådighed, som det AI-baserede værktøj kan bruge. Set ud fra et arkitekturmæssigt perspektiv fortolker MCP-serveren den indgående anmodning og forbinder om nødvendigt til de ønskede primitiver.

MCP-servere kan give adgang til tre kategorier af primitiver:

Værktøjer: Dette er i bund og grund ekstern softwarefunktionalitet. Hvis man ser på en traditionel API-baseret tilgang, kan en webanalyseapplikation hente data ved hjælp af en formateret anmodning til en ekstern server. I MCP-arkitektur er al tredjepartsfunktionalitet fra en udbyder tilgængelig via én enkelt forbindelse, og anmodninger oprettes efter standardiserede formateringsregler.
Ressourcer: Ressourcer er datakilder, der giver skrivebeskyttet kontekst. Databaseskemaer er et godt eksempel. MCP-serveren stiller de forskellige informationskilder til rådighed, som er tilgængelige for værten. Hvis værten forespørger databasen, f.eks. med en LLM-genereret SQL-søgning, betragtes det som en værktøjsanmodning.
Prompts: Dette er genanvendelige promptskabeloner, der hjælper LLM’er med at udføre bestemte opgaver. En bruger eller vært kalder en prompt i stedet for et værktøj, fordi der kræves færdige instruktioner for at udføre en opgave. Ofte gemmes forudindstillede opgaver i en værtsapplikation, såsom muligheden for at »gennemgå kode« eller »analysere data«, som prompts, som brugeren kan vælge.

Det er også værd at bemærke, at MCP og API ikke er gensidigt udelukkende teknologier. MCP-serveren kan stille API-kald til rådighed, som er tilgængelige som svar på en opdagelsesanmodning. Det afgørende er, at det er MCP-udbyderen, der skal vedligeholde dem, ikke klienten.

Datalaget i MCP-arkitektur er det sæt regler, der definerer, hvordan anmodninger, svar og notifikationer formateres. Standardsproget for beskeder er JSON-RPC.

Al MCP-arkitektur følger en grundlæggende proces med (1) initialisering og opdagelse foretaget af værten, (2) svar fra MCP-serveren og (3) et kald fra værten (nogle gange besluttet af LLM’en), hvor hver fase udgør en separat JSON-besked.

Diagram over MCP-datalaget: en bruger sender en prompt til værtsapplikationen, hvor LLM’en arbejder sammen med MCP-klienten; klienten sender en anmodning til MCP-serveren (værktøjer, ressourcer, prompts) og modtager et resultat, og værten returnerer et svar til brugeren.

Lad os se på, hvordan værktøjsopdagelse fungerer, gennem to eksempler (de kan også gælde for ressourcer eller prompts):

Find værktøjer før LLM-generering: Værten starter MCP-klienten, som sender en tools/list-anmodning (MCP-serverens liste over tilgængelige værktøjer). LLM’en gennemgår denne under genereringsprocessen og afgør, om der er brug for et bestemt værktøj, en ressource eller en prompt.
Giv LLM’en mulighed for at køre en søgning: I et agentisk system tilføjer værten en opdagelsesmulighed, såsom search-tools, til kontekstinputtet, og LLM’en kan anmode om en søgning efter behov.

Værktøjer, som overvejende er eksterne applikationsfunktioner, vælges typisk af LLM’en eller værten. Ressourcer og prompts anmodes som regel om på brugerens foranledning eller af værten.

Sådan ser en tools/list-anmodning til en MCP-server ud fra en fiktiv noteapplikation:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

I dette eksempel identificerer “id”:101 anmodningen med et id, så klienten kan matche svarene, og feltet “params” indeholder yderligere oplysninger om klienten, såsom klientnavnet (notes-app-client) og dens funktioner.

Som svar returnerer MCP-serveren værktøjsdefinitioner, som indeholder navnene på de tilgængelige værktøjer og de tilhørende detaljer. Listen kan f.eks. indeholde et add-task-værktøj, som giver noteapplikationen mulighed for at oprette opgaver i en tilsluttet opgavestyrings- eller kalenderapplikation og tildele hver opgave en titel og en prioritet.

Sådan kan en anmodning se ud:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Feltet “method” fortæller MCP-serveren, at det er et værktøjskald, “name” angiver, hvilket værktøj der skal kaldes, og “arguments” leverer de nødvendige input.

Hvis datalaget er hvad i forbindelsen mellem en klient og en MCP-server, er transportlaget hvordan. Det definerer, hvordan beskeder bevæger sig: den specifikke kanal og de regler, der styrer, hvordan anmodninger og svar leveres.

MCP har to transportveje:

Standardinput/-output: Dette bruges, når MCP-serveren kører i det samme lokale miljø som værtsappen. Klienten skriver JSON-anmodningen til serverens standardinput. Serveren læser den, udfører den ønskede handling og skriver svaret til standardoutput.
Streamable HTTP: Når MCP-serveren kører eksternt i forhold til værtsapplikationen, sender MCP-klienten anmodninger til serveren ved hjælp af HTTP POST. Serveren svarer enten med en enkelt JSON-besked eller med en Server-Sent Events (SSE)-stream, en vedvarende »lyttende« kanal, så den kan returnere flere beskeder over tid.

MCP-multi-tenant-arkitektur er en type implementering, der kan betjene flere brugere (lejere) samtidig.

Her kan en lejer være en enkeltperson, en gruppe personer eller en organisation. Implementeringen kan indebære, at der køres en separat MCP-server for hver lejer, at der gives adgang til en enkelt delt server, eller at et sæt servere placeres bag en central gateway. Når der bruges en gateway, dirigerer den anmodninger til de rigtige endpoints baseret på brugerens identitet eller anmodningens art.

Den fungerer efter samme grundprincip som standard-MCP-arkitektur, men de enkelte brugeranmodninger kører i hvert deres eget arbejdsområde (selv hvis det indebærer delte ressourcer) og autentificeres separat. Den er udbredt i virksomhedsscenarier, og delte ressourcer foretrækkes ofte, fordi det ville være unødvendigt dyrt at køre flere MCP-servere.

Hvordan ser en MCP-anmodning fra start til slut ud i praksis? Der er otte centrale faser, som hver involverer en særskilt arkitekturkomponent.

Rutediagram over en MCP-anmodning fra start til slut i otte trin: værktøjsopdagelse, brugerinput, modelbehandling, værktøjsvalg, anmodning, værktøjsudførelse, resultat og svargenerering.

Sådan ser et MCP-værktøjskald ud i praksis med det tidligere eksempel med en noteapplikation, der er forbundet til en opgavestyringstjeneste:

Værktøjsopdagelse: Noteapplikationen (værten) bruger sin MCP-klient til at anmode om serverens tilgængelige værktøjer via en tools/list-anmodning. Serveren returnerer deres navne, beskrivelser og forventede input, herunder dem for værktøjet add-task. Det kan ske, før du sender en prompt.
Brugerinput: Du sender en anmodning til den LLM-baserede noteapplikation via den indbyggede chatbot, f.eks.: »Opret en opgave i min kalender om at gennemgå mit nye udkast med middel prioritet.«
Modelbehandling: Værten sender din anmodning og de relevante værktøjsdefinitioner til LLM’en.
Værktøjsvalg: LLM’en genererer en struktureret værktøjsanmodning, der angiver værktøjet og dets input: add-task med title: Review the draft og priority: Medium. Værten kontrollerer, om handlingen er tilladt, og sender anmodningen videre til MCP-klienten, som sender en JSON-RPC-besked.
Anmodning: MCP-klienten sender en tools/call-anmodning til sin MCP-server.
Værktøjsudførelse: MCP-serveren kalder opgavestyringsapplikationens API for at oprette en ny opgave med den angivne titel og prioritet.
Returnering af resultat: Serveren sender resultatet tilbage til MCP-klienten, som videregiver det til værten. Værten føjer det til de oplysninger, der leveres til LLM’en.
Generering af svar: LLM’en bruger resultatet til at generere et svar til brugeren, f.eks. »Jeg har oprettet en opgave om at gennemgå udkastet med middel prioritet.«

MCP og traditionel API-arkitektur forveksles ofte, men de er komplementære teknologier. MCP er specifikt udviklet til AI-baserede applikationer. Den overvinder den tunge vedligeholdelsesbyrde ved at implementere og administrere flere hardcodede API-forbindelser.

Ved at give en værtsapplikation én enkelt forbindelse pr. funktionalitetsudbyder eller intern ressource hjælper MCP med at løse problemet med oppustet kontekstinput (hvor alle API’er listes) eller begrænsede API-baserede applikationsscripts.

I stedet kan MCP’er stille API’er (eller rettere den funktionalitet, der kalder API’er) til rådighed som en del af deres værktøjsliste. Når en udbyder opdaterer sin app, og der kommer en ny API, eller hvis dokumentationen ændres, opdaterer de blot MCP-serveren. Der kræves ingen kodeændringer på værtsappens side.

MCP-sikkerhed har været genstand for megen debat, siden protokollen blev introduceret. Selvom den generelt betragtes som en sikker teknologi, er der flere sikkerhedsrisici, hvoraf mange er mere udtalte i komplekse arkitekturimplementeringer.

MCP-arkitektur har følgende potentielle svagheder:

Promptinjektion: En bruger indsætter en ondsindet prompt i eksterne data, som AI-modellen fejlagtigt tolker som en instruktion.
Overprivilegeret adgang: MCP-servere kan potentielt stille et stort antal værktøjer til rådighed for en AI-model, hvilket kan øge risikoen for sikkerhedsproblemer (den såkaldte blast radius).
Utilsigtede datalæk: Dårligt konfigurerede implementeringer kan føre til, at følsomme oplysninger, såsom API-nøgler eller loginoplysninger til databaser, videregives til en LLM.
Manipulation af lokale systemer: Lokale MCP-servere er lige så sårbare over for problemer i det lokale system, såsom ondsindede scripts, som alle andre applikationer, med det ekstra problem, at de kan have skadelige følgevirkninger for agentiske AI-systemer.

Ingen af disse problemer er uoverstigelige. Ofte er etablerede foranstaltninger alt, hvad der skal til for at sikre systemets sikkerhed. Foranstaltninger som at have et menneske med i processen, håndhæve strenge kontroller omkring følsomme data og beskytte mod angreb på servere er alle almindelig praksis.

MCP har vist sig at være en nyttig og populær åben standard for udviklere. Den løser mange af problemerne med hardcodede API’er i LLM-baserede applikationer og reducerer udviklernes kodningsbyrde betydeligt.

Fremadrettet vil den underliggende værts- og serverarkitektur i MCP næsten med sikkerhed forblive den samme. Fremtidige innovationer vil fokusere på avancerede agentiske evner på tværs af arbejdsprocesser i flere trin.

Derudover bliver der brug for stærkere sikkerhedsforanstaltninger, efterhånden som disse agentiske funktioner implementeres, og for skalerbar arkitektur, især i transportlaget, efterhånden som AI-systemer bliver mere omfattende og komplekse.

Hvad er MCP-arkitektur?

MCP-arkitekturens komponenter: Værter, klienter og servere

Vært

Klient

Server

Hvad er datalaget i MCP-arkitektur?

Hvad er transportlaget i MCP-arkitektur?

Hvad er MCP-multi-tenant-arkitektur?

Diagram over MCP-arkitektur: Gennemgang trin for trin

Hvordan adskiller MCP-arkitektur sig fra traditionel API-arkitektur?

Er MCP-arkitektur sikker?

Hvad er det næste for MCP-arkitektur?