Vad en MCP-server är och vad den inte är

Att koppla en språkmodell till ett verksamhetssystem är ingen uppgift för modellen. Det är en uppgift för integrationen. Model Context Protocol (MCP) finns för att standardisera just det lagret. Den här texten behandlar MCP som ett protokoll, inte som en produkt: vad det fastställer, vad det medvetet lämnar öppet och vilken ruta det upptar i en företagsarkitektur. Varje teknisk uppgift nedan vilar på den officiella specifikationen. Revisioner av specifikationen bär en identifierare i formatet ÅÅÅÅ-MM-DD och räknas bara upp när en bakåtinkompatibel ändring införs. Den här texten utgår från revision 2025-11-25. Revisionen 2026-07-28, som kommer den 28 juli 2026, gör protokollet tillståndslöst, tar bort initialize-handskakningen och sessionsidentifieraren, flyttar Tasks ut ur kärnan till ett eget tillägg och markerar Roots, Sampling och Logging som deprecated med ett tolv månader långt fönster fram till borttagning. Uppgifterna om session och primitiver nedan ändras i den revisionen.

Före protokollet: en brygga per par

Före MCP innebar det att koppla en AI-applikation till en datakälla att man skrev egen kod för just det paret av applikation och källa. Det ursprungliga tillkännagivandet beskriver det rakt ut: varje ny datakälla kräver en egen implementation, vilket gör verkligt sammankopplade system svåra att skala. Branschen förkortar det som N×M — N applikationer, M system, N×M handskrivna bryggor däremellan. Den benämningen är ingen officiell terminologi, men läget den beskriver står så i den officiella texten. Bytet MCP föreslår är enkelt: ett enda protokoll i stället för spridda punktintegrationer, så att varje sida implementerar protokollet en gång.

Anthropic tillkännagav MCP den 25 november 2024 och släppte det som öppen källkod; bakom det står David Soria Parra och Justin Spahr-Summers. Den första utgåvan kom i tre delar: specifikationen med SDK:er, stöd för lokala MCP-servrar i Claude Desktop-apparna och ett repository med öppen källkod som samlar färdiga servrar för system som Google Drive, Slack, GitHub, Postgres och Puppeteer.

Den 9 december 2025 överlämnade Anthropic MCP till Agentic AI Foundation (AAIF), en öronmärkt fond under Linux Foundation. Den grundades tillsammans av Anthropic, Block och OpenAI, med stöd från Google, Microsoft, AWS, Cloudflare och Bloomberg. MCP är ett av grundprojekten vid sidan av goose och AGENTS.md. Maintainer-strukturen fördes över oförändrad: styrelsen hanterar budget, medlemskap och godkännande av nya projekt, medan de enskilda projekten behåller full autonomi över den tekniska inriktningen. Att i dag beskriva MCP som helt enkelt Anthropics protokoll säger därför bara halva sanningen. Mer träffande: initierat av Anthropic och släppt som öppen källkod, och sedan december 2025 styrt under AAIF inom Linux Foundation. Den officiella dokumentationen nämner Claude, ChatGPT, Visual Studio Code, Cursor och MCPJam bland de klienter som har stöd för det.

Arkitektur: host, klient, server

MCP följer en klient-server-arkitektur och definierar tre skilda roller. MCP-hosten är den AI-applikation som samordnar en eller flera MCP-klienter — till exempel Claude Code eller VS Code. En MCP-klient är den komponent som håller förbindelsen till exakt en server och hämtar kontext å hostens vägnar. En MCP-server är ett program som förser MCP-klienter med kontext. Detaljen som spelar roll i drift: hosten skapar ett eget klientobjekt per server, och varje klient håller en dedikerad förbindelse till sin egen server. Servrarna ser inte varandra.

Termen MCP-server säger ingenting om var koden körs; den kan ligga lokalt eller på distans. I praktiken betjänar lokala servrar över stdio vanligtvis en enda klient, medan servrar på distans över Streamable HTTP betjänar många. Protokollet delas i två lager: ett datalager (meddelanden enligt JSON-RPC 2.0, livscykel, primitiver, notifieringar) och ett transportlager (uppkoppling, message framing, auktorisering). MCP är ett tillståndsbärande protokoll. En session öppnas med initialize, där capabilities förhandlas, och klient och server måste enas om en enda protokollversion.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": { "name": "example-host", "version": "1.0.0" }
  }
}

Specifikationen definierar två standardtransporter: stdio och Streamable HTTP. Klienter bör stödja stdio när det är möjligt, och egna transporter är tillåtna så länge de behåller JSON-RPC-meddelandeformatet och kraven på livscykeln. Streamable HTTP tillhandahåller en enda sökväg som MCP-slutpunkt, med stöd för både POST och GET; servern kan valfritt strömma svar över SSE. Den äldre HTTP+SSE-transporten från revision 2024-11-05 har ersatts av Streamable HTTP och är deprecated. Över HTTP måste klienter skicka en MCP-Protocol-Version-header på alla anrop efter initialize, och värdet som skickas bör vara den version som förhandlades under initialize; en server som inte får någon header utgår från 2025-03-26. En server kan utfärda ett MCP-Session-Id vid initieringen och förvänta sig det i efterföljande anrop.

Specifikationen säger uttryckligen att MCP delvis hämtar inspiration från Language Server Protocol. Liknelsen håller: LSP standardiserade skarven mellan en editor och ett språk, MCP standardiserar skarven mellan en AI-applikation och ett externt system.

Vad en server faktiskt exponerar

Servrar exponerar sina förmågor genom tre kärnprimitiver. Det som skiljer dem åt är inte vad de gör, utan vem som styr dem:

• Tools — funktioner som modellen kan anropa för att utföra något: skriva till en databas, anropa ett externt API, ändra filer. Styrs av modellen. Metoder: tools/list, tools/call.
• Resources — passiva, skrivskyddade datakällor som levererar kontext: filinnehåll, databasscheman, API-svar. Styrs av applikationen. Metoder: resources/list, resources/templates/list, resources/read, resources/subscribe.
• Prompts — återanvändbara, parametriserade interaktionsmallar. Styrs av användaren; specifikationen utgår från att de anropas uttryckligen. Metoder: prompts/list, prompts/get.

Indata till tools deklareras med JSON Schema. Det låter den som skriver servern luta sig mot schemat i stället för mot modellen: ett inkommande anrop valideras mot schemat innan det når någon affärslogik.

{
  "name": "get_order_status",
  "title": "Get order status",
  "description": "Returns the current status of a given order number.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderNumber": { "type": "string", "pattern": "^[A-Z]{2}-[0-9]{6}$" },
      "verbose": { "type": "boolean", "default": false }
    },
    "required": ["orderNumber"]
  }
}

På resurssidan bär varje resurs en unik URI och deklarerar en MIME-typ. Utöver fasta URI:er kan servrar publicera parametriserade Resource Templates — till exempel en mall som tar emot en stad och ett datum. Flödet går inte bara åt ett håll: även klienter exponerar primitiver för servrar. Sampling låter en server begära en completion från hostens modell (sampling/createMessage). Elicitation låter en server be användaren om ytterligare indata eller en bekräftelse (elicitation/create). Roots låter en server fråga efter den filsystemsgräns den har tilldelats. Logging fyller ut bilden. En Tasks-primitiv för långkörande operationer är markerad som experimentell i den aktuella revisionen och bör därför inte behandlas som ett fast antagande i en införandeplan. Servrar vars capabilities ändras kan skicka notifieringar som notifications/tools/list_changed — men bara om de annonserade listChanged under initialize.

Var auktoriseringen faktiskt sker

Det här är den punkt som oftast blandas ihop vid läsningen. I MCP är auktoriseringen definierad på transportnivå och den är valfri. HTTP-baserade transporter bör följa auktoriseringsspecifikationen; STDIO-transporter bör låta bli och i stället hämta autentiseringsuppgifter från miljön. Den som letar efter ett OAuth-flöde i en lokal stdio-server letar i ett annat lager än det där auktoriseringen bor.

Över HTTP är rollerna entydiga. En skyddad MCP-server uppträder som OAuth 2.1-resursserver. En MCP-klient uppträder som OAuth 2.1-klient. Auktoriseringsservern är en egen part — den kan köras bredvid resursservern eller helt fristående. Just den uppdelningen är grunden för påståendet att en MCP-server är en auktoriseringsgräns: servern utfärdar inga token, den validerar dem och begränsar åtkomsten därefter. De standarder avsnittet anger överensstämmelse med är utkastet till OAuth 2.1, RFC 8414, RFC 7591, RFC 9728 och utkastet OAuth Client ID Metadata Documents. Separat kräver samma dokument RFC 8707 för resource-parametern.

De krav som direkt översätts till beslut om driftsättning:

• MCP-servrar måste implementera RFC 9728 (Protected Resource Metadata), och klienter måste använda den för att hitta auktoriseringsservern.
• Klienter måste implementera PKCE och använda challenge-metoden S256 när det är tekniskt möjligt; går stödet för PKCE inte att bekräfta ur fältet code_challenge_methods_supported i auktoriseringsserverns metadata, måste klienten avstå från att fortsätta.
• Servrar måste validera att åtkomsttoken har utfärdats uttryckligen för dem som avsedd audience, och måste avvisa token som inte namnger dem.
• Vid anrop till ett uppströms-API uppträder MCP-servern som en egen OAuth-klient och får inte skicka vidare det token den tagit emot från MCP-klienten. Token passthrough är ett uttryckligen otillåtet mönster.
• Token får inte förekomma i URI:ns query-sträng; varje HTTP-anrop bär med sig en Authorization: Bearer-header, även inom samma logiska session.
• Sessionsidentifierare är ingen autentiseringsmekanism: servrar får inte använda sessioner för autentisering.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="orders:read orders:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Write permission required"

Statuskoderna är också fastlagda: 401 när auktorisering krävs eller när ett token inte är giltigt, 403 vid otillräckligt scope, 400 när begäran har ett format som inte är giltigt. Vid 403 anger servern de scopes som behövs i WWW-Authenticate-headern, och klienten kan köra ett step-up-flöde för auktorisering. Specifikationen rekommenderar uttryckligen att hålla scopes minimala; samlingsnamn som *, all eller full-access listar den bland vanliga antimönster i implementationer.

Vad MCP inte är

MCP är ingen modell. Det är en öppen standard för att koppla AI-applikationer till externa system. Det finns inga vikter i den, ingen inferensmotor, ingen bestämmelse om hur modellen ska bete sig. Vilken modell du kör ligger utanför protokollets område.

MCP är inget agentramverk. Den officiella anmärkningen om omfattningen är tydlig: MCP befattar sig enbart med protokollet för utbyte av kontext och föreskriver inte hur AI-applikationer använder LLM:er eller förvaltar den kontext de får. Planering, loopstyrning, minne, omförsökslogik — allt det ligger i din applikation, inte i protokollet.

MCP är inget RAG-system. Dokumentationen om Resources säger det rakt ut: applikationerna kommer åt informationen och avgör själva hur den ska användas — genom att välja ut relevanta delar, genom att söka med embeddings eller genom att skicka allt till modellen. Indexering, chunkning och vektorsökning är inte definierade någonstans i protokollet. Det är beslut som hör till applikationen.

MCP ersätter inte en API-gateway. En MCP-server är inget transparent genomsläpp framför uppströms-API:er. Det åtkomsttoken som används uppströms är ett eget token, utfärdat av auktoriseringsservern där, och servern får inte skicka vidare det den tog emot. Servern bär sin egen identitet och sin egen auktoriseringsgräns. Rate limiting, kvoter, protokollöversättning och edge-routing förblir gatewayens uppgifter.

Den officiella liknelsen är träffande: tänk på MCP som en USB-C-port för AI-applikationer. Porten bestämmer inte vad som sitter i andra änden av kabeln, eller vad den anslutna enheten gör med anslutningen.

Var servern hör hemma vid drift on-premise

Specifikationens säkerhetsavsnitt räknar upp fyra principer: användarens samtycke och kontroll, dataskydd, säkerhet kring tools och kontroller för LLM-sampling. Samma avsnitt lägger till ett förbehåll: MCP kan inte upprätthålla de här principerna på protokollnivå, det förväntas av dem som implementerar. Just det förbehållet förklarar varför arkitekturbesluten väger så tungt här. Det mesta av kontrollen ligger inte i protokollet, utan i vem som driver servern och var den körs.

Säkerhetskraven i specifikationen gör drift on-premise till det naturliga valet. Servrar som körs lokalt bör binda enbart till 127.0.0.1 i stället för till alla gränssnitt. Servrar som använder Streamable HTTP måste validera Origin-headern och svara 403 när värdet inte är giltigt — det är skyddet mot DNS-rebinding. Autentisering rekommenderas för alla anslutningar. En lokal server är en process som kör kod på värddatorn: specifikationen rekommenderar att klienten kör den processen i en sandlåda med minimala standardrättigheter, och att en lokalt körande server begränsar åtkomsten till stdio eller en avgränsad IPC-kanal som en unix domain socket. MCP-klienter som hämtar URL:er för OAuth-discovery bör blockera anrop till privata och reserverade IP-intervall, och serversidiga installationer av MCP-klienter bör överväga en egress-proxy — den del som täcker server-side request forgery, alltså fallet där en server riktar en klient mot interna nätadresser. Proxyservrar med statiskt klient-ID måste hämta in användarens samtycke per dynamiskt registrerad klient — regeln som stänger fallet med en confused deputy. Isoleringen av token-audience säger redan samma sak med ett annat ordval: servern är gränsen.

Sammantaget ser bilden ut så här. MCP-servern är den punkt där verksamhetens data och verksamhetens åtgärder passerar. Även när modellen körs någon annanstans avgör servern vilka tools som finns, vilka resources som går att läsa och vilken identitet som bär vilket anrop uppströms. Sitter den servern i ditt eget nät och under din kontroll stannar alla de besluten på en plats du kan granska. Specifikationen noterar också att beskrivningar och annoteringar av tools bör betraktas som icke betrodda så länge de inte kommer från en betrodd server — och den som definierar vad betrodd betyder är den som drar gränsen.

Kortaste vägen att placera in MCP: det mesta av koden du förr skrev för att koppla en modell till ett verksamhetssystem handlade aldrig om modellen. Den handlade om discovery, scheman, identitet, auktorisering, svarsformat i undantagsfall och livscykel. MCP standardiserar just den delen och håller sig utanför resten. Därför är designfrågorna för en MCP-server inga protokollfrågor alls: vilka åtgärder som blir tools, vilka data som blir läsbara som resources och vilken identitet som når vilket uppströmssystem med vilket scope. Protokollet klargör var de frågorna ställs. Att besvara dem är fortfarande arkitekturarbete.

Källor

• Model Context Protocol — specification, 2025-11-25 revision
• MCP specification — Authorization section (OAuth 2.1 roles, RFC 9728, error codes)
• MCP specification — Versioning and feature lifecycle
• MCP Blog — The 2026-07-28 MCP Specification Release Candidate
• MCP Blog — MCP joins the Agentic AI Foundation (9 December 2025)
• Anthropic — Introducing the Model Context Protocol (25 November 2024)