MCP-arkitektur: Fullstendig teknisk gjennomgang med diagrammer

MCP-arkitektur er det grunnleggende settet med komponenter og kommunikasjonsregler som gjør MCP (Model Context Protocol) mulig. MCP er en åpen kildekode-standard, og MCP-arkitektur er den underliggende infrastrukturen den kjører på.

Enhver MCP-arkitektur inneholder og er bygget rundt tre kjernekomponenter: en vert, en klient og en server. MCPs kommunikasjonsrammeverk beskrives ofte som bestående av et datalag og et transportlag. Datalaget er settet med regler for hvordan meldinger formateres (MCP-forespørsler sendes i JSON-RPC 2.0). Transportlaget frakter disse meldingene og bruker Streaming HTTP for eksterne tilkoblinger.

MCP-arkitektur er et serverrammeverk som implementerer Model Context Protocol, en åpen standard for å koble AI-modeller til verktøy, ressurser som databaser og prompter som utvider inndatakonteksten. Disse kalles samlet «primitiver». Til syvende og sist gjør MCP-arkitektur det mulig for LLM-er å oppdage hvilke verktøy som er tilgjengelige, og utføre arbeidsflyter, uten at det kreves jevnlige oppdateringer på klientsiden.

Diagram over MCP-arkitektur: en AI-applikasjon utveksler forespørsler med en MCP-server, som tilbyr verktøy, ressurser og prompter.

Siden MCP ble introdusert av Anthropic, har MCP-arkitektur blitt mye brukt i AI-arbeidsflyter. Dette skyldes i stor grad at den erstatter mer vedlikeholdskrevende systemer, for eksempel slike som er bygget rundt flere API-tilkoblinger, uten at det går på bekostning av ytelsen. Fordi all tilgjengelig funksjonalitet ligger bak MCP-serveren, trengs bare én tilkobling, og oppdateringer og tillegg blir umiddelbart tilgjengelige for klientapplikasjonen.

MCP gir LLM-er en måte å oppdage og kalle verktøyene, promptene og ressursene som er tilgjengelige for dem, enten på vertsapplikasjonens lokale system eller fra en ekstern leverandør.

Når det gjelder verktøy, som gir tilgang til ekstern funksjonalitet, innebærer oppdagelse at verten sender et tools/list-kall til MCP-serveren for å finne ut hvilke verktøy som er tilgjengelige. LLM-en (eller i noen tilfeller verten) kan deretter lese beskrivelsene av de tilgjengelige verktøyene og be om dem ved behov. Prompter og ressurser bruker en lignende prosess.

Diagram over komponentene i MCP-arkitektur: en vert som inneholder en LLM, en orkestrator og en klient, kobler seg til en MCP-server i to trinn, først oppdagelse og deretter forespørsler, og MCP-serveren eksponerer verktøy, ressurser og prompter.

Dette står i kontrast til skreddersydd API-basert arkitektur, som har vært normen innen programvareutvikling, der funksjonalitet utenfor appen måtte kalles via dedikerte tilkoblinger med nøyaktig formaterte forespørsler.

Vertsapplikasjonen er den sentrale orkestreringsplattformen og kobler seg til en LLM. Kjente verktøy som Perplexity og Claude Desktop kan fungere som verter i et MCP-system.

I en enkel arbeidsflyt stiller brukeren et spørsmål via chattegrensesnittet. Vertens orkestreringskomponent legger deretter til kontekst i spørsmålet og forteller LLM-en hvilke MCP-primitiver som er tilgjengelige, sammen med en beskrivelse av hva de kan gjøre.

Klienten er en programvarekomponent i AI-applikasjonen. MCP gir et standardgrensesnitt som klienten bruker til å kommunisere med interne og eksterne MCP-servere basert på instruksjonene fra verten eller LLM-en. Oppgaven dens er å opprette en tilkobling, formatere JSON-RPC-meldinger, sende forespørsler og motta svar.

Begrepene «MCP-vert» og «MCP-klient» brukes noen ganger om hverandre. Det er likevel et nyttig skille, fordi en vert, for eksempel Perplexity, kan orkestrere flere MCP-klienter samtidig. En kompleks AI-arbeidsflyt kan kreve tilgang til dusinvis eller til og med hundrevis av separate MCP-servere, og hver av dem bruker en egen tilkobling.

Diagram over en MCP-vert, for eksempel Perplexity, som orkestrerer tre MCP-klienter, hver koblet til sin egen MCP-server, for eksempel en database, filer eller et eksternt API.

Serveren eksponerer alle verktøyene som det AI-baserte verktøyet kan bruke. Fra et arkitekturperspektiv tolker MCP-serveren den innkommende forespørselen og kobler seg ved behov til de forespurte primitivene.

MCP-servere kan gi tilgang til tre kategorier primitiver:

Verktøy: Dette er i bunn og grunn ekstern programvarefunksjonalitet. I en tradisjonell API-basert tilnærming kan en applikasjon for nettanalyse hente data ved hjelp av en formatert forespørsel til en ekstern server. I MCP-arkitektur er all tredjepartsfunksjonalitet fra en leverandør tilgjengelig via én enkelt tilkobling, og forespørsler opprettes etter standardiserte formateringsregler.
Ressurser: Ressurser er datakilder som gir skrivebeskyttet kontekst. Databaseskjemaer er et godt eksempel. MCP-serveren eksponerer de ulike informasjonskildene som er tilgjengelige for verten. Hvis verten sender spørringer mot databasen, for eksempel med et LLM-generert SQL-søk, regnes dette som en verktøyforespørsel.
Prompter: Dette er gjenbrukbare promptmaler som hjelper LLM-er med å utføre bestemte oppgaver. En bruker eller vert kaller en prompt i stedet for et verktøy fordi oppgaven krever ferdige instruksjoner for å fullføres. Forhåndsdefinerte oppgaver i en vertsapplikasjon, som valget «gjennomgå kode» eller «analyser data», lagres ofte som prompter som brukeren kan velge.

Det er også verdt å merke seg at MCP og API ikke er gjensidig utelukkende teknologier. MCP-serveren kan eksponere API-kall som er tilgjengelige som svar på en oppdagelsesforespørsel. Poenget er at det er MCP-leverandøren som har ansvaret for å vedlikeholde disse, ikke klienten.

Datalaget i MCP-arkitektur er settet med regler som definerer hvordan forespørsler, svar og varsler formateres. Standardspråket for meldinger er JSON-RPC.

All MCP-arkitektur følger en grunnleggende prosess med (1) initialisering og oppdagelse fra vertens side, (2) svar fra MCP-serveren og (3) et kall fra verten (noen ganger bestemt av LLM-en), der hvert trinn utgjør en separat JSON-melding.

Diagram over MCP-datalaget: en bruker sender en prompt til vertsapplikasjonen, der LLM-en samarbeider med MCP-klienten; klienten sender en forespørsel til MCP-serveren (verktøy, ressurser, prompter) og mottar et resultat, og verten returnerer et svar til brukeren.

La oss se på hvordan verktøyoppdagelse fungerer gjennom to eksempler (disse kan også gjelde ressurser eller prompter):

Oppdag verktøy før LLM-generering: Verten starter MCP-klienten, som sender en tools/list-forespørsel (MCP-serverens liste over tilgjengelige verktøy). LLM-en gjennomgår denne under genereringsprosessen og avgjør om et bestemt verktøy, en ressurs eller en prompt trengs.
Gi LLM-en mulighet til å kjøre et søk: I et agentisk system legger verten til et oppdagelsesalternativ, for eksempel search-tools, i kontekstinndataene, og LLM-en kan be om et søk ved behov.

Verktøy, som stort sett er funksjonalitet i eksterne applikasjoner, velges vanligvis av LLM-en eller verten. Ressurser og prompter forespørres vanligvis etter ønske fra brukeren eller av verten.

Slik ser en tools/list-forespørsel til en MCP-server ut fra en tenkt notatapplikasjon:

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 eksemplet identifiserer “id”:101 forespørselen med en ID slik at klienten kan matche svarene, og feltet “params” inneholder tilleggsinformasjon om klienten, for eksempel klientnavnet (notes-app-client) og funksjonene.

Som svar returnerer MCP-serveren verktøydefinisjoner, som inneholder navnene på tilgjengelige verktøy og tilhørende detaljer. Listen kan for eksempel inneholde et add-task-verktøy som lar notatapplikasjonen opprette oppgaver i en tilkoblet applikasjon for oppgavebehandling eller kalender, og gi hver oppgave en tittel og en prioritet.

Slik kan en forespørsel se ut:

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” forteller MCP-serveren at det er et verktøykall, “name” angir hvilket verktøy som skal kalles, og “arguments” leverer de nødvendige inndataene.

Hvis datalaget er hva i forbindelsen mellom en klient og en MCP-server, er transportlaget hvordan. Det definerer måten meldinger reiser på: den spesifikke kanalen og reglene for hvordan forespørsler og svar leveres.

MCP har to transportveier:

Standard inndata/utdata: Dette brukes når MCP-serveren kjører i det samme lokale miljøet som vertsappen. Klienten skriver JSON-forespørselen til serverens standard inndata. Serveren leser den, utfører den forespurte operasjonen og skriver svaret til standard utdata.
Streamable HTTP: Når MCP-serveren kjører eksternt i forhold til vertsapplikasjonen, sender MCP-klienten forespørsler til serveren med HTTP POST. Serveren svarer enten med én enkelt JSON-melding eller med en Server-Sent Events (SSE)-strøm, en vedvarende «lyttekanal», som gjør det mulig å returnere flere meldinger over tid.

MCP-arkitektur med flere leietakere (multi-tenant) er en type implementering som kan betjene flere brukere (leietakere) samtidig.

Her kan en leietaker være en enkeltperson, en gruppe personer eller en organisasjon. Implementeringen kan innebære å kjøre en egen MCP-server for hver leietaker, gi tilgang til én enkelt delt server eller plassere et sett med servere bak en sentral gateway. Når en gateway brukes, ruter den forespørsler til riktige endepunkter basert på brukerens identitet eller forespørselens art.

Den fungerer etter samme grunnprinsipp som standard MCP-arkitektur, men hver enkelt brukerforespørsel kjører i sitt eget arbeidsområde (selv om det innebærer delte ressurser) og autentiseres separat. Dette er vanlig i bedriftsscenarioer, og delte ressurser foretrekkes ofte fordi det ville vært unødvendig kostbart å kjøre flere MCP-servere.

Hvordan ser en ende-til-ende-forespørsel i MCP ut i praksis? Det finnes åtte kjernetrinn, og hvert av dem involverer en egen arkitekturkomponent.

Flytdiagram over en ende-til-ende-forespørsel i MCP i åtte trinn: verktøyoppdagelse, brukerinndata, modellbehandling, verktøyvalg, forespørsel, verktøykjøring, resultat og generering av svar.

Slik ser et MCP-verktøykall ut i praksis, med det forrige eksemplet med en notatapplikasjon som er koblet til en tjeneste for oppgavebehandling:

Verktøyoppdagelse: Notatapplikasjonen (verten) bruker MCP-klienten sin til å be om serverens tilgjengelige verktøy gjennom en tools/list-forespørsel. Serveren returnerer navn, beskrivelser og forventede inndata, inkludert dem for verktøyet add-task. Dette kan skje før du sender inn en prompt.
Brukerinndata: Du sender en forespørsel til den LLM-baserte notatapplikasjonen via chatboten i appen, for eksempel: «Opprett en oppgave i kalenderen min om å gå gjennom det nye utkastet mitt, med middels prioritet.»
Modellbehandling: Verten sender forespørselen din og de relevante verktøydefinisjonene til LLM-en.
Verktøyvalg: LLM-en genererer en strukturert verktøyforespørsel som angir verktøyet og inndataene: add-task med title: Gå gjennom utkastet og priority: Middels. Verten kontrollerer om handlingen er tillatt, og sender forespørselen videre til MCP-klienten, som sender en JSON-RPC-melding.
Forespørsel: MCP-klienten sender en tools/call-forespørsel til MCP-serveren sin.
Verktøykjøring: MCP-serveren kaller API-et til oppgavebehandlingsapplikasjonen for å opprette en ny oppgave med angitt tittel og prioritet.
Retur av resultat: Serveren sender resultatet tilbake til MCP-klienten, som sender det videre til verten. Verten legger det til i informasjonen som gis til LLM-en.
Generering av svar: LLM-en bruker resultatet til å generere et svar til brukeren, for eksempel «Jeg har opprettet en oppgave om å gå gjennom utkastet, med middels prioritet.»

MCP og tradisjonell API-arkitektur forveksles ofte, men de er komplementære teknologier. MCP ble utviklet spesielt for AI-baserte applikasjoner. Den løser problemet med den store vedlikeholdsbyrden ved å implementere og administrere flere hardkodede API-tilkoblinger.

Ved å gi en vertsapplikasjon én enkelt tilkobling per funksjonalitetsleverandør eller intern ressurs bidrar MCP til å løse problemet med oppblåste kontekstinndata (der alle API-er listes opp) eller begrensede API-baserte applikasjonsskript.

I stedet kan MCP-er eksponere API-er (eller rettere sagt funksjonaliteten som kaller API-er) som en del av verktøylisten sin. Hver gang en leverandør oppdaterer appen sin og det kommer et nytt API, eller hvis dokumentasjonen endres, oppdaterer leverandøren ganske enkelt MCP-serveren. Det kreves ingen kodeendringer på vertsappens side.

Sikkerheten i MCP har vært gjenstand for mye debatt siden introduksjonen. Selv om MCP generelt regnes som en trygg teknologi, finnes det flere sikkerhetsrisikoer, og mange av dem er mer fremtredende i komplekse arkitekturimplementeringer.

MCP-arkitektur har følgende potensielle svakheter:

Promptinjeksjon: En bruker legger inn en ondsinnet prompt i eksterne data som AI-modellen feiltolker som en instruksjon.
Overprivilegert tilgang: MCP-servere kan potensielt eksponere et stort antall verktøy for en AI-modell, noe som kan øke potensialet for sikkerhetsproblemer (skadeomfanget).
Utilsiktede datalekkasjer: Dårlig konfigurerte implementeringer kan føre til at sensitiv informasjon, som API-nøkler eller påloggingsinformasjon til databaser, sendes videre til en LLM.
Manipulering av lokale systemer: Lokale MCP-servere er like sårbare for problemer i lokale systemer, som ondsinnede skript, som alle andre applikasjoner, med det tilleggsproblemet at de kan få skadelige følgevirkninger for agentiske AI-systemer.

Ingen av disse problemene er uoverstigelige. Ofte er etablerte tiltak alt som trengs for å sikre systemets sikkerhet. Tiltak som å ha et menneske i loopen, håndheve strenge kontroller rundt sensitive data og beskytte mot serverangrep er alle vanlig praksis.

MCP har vist seg å være en nyttig og populær åpen standard for utviklere. Den løser mange av problemene med hardkodede API-er i LLM-baserte applikasjoner og reduserer kodebyrden for utviklere betydelig.

Fremover vil den underliggende verts- og serverarkitekturen i MCP nesten helt sikkert forbli den samme. Fremtidige innovasjoner vil dreie seg om avanserte agentiske egenskaper på tvers av arbeidsflyter med flere trinn.

I tillegg vil det være behov for sterkere sikkerhetstiltak etter hvert som disse agentiske funksjonene implementeres, og for skalerbar arkitektur, særlig i transportlaget, etter hvert som AI-systemer blir mer omfattende og komplekse.

Hva er MCP-arkitektur?

Komponenter i MCP-arkitektur: verter, klienter og servere

Vert

Klient

Server

Hva er datalaget i MCP-arkitektur?

Hva er transportlaget i MCP-arkitektur?

Hva er MCP-arkitektur med flere leietakere?

Diagram over MCP-arkitektur: Gjennomgang trinn for trinn

Hvordan skiller MCP-arkitektur seg fra tradisjonell API-arkitektur?

Er MCP-arkitektur sikker?

Hva er det neste for MCP-arkitektur?