MCP-arkitektur: fullständig teknisk genomgång med diagram

MCP-arkitektur är den grundläggande uppsättningen komponenter och kommunikationsregler som gör MCP (Model Context Protocol) möjligt. MCP är en standard med öppen källkod, och MCP-arkitekturen är den underliggande infrastruktur som den körs på.

Varje MCP-arkitektur innehåller och är uppbyggd kring tre kärnkomponenter: en värd, en klient och en server. MCP:s kommunikationsramverk beskrivs ofta som uppbyggt av ett datalager och ett transportlager. Datalagret är uppsättningen regler för hur meddelanden formateras (MCP-förfrågningar skickas i JSON-RPC 2.0). Transportlagret bär dessa meddelanden och använder Streaming HTTP för externa anslutningar.

MCP-arkitektur är ett serverramverk som implementerar Model Context Protocol, en öppen standard för att ansluta AI-modeller till verktyg, resurser som databaser och prompter som utökar indatakontexten. Dessa kallas tillsammans för ”primitiver”. I slutändan gör MCP-arkitekturen det möjligt för LLM:er att upptäcka vilka verktyg som är tillgängliga och köra arbetsflöden, helt utan att det krävs regelbundna uppdateringar på klientsidan.

Diagram över MCP-arkitektur: en AI-applikation utbyter förfrågningar med en MCP-server, som tillhandahåller verktyg, resurser och prompter.

Sedan Anthropic introducerade den har MCP-arkitekturen blivit allmänt använd i AI-arbetsflöden. Det beror till stor del på att den ersätter mer underhållskrävande system, till exempel sådana som bygger på flera API-anslutningar, utan att prestandan försämras. Eftersom all tillgänglig funktionalitet ligger bakom MCP-servern krävs bara en anslutning, och uppdateringar och utökningar blir omedelbart tillgängliga för klientapplikationen.

MCP ger LLM:er ett sätt att upptäcka och anropa de verktyg, prompter och resurser som finns tillgängliga för dem, antingen på värdapplikationens lokala system eller från en extern leverantör.

När det gäller verktyg, som ger åtkomst till extern funktionalitet, innebär upptäckt att värden gör ett tools/list-anrop till MCP-servern för att ta reda på vilka verktyg som är tillgängliga. LLM:en (eller i vissa fall värden) kan sedan läsa beskrivningarna av de tillgängliga verktygen och begära dem vid behov. Prompter och resurser använder en liknande process.

Diagram över MCP-arkitekturens komponenter: en värd som innehåller en LLM, en orkestrerare och en klient ansluter till en MCP-server i två steg, först upptäckt och sedan förfrågningar, och MCP-servern exponerar verktyg, resurser och prompter.

Detta står i kontrast till skräddarsydd API-baserad arkitektur, som har varit normen inom mjukvaruutveckling, där funktionalitet utanför appen måste anropas via dedikerade anslutningar med exakt formaterade förfrågningar.

Värdapplikationen är den centrala orkestreringsplattformen och ansluter till en LLM. Välkända verktyg som Perplexity och Claude Desktop kan fungera som värdar i ett MCP-system.

I ett enkelt arbetsflöde ställer användaren en fråga via chattgränssnittet. Värdens orkestreringskomponent lägger sedan till kontext till frågan och talar om för LLM:en vilka MCP-primitiver som är tillgängliga, tillsammans med en beskrivning av deras funktioner.

Klienten är en mjukvarukomponent i AI-applikationen. MCP tillhandahåller ett standardgränssnitt som klienten använder för att kommunicera med interna och externa MCP-servrar utifrån instruktioner från värden eller LLM:en. Dess uppgift är att upprätta en anslutning, formatera JSON-RPC-meddelanden, skicka förfrågningar och ta emot svar.

Termerna ”MCP-värd” och ”MCP-klient” används ibland synonymt. Det är dock en användbar distinktion, eftersom en värd, till exempel Perplexity, kan orkestrera flera MCP-klienter samtidigt. Ett komplext AI-arbetsflöde kan kräva åtkomst till dussintals eller till och med hundratals separata MCP-servrar, och var och en använder en separat anslutning.

Diagram över en MCP-värd, till exempel Perplexity, som orkestrerar tre MCP-klienter som var och en är ansluten till sin egen MCP-server, till exempel en databas, filer eller ett externt API.

Servern exponerar alla verktyg som det AI-baserade verktyget kan använda. Ur ett arkitektoniskt perspektiv tolkar MCP-servern den inkommande förfrågan och ansluter vid behov till de begärda primitiverna.

MCP-servrar kan ge åtkomst till tre kategorier av primitiver:

Verktyg: Detta är i grunden extern mjukvarufunktionalitet. Om man tänker på ett traditionellt API-baserat tillvägagångssätt kan en webbanalysapplikation hämta data med en formaterad förfrågan till en extern server. I MCP-arkitektur är all tredjepartsfunktionalitet från en leverantör tillgänglig via en enda anslutning, och förfrågningar skapas enligt standardiserade formateringsregler.
Resurser: Resurser är datakällor som tillhandahåller skrivskyddad kontext. Databasscheman är ett bra exempel. MCP-servern exponerar de olika informationskällor som är tillgängliga för värden. Om värden ställer frågor mot databasen, till exempel med en LLM-genererad SQL-sökning, räknas detta som en verktygsförfrågan.
Prompter: Detta är återanvändbara promptmallar som hjälper LLM:er att utföra specifika uppgifter. En användare eller värd anropar en prompt i stället för ett verktyg eftersom det krävs färdiga instruktioner för att slutföra en uppgift. Förinställda uppgifter i en värdapplikation, som alternativen ”granska kod” eller ”analysera data”, lagras ofta som prompter som användaren kan välja.

Det är också värt att notera att MCP och API inte är ömsesidigt uteslutande tekniker. MCP-servern kan exponera API-anrop som blir tillgängliga som svar på en upptäcktsförfrågan. Det viktiga är att det är MCP-leverantören som ansvarar för att underhålla dessa, inte klienten.

Datalagret i MCP-arkitektur är uppsättningen regler som definierar hur förfrågningar, svar och aviseringar formateras. Standardspråket för meddelanden är JSON-RPC.

All MCP-arkitektur följer en grundläggande process med (1) initiering och upptäckt av värden, (2) svar från MCP-servern och (3) ett anrop från värden (ibland beslutat av LLM:en), där varje steg utgör ett separat JSON-meddelande.

Diagram över MCP:s datalager: en användare skickar en prompt till värdapplikationen, där LLM:en arbetar med MCP-klienten; klienten skickar en förfrågan till MCP-servern (verktyg, resurser, prompter) och får tillbaka ett resultat, och värden returnerar ett svar till användaren.

Låt oss titta på hur verktygsupptäckt fungerar med hjälp av två exempel (dessa kan även gälla resurser eller prompter):

Upptäck verktyg före LLM-genereringen: Värden initierar MCP-klienten, som skickar en tools/list-förfrågan (MCP-serverns lista över tillgängliga verktyg). LLM:en granskar detta under genereringsprocessen och avgör om ett visst verktyg, en viss resurs eller en viss prompt behövs.
Ge LLM:en möjlighet att köra en sökning: I ett agentiskt system lägger värden till ett upptäcktsalternativ, till exempel search-tools, i kontextindata, och LLM:en kan begära en sökning vid behov.

Verktyg, som i stort sett är extern applikationsfunktionalitet, väljs vanligtvis av LLM:en eller värden. Resurser och prompter efterfrågas oftast på användarens initiativ eller av värden.

Så här ser en tools/list-förfrågan till en MCP-server ut från en påhittad anteckningsapplikation:

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 det här exemplet identifierar “id”:101 förfrågan med ett ID så att klienten kan matcha svar, och fältet “params” innehåller ytterligare information om klienten, till exempel klientnamnet (notes-app-client) och funktioner.

Som svar returnerar MCP-servern verktygsdefinitioner, som innehåller namnen på de tillgängliga verktygen och tillhörande information. Listan kan till exempel innehålla ett add-task-verktyg som gör det möjligt för anteckningsapplikationen att skapa uppgifter i en ansluten applikation för uppgiftshantering eller kalender och ge varje uppgift en titel och en prioritet.

Så här kan en förfrågan 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": {}
    }
  }
}

Fältet “method” talar om för MCP-servern att det är ett verktygsanrop, “name” anger vilket verktyg som ska anropas och “arguments” tillhandahåller de nödvändiga indata.

Om datalagret är vad i anslutningen mellan en klient och en MCP-server, så är transportlagret hur. Det definierar hur meddelanden färdas: den specifika kanalen och de regler som styr hur förfrågningar och svar levereras.

MCP har två transportvägar:

Standardindata/standardutdata: Detta används när MCP-servern körs i samma lokala miljö som värdappen. Klienten skriver JSON-förfrågan till serverns standardindata. Servern läser den, utför den begärda åtgärden och skriver svaret till standardutdata.
Streamable HTTP: När MCP-servern körs externt i förhållande till värdapplikationen skickar MCP-klienten förfrågningar till servern med HTTP POST. Servern svarar antingen med ett enskilt JSON-meddelande eller med en Server-Sent Events (SSE)-ström, en beständig ”lyssnande” kanal, vilket gör att den kan returnera flera meddelanden över tid.

Multi-tenant-arkitektur för MCP är en typ av implementering som kan betjäna flera användare (tenants) samtidigt.

Här kan en tenant vara en individ, en grupp individer eller en organisation. Implementeringen kan innebära att en separat MCP-server körs för varje tenant, att åtkomst ges till en enda delad server eller att en uppsättning servrar placeras bakom en central gateway. När en gateway används dirigerar den förfrågningar till rätt slutpunkter baserat på användarens identitet eller förfrågans art.

Den bygger på samma grundprincip som standard-MCP-arkitektur, men enskilda användares förfrågningar körs i en egen arbetsyta (även om det innebär delade resurser) och autentiseras separat. Den är vanlig i företagsscenarier, och delade resurser föredras ofta eftersom det skulle bli onödigt kostsamt att köra flera MCP-servrar.

Hur ser en MCP-förfrågan från början till slut ut i praktiken? Det finns åtta huvudsteg, och vart och ett involverar en separat arkitekturkomponent.

Flödesschema över en MCP-förfrågan från början till slut i åtta steg: verktygsupptäckt, användarindata, modellbearbetning, verktygsval, förfrågan, verktygskörning, resultat och svarsgenerering.

Så här ser ett MCP-verktygsanrop ut i praktiken, med det tidigare exemplet med en anteckningsapplikation som är ansluten till en tjänst för uppgiftshantering:

Verktygsupptäckt: Anteckningsapplikationen (värden) använder sin MCP-klient för att begära serverns tillgängliga verktyg via en tools/list-förfrågan. Servern returnerar deras namn, beskrivningar och förväntade indata, inklusive dem för verktyget add-task. Detta kan ske innan du skickar en prompt.
Användarindata: Du skickar en förfrågan till den LLM-baserade anteckningsapplikationen via chattroboten i appen, till exempel: ”Skapa en uppgift i min kalender om att granska mitt nya utkast med medelhög prioritet.”
Modellbearbetning: Värden skickar din förfrågan och de relevanta verktygsdefinitionerna till LLM:en.
Verktygsval: LLM:en genererar en strukturerad verktygsförfrågan som anger verktyget och dess indata: add-task med title: Granska utkastet och priority: Medium. Värden kontrollerar om åtgärden är tillåten och skickar förfrågan vidare till MCP-klienten, som skickar ett JSON-RPC-meddelande.
Förfrågan: MCP-klienten skickar en tools/call-förfrågan till sin MCP-server.
Verktygskörning: MCP-servern anropar uppgiftshanteringsapplikationens API för att skapa en ny uppgift med angiven titel och prioritet.
Returnering av resultat: Servern skickar tillbaka resultatet till MCP-klienten, som skickar det vidare till värden. Värden lägger till det i den information som tillhandahålls LLM:en.
Svarsgenerering: LLM:en använder resultatet för att generera ett svar till användaren, till exempel ”Jag har skapat en uppgift om att granska utkastet med medelhög prioritet.”

MCP och traditionell API-arkitektur förväxlas ofta, men de är kompletterande tekniker. MCP utformades specifikt för AI-baserade applikationer. Det övervinner den tunga underhållsbördan med att implementera och hantera flera hårdkodade API-anslutningar.

Genom att ge en värdapplikation en enda anslutning per funktionsleverantör eller intern resurs hjälper MCP till att lösa problemet med uppblåst kontextindata (där alla API:er listas) eller begränsade API-baserade applikationsskript.

I stället kan MCP:er exponera API:er (eller snarare den funktionalitet som anropar API:er) som en del av sin verktygslista. När en leverantör uppdaterar sin app och det finns ett nytt API, eller om dokumentationen ändras, uppdaterar de helt enkelt MCP-servern. Inga kodändringar krävs på värdappens sida.

MCP-säkerhet har varit föremål för mycket debatt sedan protokollet introducerades. Även om det allmänt anses vara en säker teknik finns det flera säkerhetsrisker, och många av dem är mer framträdande i komplexa arkitekturimplementeringar.

MCP-arkitektur har följande potentiella svagheter:

Promptinjektion: En användare infogar en skadlig prompt i externa data som AI-modellen feltolkar som en instruktion.
Överprivilegierad åtkomst: MCP-servrar kan potentiellt exponera ett stort antal verktyg för en AI-modell, vilket kan öka risken för säkerhetsproblem (den så kallade sprängradien).
Oavsiktliga dataläckor: Dåligt konfigurerade implementeringar kan leda till att känslig information, som API-nycklar eller inloggningsuppgifter till databaser, skickas vidare till en LLM.
Manipulation av lokala system: Lokala MCP-servrar är lika sårbara för problem i det lokala systemet, som skadliga skript, som alla andra applikationer, med det ytterligare problemet att de kan få skadliga följdeffekter på agentiska AI-system.

Inget av dessa problem är oöverstigligt. Ofta är etablerade åtgärder allt som behövs för att säkerställa systemets säkerhet. Åtgärder som att ha en människa i loopen, tillämpa strikta kontroller kring känsliga data och skydda mot serverattacker är alla vanliga metoder.

MCP har visat sig vara en användbar och populär öppen standard för utvecklare. Den löser många av problemen med hårdkodade API:er i LLM-baserade applikationer och minskar avsevärt kodningsbördan för utvecklare.

Framöver kommer MCP:s underliggande värd- och serverarkitektur med största sannolikhet att förbli densamma. Framtida innovationer kommer att kretsa kring avancerade agentiska förmågor i flerstegsarbetsflöden.

Dessutom kommer det att behövas starkare säkerhetsskydd i takt med att dessa agentiska funktioner implementeras, liksom skalbar arkitektur, särskilt i transportlagret, när AI-system blir mer omfattande och komplexa.

Vad är MCP-arkitektur?

MCP-arkitekturens komponenter: värdar, klienter och servrar

Värd

Klient

Server

Vad är datalagret i MCP-arkitektur?

Vad är transportlagret i MCP-arkitektur?

Vad är multi-tenant-arkitektur för MCP?

Diagram över MCP-arkitektur: genomgång steg för steg

Hur skiljer sig MCP-arkitektur från traditionell API-arkitektur?

Är MCP-arkitektur säker?

Vad händer härnäst med MCP-arkitektur?