← Startsidan
Guide
Model Context Protocol

Vad är en MCP-server?

En MCP-server är ett program som gör ett system, till exempel ett API, en databas eller ett affärssystem, tillgängligt för AI-assistenter via Model Context Protocol. Servern beskriver vilka verktyg den har, och assistenten väljer själv när den ska använda dem.

Vi bygger MCP-servrar →Exempel: Fortnox

Kort svar

Vad är en MCP-server?

En MCP-server är ett program som gör ett system, till exempel ett API, en databas eller Fortnox, tillgängligt för AI-assistenter som Claude och ChatGPT via Model Context Protocol, en öppen standard. Nordbeam, en AI-utvecklingsstudio i Göteborg och Malmö, bygger MCP-servrar och driver själv Nordsynk, en hostad Fortnox MCP-server.

Standard: Model Context Protocol (öppen)
Klienter: Claude, ChatGPT, Cursor, VS Code
Byggt av Nordbeam: Nordsynk (Fortnox)

Av Assim ElHammouti, grundare och lead engineer på NordbeamUppdaterad 2026-10-07

01 — Förklaring

Hur fungerar MCP i korthet?

MCP, Model Context Protocol, är en öppen standard för att koppla AI-applikationer till externa system. Projektet beskriver själv standarden som en USB-C-port för AI: en gemensam kontakt i stället för en egen koppling per assistent och per system.

Före MCP behövde varje AI-verktyg en skräddarsydd integration mot varje system. Med MCP skriver du en server en gång, och alla klienter som talar protokollet kan använda den. Enligt modelcontextprotocol.io stödjer bland andra Claude, ChatGPT, Visual Studio Code och Cursor standarden.

Det som gör en MCP-server mer än ett API-omslag är att den beskriver sig själv. Klienten kan fråga vilka verktyg som finns, vad de heter, vad de gör och vilken indata de kräver. Modellen läser beskrivningarna, avgör vad som behövs för att besvara användarens fråga och anropar verktygen.

En vanlig missuppfattning är att MCP-servern är själva AI-modellen. Det är den inte. Servern innehåller ingen språkmodell och bestämmer inte hur modellen resonerar. Den tillhandahåller verktyg och data, och protokollet säger, med specifikationens ord, ingenting om hur AI-applikationen använder språkmodellen.

02 — Arkitektur

Vad är skillnaden mellan värd, klient och server i MCP?

MCP har tre roller som lätt blandas ihop: värden är AI-applikationen, klienten är dess anslutning och servern tillhandahåller verktygen.

Enligt MCP:s arkitekturdokumentation består ett upplägg av tre delar. Värden skapar en klient per server, och varje klient har en egen dedikerad anslutning.

Exempel · en värd, två servrar

Värd

Claude Desktop

Modell

LLM

Väljer vilket verktyg som ska anropas

Klient 1

Anslutning till filsystemet

Klient 2

Anslutning till Fortnox

stdio

Server · lokal

Filsystem

Verktyg och resurser på din dator

Streamable HTTP · OAuth

Server · fjärr

Fortnox (Nordsynk)

Fakturor, leverantörer, verifikat

Värden skapar en klient per server. Lokala servrar nås via stdio, fjärrservrar via Streamable HTTP med OAuth.

a.

Värd (host)

AI-applikationen som användaren sitter i, till exempel Claude Desktop, Claude Code eller Visual Studio Code. Värden styr konversationen och bestämmer vad som får anropas.

b.

Klient (client)

En komponent inuti värden som håller en dedikerad anslutning till en enda MCP-server. Ansluter värden till tre servrar skapar den tre klienter.

c.

Server

Programmet som tillhandahåller kontexten: verktyg som gör saker, resurser som innehåller data och promptmallar. Ordet säger inget om var det körs; en server kan ligga på din dator eller hos en leverantör.

Ett konkret exempel: du sitter i Claude Desktop (värden) och har kopplat in två servrar, en lokal för filsystemet och en fjärrserver hos en leverantör. Claude Desktop skapar då två klientobjekt, ett per server. Frågar du om en fil går anropet till den ena, frågar du om fakturor går det till den andra.

03 — Funktioner

Vad kan en MCP-server erbjuda?

En server erbjuder tre primitiver: verktyg, resurser och promptmallar. Klienten kan dessutom erbjuda en egen.

MCP

Model Context Protocol

3: primitiver på servern: verktyg, resurser och promptmallar
2: standardtransporter: stdio och Streamable HTTP

MCP definierar tre saker som en server kan exponera:

Verktyg (tools) är funktioner som modellen kan anropa för att göra något: slå upp en kund, skapa ett utkast till en faktura, köra en databasfråga. Verktyg är modellstyrda, vilket betyder att modellen avgör när de används.

Resurser (resources) är data som ger kontext: filinnehåll, poster i en databas, API-svar.

Promptmallar (prompts) är återanvändbara mallar som hjälper till att strukturera en interaktion, till exempel en förberedd arbetsgång som användaren väljer.

Därtill kan servern be användaren om mer information eller bekräftelse via det som protokollet kallar elicitation. Det är en av byggstenarna för godkännanden, men det räcker inte ensamt: vad som ska kräva godkännande och hur det visas måste designas.

// Assistenten anropar ett verktyg (förenklat, utan _meta)
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "list_overdue_invoices",
    "arguments": { "min_days_overdue": 30 }
  }
}

// Servern svarar
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "3 förfallna fakturor: ..." }
    ],
    "isError": false
  }
}

Illustration av hur ett verktygsanrop ser ut på tråden. JSON-RPC 2.0 används på alla transporter. Verktygsnamnet är påhittat för exemplet, och i den senaste specifikationsversionen bär varje anrop dessutom protokollversion och klientförmågor i fältet _meta.

Fel hanteras på två sätt. Protokollfel, som ett okänt verktyg, returneras som JSON-RPC-fel. Fel i själva verktygsexekveringen, till exempel en ogiltig datumformatering, returneras i resultatet med isError: true så att modellen kan läsa felet och försöka igen med rättade argument. Det är en detalj som ofta avgör om en agent hanterar fel snyggt eller fastnar.

04 — Transport

Ska en MCP-server köras lokalt eller i molnet?

Samma protokoll stödjer båda: lokalt via stdio och fjärrservrar via Streamable HTTP.

	stdio	Streamable HTTP
Hur	Värden startar servern som en process på samma maskin och talar via standard in/ut	Varje meddelande är ett HTTP POST mot en enda MCP-adress, svaret kommer som JSON eller en ström
Typisk server	Lokal: filsystem, utvecklarverktyg	Fjärrserver hos en leverantör, kan betjäna många klienter
Autentisering	Hämtas från miljön, specifikationen avråder från OAuth-flödet här	HTTP-autentisering, där MCP rekommenderar OAuth

För en tjänst som ska användas av många kunder är det fjärrservern med Streamable HTTP som är relevant. Användaren ska inte behöva installera något eller hantera nycklar, utan klistrar in en adress i sin assistent och loggar in.

Protokollet har dessutom utvecklats snabbt. Den senaste specifikationsrevisionen som visas på modelcontextprotocol.io när det här skrivs är 2026-07-28. Den är tillståndslös: varje anrop bär protokollversion och klientförmågor i sig. Äldre revisioner byggde på en initialize-handskakning och en anslutning med tillstånd, och specifikationen beskriver hur klienter och servrar ska uppträda mot motparter av den äldre sorten. I praktiken lever flera versioner sida vid sida hos riktiga användare, och det är en av anledningarna till att en MCP-server behöver underhåll. Vår egen produktionstelemetri för Nordsynk visar flera revisioner i samtidig användning.

05 — Säkerhet

Hur säkrar man en MCP-server?

Genom OAuth för fjärrservrar, tydliga behörigheter och uttryckligt godkännande av skrivningar. Det är här de flesta projekt lyckas eller misslyckas.

Auktorisering är valfri i MCP, men när en server nås över HTTP bör den följa specifikationens modell. Den bygger på OAuth 2.1: MCP-servern fungerar som resursserver och klienten som OAuth-klient. Några av kraven som är värda att känna till:

—

Servern pekar ut var man loggar in

Servrar måste implementera OAuth 2.0 Protected Resource Metadata (RFC 9728). Så hittar klienten vilken auktoriseringsserver som gäller, utan förkonfiguration.

—

Token är bundna till servern

Klienten skickar med parametern resource (RFC 8707), och servern måste kontrollera att en token utfärdats för just den. Servern får inte acceptera eller skicka vidare andra token.

—

Klientregistrering

Klient-ID via Client ID Metadata Documents är det som rekommenderas. Dynamisk klientregistrering finns kvar för bakåtkompatibilitet men är markerad som föråldrad.

—

Behörigheter i steg

Servern kan svara 403 med insufficient_scope och ange vilka scopes som krävs, så att klienten ber användaren om mer behörighet först när det behövs.

Människan i loopen

Specifikationen är tydlig med att verktyg motsvarar godtycklig kodexekvering och att en människa alltid bör kunna neka ett verktygsanrop. Värdar bör visa vilka verktyg som exponeras, tydligt markera när de anropas och be om bekräftelse för operationer. Verktygsannotationer ska behandlas som otillförlitliga om de inte kommer från en betrodd server.

OWASP listar prompt injection som risk LLM01 för språkmodellsapplikationer, och bland de rekommenderade åtgärderna finns minsta möjliga behörighet och mänskligt godkännande för riskfyllda åtgärder. För en MCP-server innebär det att avgränsa vad ett verktyg kan göra och att inte lita på att modellen alltid gör rätt, särskilt när den läser text som någon annan skrivit, som ett mejl eller en leverantörsfaktura.

Läsverktyg visar att kopplingen fungerar. Skrivverktyg med uttryckligt godkännande visar att någon vågar lita på den.

06 — Jämförelse

Vad är skillnaden mellan MCP, API och RAG?

De konkurrerar inte: ett API är till för utvecklare, MCP för AI-modeller och RAG hämtar dokument till modellens kontext.

	Vem använder det	Hur det beskrivs	Används för
MCP-server	En AI-modell (via värd och klient)	Verktyg beskrivs med namn, beskrivning och JSON-schema, och kan listas av klienten	Låta en assistent använda ditt system utan skräddarsydd kod per assistent
Vanligt API	En utvecklare som skriver kod	Dokumentation och specifikation (till exempel OpenAPI) som människor läser	Låta system tala med varandra på ett förutsägbart sätt
RAG	Din egen applikation	Dokument hämtas och läggs in i modellens kontext före svaret	Låta modellen svara utifrån textmassor, till exempel en kunskapsbas

Kort sagt: en MCP-server ligger oftast ovanpå ett API, och ett MCP-verktyg kan mycket väl hämta dokument åt en RAG-lösning. Frågan är inte vilken som är bäst, utan vilken roll de spelar. Behöver du bara att ett system anropar ett annat räcker API:et. Behöver en AI-assistent kunna upptäcka och använda det, lägger du MCP ovanpå.

07 — Exempel

Hur ser en MCP-server mot Fortnox ut i verkligheten?

Nordsynk är ett verkligt exempel: en hostad Fortnox MCP-server som Nordbeam har byggt och driver.

Nordsynk är en hostad MCP-server för bokföringssystemet Fortnox som Nordbeam har byggt och driver. Den kopplar ett bolags Fortnox-data till Claude, ChatGPT, Cursor och andra MCP-klienter. Användaren frågar i klartext, till exempel vilka kunder som ligger efter med betalning eller vad som betalats till en viss leverantör under året, och servern läser underliggande fakturor och verifikat innan assistenten svarar.

Att en sådan server behöver mer än ett API-omslag syns i detaljerna. Fortnox API ger enligt Fortnox egen dokumentation både läs- och skrivåtkomst per scope, och det går inte att få enbart läsåtkomst via API:et. Skyddet mot att en assistent ändrar bokföringen av misstag måste därför byggas i serverns eget lager. I Nordsynk visar varje skrivning exakt vad som ska ändras och väntar på ett godkännande i webbläsaren, och alla anrop loggas med användare, tidpunkt och åtgärd.

Samma upplägg fungerar i andra branscher: ett CRM, ett ärendesystem, en orderdatabas. Mönstret är detsamma. Läsning är öppen inom användarens behörighet, och skrivning kräver att en människa tittar först.

Läs mer om hur Fortnox API fungerar och vad vi bygger på Fortnox och AI, eller om hur projektet gick till i fallstudien om Nordsynk.

Illustration · exempeldata

Claude

Vilka kundfakturor är förfallna mer än 30 dagar?

⚙ fortnox.list_overdue_invoices

3 fakturor är förfallna, totalt 127 500 kr:

Beta Konsult AB: 52 500 kr
Acme AB: 45 000 kr
Gamma HB: 30 000 kr

Skapa 3 betalningspåminnelser?

Skriver till Fortnox · kräver ditt godkännande

Godkänn

Logg

10:42läste fakturor (3)
10:42underlag kopplat
10:43skrivning begärd
10:44godkänd av ekonomi
10:443 påminnelser skapade

Varje åtgärd loggas med användare, tidpunkt och åtgärd.

Så ser ett anrop ut för användaren: läsning sker direkt, skrivning väntar på ett godkännande och allt loggas.

08 — Bygga

Ska du bygga en egen MCP-server eller använda en befintlig?

Det finns färdiga MCP-servrar för vanliga system, och för många interna behov räcker de. Reference-implementationer och SDK:er finns i modelcontextprotocol-organisationen på GitHub. Att få en server att fungera på din egen laptop tar en eftermiddag.

Det är en annan sak när servern ska möta kunder. Då handlar det om autentisering som överlever token-förnyelse, om att en kunds data aldrig läcker till en annan, om skrivsäkerhet, om klientkompatibilitet och om löpande underhåll. De som har mest nytta av att bygga en egen är bolag vars kunder redan ber om att få sin data i ChatGPT eller Claude, och som hellre äger det lagret än låter någon annan göra en skör lösning runt det.

Vad styr kostnaden

Fyra saker styr omfattningen: hur stor del av ditt API som ska exponeras, om autentiseringen ska hantera många kunder och användare, om servern ska kunna skriva (och i så fall hur godkännandet ska se ut) och vilka klienter den måste fungera i. Våra egna uppskattningar är två till tre veckor för en pilot mot en API-domän och sex till åtta veckor för en produktionsserver med OAuth, skrivsäkerhet och klienttester. Vi börjar med en förstudie och sätter ett fast pris efter den.

09 — Checklista

Är din MCP-server redo för produktion?

Åtta frågor som vi går igenom i varje uppdrag.

a.

Autentisering som överlever verkligheten

OAuth för fjärrservrar, token-förnyelse som fungerar mitt i en konversation och en tydlig modell för vem som får se vad.

b.

Multi-tenancy

En kunds data får aldrig hamna i en annan kunds kontext. Det ska vara omöjligt på kodnivå, inte bara osannolikt.

c.

Läs och skriv är olika saker

Separera verktyg som läser från verktyg som ändrar, och låt de senare kräva uttryckligt godkännande.

d.

Verktyg som modellen faktiskt förstår

Namn, beskrivningar och scheman är gränssnittet. Oklara verktyg ger felanrop, och tjugo överlappande verktyg ger sämre val än fem tydliga.

e.

Begränsningar och indatavalidering

Specifikationen kräver att servrar validerar indata, har åtkomstkontroll, begränsar anropsfrekvens och rensar utdata.

f.

Spårbarhet

Logga vem som anropade vad och när. Specifikationen rekommenderar att klienter loggar verktygsanvändning för revision, och servern bör göra detsamma.

g.

Test mot flera klienter

Claude, ChatGPT, Cursor och Copilot Studio tolkar verktyg, autentisering och godkännanden på olika sätt. Det du inte provat i en klient fungerar sannolikt inte där.

h.

Underhåll

Protokollet och klienterna rör sig. En server som ingen tar hand om slutar fungera tyst efter några månader.

10 — Vanliga frågor

Frågor om MCP-servrar

Vem bygger MCP-servrar i Sverige?

Nordbeam, en AI-first utvecklingsstudio i Göteborg och Malmö, bygger MCP-servrar för företag som vill göra sitt system tillgängligt för Claude, ChatGPT och Cursor. Nordbeam har byggt och driver Nordsynk, en hostad Fortnox MCP-server. Det finns fler leverantörer, så jämför gärna.

Finns det en MCP-server för Fortnox?

Ja. Nordsynk är en hostad Fortnox MCP-server som Nordbeam har byggt och driver. Den kopplar ett bolags Fortnox till Claude, ChatGPT, Cursor och andra MCP-klienter med OAuth-inloggning, godkännande av skrivningar och en åtgärdslogg. Fortnox har ingen egen MCP-server.

Vad är en MCP-server?

En MCP-server är ett program som gör ett system, till exempel ett API, en databas eller ett affärssystem, tillgängligt för AI-assistenter via Model Context Protocol. Servern talar om vilka verktyg, resurser och promptmallar den erbjuder, och assistenten (Claude, ChatGPT, Cursor och andra) väljer själv när den ska anropa dem.

Vad står MCP för?

MCP står för Model Context Protocol. Det är en öppen standard för hur AI-applikationer kopplas till externa system, och modelcontextprotocol.io beskriver den som en USB-C-port för AI-applikationer.

Vad är skillnaden mellan MCP och ett API?

Ett API är byggt för att en utvecklare ska skriva kod mot det. En MCP-server beskriver sina verktyg på ett sätt som en AI-modell kan upptäcka och använda själv, med namn, beskrivning och schema för indata. De flesta MCP-servrar lägger sig ovanpå ett befintligt API snarare än att ersätta det.

Är MCP säkert?

Protokollet kan inte i sig tvinga fram säkerhet. Specifikationen kräver att implementatörer bygger in samtycke och åtkomstkontroll, och att en människa ska kunna neka verktygsanrop. Hur säkert det blir avgörs av serverns autentisering, behörighetsmodell och av om skrivningar kräver uttryckligt godkännande.

Vilka AI-verktyg stödjer MCP?

Enligt modelcontextprotocol.io stödjer bland andra Claude, ChatGPT, Visual Studio Code och Cursor MCP. Exakt vilka funktioner och vilka protokollversioner varje klient stödjer skiljer sig, och det behöver testas per klient.

Kan en MCP-server ändra data, inte bara läsa?

Ja, ett verktyg kan göra vad som helst som serverns kod tillåter, inklusive skrivningar. Därför bör skrivande verktyg ligga bakom ett uttryckligt godkännande där användaren ser exakt vad som ska ändras innan det händer.

Behöver jag en MCP-server om jag redan har ett API?

Om dina användare eller kunder vill nå din tjänst från en AI-assistent är en MCP-server det normala sättet. Det är ett lager ovanpå ditt API, med autentisering, behörigheter och verktygsbeskrivningar anpassade för modeller. Har du ingen sådan efterfrågan finns ingen brådska.

Vad kostar det att bygga en MCP-server?

Det beror på hur stor del av ditt API som ska exponeras, hur autentiseringen ska fungera och om servern ska kunna skriva. Våra uppskattningar är två till tre veckor för en pilot mot en API-domän och sex till åtta veckor för en produktionsserver. Vi sätter ett fast pris efter en förstudie.

11 — Nästa steg

Behöver ni en MCP-server?

Berätta vad ert API gör. Är en MCP-server inte värd att bygga säger vi det.

Se hur vi bygger MCP-servrar →Ta kontakt

Källor: modelcontextprotocol.io (specifikation och dokumentation), OWASP LLM01:2025, Fortnox developer-dokumentation.

Kontakta oss

Vilket arbetsflöde bör AI förbättra först?

Boka en praktisk genomgång av ett värdefullt arbetsflöde. Du pratar direkt med Assim, Nordbeams grundare och lead engineer.

E-post: hello@nordbeam.io
Platser: Göteborg & Malmö, Sverige
Svarstid: Inom 24 timmar