Vad är MCP – och hur använder jag det tillsammans med AI och externa datakällor?

MCP – Model Context Protocol – är en öppen standard för hur en AI-applikation hämtar information från och utför åtgärder i andra system. I stället för att varje AI-verktyg behöver sin egen specialbyggda koppling till er databas, ert CRM och ert dokumentarkiv, beskriver MCP ett gemensamt sätt att presentera de förmågorna. Ett verktyg som talar MCP kan använda vilken MCP-server som helst.

Praktiskt betyder det att ni bygger kopplingen till ert eget system en gång, och sedan kan använda den från Claude, från Codex, från en egen agent — utan att skriva om något. Protokollet togs fram av Anthropic och släpptes öppet; det utvecklas i dag i det öppna, med en publik specifikation och en formell process för ändringar.

En språkmodell kan bara resonera om det den har i sin kontext. Utan koppling till era system är den hänvisad till vad någon klistrar in i chatten — och till sin träningsdata, som per definition är gammal och inte vet någonting om er verksamhet.

Det uppenbara svaret är att bygga integrationer. Problemet är hur snabbt det växer: med fem AI-verktyg och åtta interna system pratar man i värsta fall om fyrtio separata kopplingar, var och en med sin egen autentisering, sitt eget felhanteringsbeteende och sin egen förvaltning. Varje nytt verktyg multiplicerar arbetet i stället för att lägga till det.

MCP bryter den multiplikationen. Systemen exponeras en gång som MCP-servrar, verktygen talar ett protokoll, och de två sidorna kan bytas ut oberoende av varandra. Det är samma idé som gjorde att skrivardrivrutiner slutade vara ett problem: standardisera gränssnittet, inte parterna.

Tre roller räcker för att förstå hela protokollet.

Två transporter

En MCP-server når värden på ett av två sätt. stdio betyder att servern startas som en lokal process och pratar över standard in- och utflöde — enklast, och rätt val för allt som ska köra på utvecklarens egen maskin. Streamable HTTP betyder att servern körs som en vanlig webbtjänst som flera användare kan dela, vilket är vad ni vill ha för något som hela organisationen ska nå.

En server kan erbjuda tre sorters saker, och skillnaden mellan dem är värd att hålla isär — den avgör hur mycket kontroll ni behåller.

• Verktyg (tools) är åtgärder modellen kan utföra: slå upp en kund, skapa ett ärende, köra en fråga. Det är den kraftfulla kategorin — och den som behöver ert skydd, eftersom modellen väljer när den anropas.
• Resurser (resources) är data modellen kan läsa: ett dokument, en tabell, ett filträd. Läsande till sin natur, och därmed betydligt mindre riskabelt att öppna upp.
• Prompter (prompts) är färdiga instruktionsmallar som servern erbjuder — ett sätt att paketera hur något bör göras, inte bara vad som går att göra.

Varje verktyg beskriver sig själv: namn, beskrivning i klartext och ett JSON-schema för sina argument. Det är den beskrivningen modellen läser när den avgör om verktyget är relevant. En slarvigt formulerad beskrivning ger en modell som anropar fel verktyg vid fel tillfälle — verktygstexterna är en del av lösningen, inte dokumentation vid sidan om.

MCP är en levande standard. Den senaste revisionen, 2026-07-28, är den största omskrivningen hittills och ersätter revisionen 2025-11-25. Läser ni äldre guider är det här ni behöver kalibrera om.

• Protokollet är nu stateless. Handskakningen initialize / notifications/initialized är borttagen, och med den sessioner på protokollnivå och Mcp-Session-Id. Varje anrop bär i stället sin egen protokollversion och sina klientförmågor. Följden är praktisk: en MCP-server skalar nu bakom vanlig HTTP-infrastruktur, med lastbalanserare och flera instanser, utan klistrig sessionsrouting.
• server/discover är ny och obligatorisk för servrar. Klienten kan fråga rakt ut vilka protokollversioner och förmågor en server har innan den gör något annat.
• Multi Round-Trip Requests (MRTR) ersätter serverinitierade anrop. Behöver servern mer information mitt i en körning svarar den input_required i stället för att ringa tillbaka, och klienten gör om anropet med svaret. Enklare att resonera om, och enklare att säkra.
• Långkörande jobb flyttade ut ur kärnan till en officiell tillägsmodul (tasks), med pollning i stället för blockerande anrop.
• Listsvar är cachebara. Verktygs- och resurslistor bär nu livslängd och cache-räckvidd, vilket sänker både svarstid och kostnad.
• Roots, Sampling och Logging är utfasade. De fungerar fortfarande, men nya implementationer ska inte bygga på dem.

Det snabbaste sättet att förstå MCP är att koppla in en färdig server och se vad som händer. Båda verktygen nedan gör samma sak med olika syntax.

Claude Code

För en lokal server som startas som en process — allt efter -- skickas vidare oförändrat:

claude mcp add postgres -- npx -y @company/postgres-mcp

För en server som redan körs som en webbtjänst:

claude mcp add --transport http notion https://mcp.notion.com/mcp

Ska hela teamet dela konfigurationen lägger ni den i .mcp.json i projektroten och checkar in filen. Claude Code frågar varje användare om godkännande första gången — en incheckad serverlista kan alltså inte tyst börja köra hos någon annan:

{
  "mcpServers": {
    "kundregister": {
      "command": "npx",
      "args": ["-y", "@company/crm-mcp"],
      "env": { "CRM_TOKEN": "${CRM_TOKEN}" }
    }
  }
}

Tre räckvidder finns: local (bara ni, bara det här projektet), project (den incheckade .mcp.json) och user (ni, i alla projekt).

Codex

Samma server, samma protokoll, annan konfigurationsfil. Codex läser ~/.codex/config.toml:

codex mcp add kundregister -- npx -y @company/crm-mcp

[mcp_servers.kundregister]
command = "npx"
args = ["-y", "@company/crm-mcp"]

[mcp_servers.kundregister.env]
CRM_TOKEN = "..."

Var nyttan faktiskt uppstår beror mindre på tekniken än på vilket manuellt moment ni tar bort. De här mönstren återkommer:

Notera att fyra av fem rader är läsande. Det är sällan en slump. Läsande flöden ger nästan all nytta i början till en bråkdel av risken, och de går att sätta i produktion utan att någon behöver godkänna varje åtgärd. Skrivande flöden är också rätt svar — men senare, och med en godkännandegrind.

För era interna system finns ingen färdig server. Den goda nyheten är att en MCP-server i grunden är ett tunt lager: den beskriver några verktyg och översätter anropen till API:er eller frågor ni redan har. Det officiella SDK:t sköter protokollet.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "kundregister", version: "1.0.0" });

server.tool(
  "kund_slag_upp",
  "Slår upp en kund på organisationsnummer och returnerar " +
    "namn, status och ansvarig säljare. Returnerar aldrig personuppgifter.",
  { orgnr: z.string().regex(/^\d{10}$/) },
  async ({ orgnr }) => {
    const kund = await db.kunder.findByOrgnr(orgnr);
    if (!kund) {
      return { content: [{ type: "text", text: "Ingen kund med det numret." }] };
    }
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify({
            namn: kund.namn,
            status: kund.status,
            ansvarig: kund.ansvarigSaljare,
          }),
        },
      ],
    };
  },
);

Fyra saker i det lilla exemplet är värda att kopiera. Verktygsbeskrivningen säger både vad verktyget gör och vad det inte returnerar. Argumentet valideras med ett schema i stället för att litas på. Servern returnerar utvalda fält, inte hela kundposten. Och uteblivet svar är ett normalt svar, inte ett fel — modellen ska kunna säga ”jag hittade ingen” utan att flödet kraschar.

MCP ger en AI-modell möjlighet att både läsa er data och utföra åtgärder. Det är exakt det ni vill ha, och exakt därför det behöver styras. Tre risker är specifika nog att nämnas vid namn.

• Indirekt promptinjektion. Modellen hämtar in innehåll — ett mejl, en webbsida, ett ärende — som bär dolda instruktioner, och behandlar dem som om de kom från er. Angreppet kommer via en betrodd kanal, vilket är varför det är svårt att upptäcka. Grundregeln: allt en modell hämtar in är data, aldrig instruktioner.
• Tool poisoning. Instruktionerna göms i verktygets egen metadata — beskrivningar, parameternamn, fält som modellen läser vid körning men som användaren aldrig ser i gränssnittet. En server ni installerar utan att granska är därmed ett förtroende ni ger blint.
• Överbehörighet. Servern kopplas in med bredare rättigheter än uppgiften kräver, ofta för att det gick snabbare. Då avgör inte er riskaptit vad som kan hända vid en incident, utan vad tjänstekontot råkade ha tillgång till.

Det finns ingen enskild kontroll som löser det här. Det som fungerar är flera lager som var för sig är enkla:

• Minsta möjliga behörighet per server, och läsbehörighet som förval.
• Godkända serverlistor — installera inte MCP-servrar ni inte har granskat, och lås vilka som får köra.
• Mänskligt godkännande före åtgärder med konsekvens: utskick, betalningar, borttagningar, allt som når en kund.
• Loggning som går att granska i efterhand: vilket verktyg, med vilka argument, av vem, när.
• Maskning av personuppgifter på vägen ut ur servern, inte i modellprompten.

Protokollet självt drar åt samma håll. Revisionen 2026-07-28 skärpte auktorisationsdelen mot etablerad OAuth- och OpenID Connect-praxis, och fasade ut dynamisk klientregistrering till förmån för klientidentiteter som går att verifiera. Det gör det möjligt att koppla ett MCP-anrop till en faktisk identitet — vilket är förutsättningen för att kunna granska något alls.

Ordningen spelar större roll än verktygsvalet. Den här sekvensen ger svar tidigt och håller risken låg medan ni lär er.

1. 1

   Välj ett moment som gör ont, inte ett system

   Leta efter stället där någon regelbundet klipper och klistrar mellan ett system och en chatt. Det är där nyttan är mätbar och uppenbar för den som utför arbetet.
2. 2

   Börja läsande

   Första servern ska bara hämta. Ni får nästan hela nyttan, en bråkdel av risken, och ingen behöver godkänna varje anrop medan ni lär er.
3. 3

   Avgränsa i servern, inte i prompten

   Bestäm i koden vilka fält som lämnar systemet. En instruktion om vad modellen ”inte ska titta på” är inte en säkerhetsåtgärd.
4. 4

   Kör skarpt med en liten grupp i två veckor

   Mät sparad tid och notera varje gång svaret blev fel. Felen är den mest värdefulla informationen ni får i hela projektet.
5. 5

   Lägg till skrivande åtgärder med grind

   Först när det läsande flödet är stabilt. Varje åtgärd med konsekvens får ett mänskligt godkännande och en logg som går att följa upp.
6. 6

   Bestäm förvaltningen innan ni skalar

   Vem äger servern, vem godkänner nya, hur uppgraderas de när specen ändras? Utan svar blir varje ny integration en ny liten skuld.

Vi bygger den här typen av kopplingar åt svenska företag — oftast mot Microsoft 365, affärssystem och egna databaser, med kontrollpunkterna på plats från början. Vill ni resonera kring ett konkret flöde är vår kostnadsfria AI-audit ett bra första steg, och våra AI-assistenter visar hur det ser ut i drift.