Bygga MCP-server: sex regler för en koppling som håller

Det börjar nästan alltid på en fredag. Någon på ekonomi har sett en demo, hittar en färdig MCP-server på GitHub, klistrar in API-nyckeln till bokföringen i en konfigurationsfil och kopplar den till Claude på sin egen dator. Det funkar. Claude svarar på frågor om fakturorna, och alla blir glada.

Sen kommer måndagen. Kollegan vill också ha det, så nyckeln mejlas. En konsult får låna datorn en eftermiddag. Och ingen kan svara på vem som frågade vad, eller om Claude kan radera något, eftersom nyckeln kan allt som systemet tillåter.

Att bygga en MCP-server är inte svårt. Att bygga en MCP-server som håller när fler än en person använder den är ett annat jobb. Den här texten är reglerna vi följer när vi bygger kopplingar mellan Claude och svenska affärssystem, hämtade ur hur våra kopplingar till Fortnox, Next och iBinder faktiskt är byggda. Hela listan finns på sidan om kopplingar mellan Claude och era system.

Vad är en MCP-server, och varför räcker det inte att den fungerar?

En MCP-server är en tolk mellan Claude och ett system. MCP står för Model Context Protocol, en öppen standard som Anthropic släppte i november 2024¹. Servern beskriver vilka verktyg Claude får använda, till exempel "sök kund" eller "hämta faktura", och översätter varje anrop till något systemet förstår.

För er betyder det att Claude läser i systemet själv i stället för att någon klistrar in exporter. Men en server som fungerar på en dator är inte samma sak som en server som tål ett helt företag. Skillnaden sitter i fyra frågor som demon aldrig ställer: vem är det som frågar, vad får hen se, vad får hen ändra, och vem märker det när något går sönder.

MCP-specifikationen har egna regler för inloggning² och en lista med säkerhetsråd³. De är bra, men de är skrivna för utvecklare. Här är samma tankar översatta till det ni ska kräva av den som bygger er koppling.

Hur ska man bygga en MCP-server som håller?

Sex regler. Varje regel står med hur den ser ut i en koppling vi har byggt.

Regel 1: Ert eget jobbkonto, inte en delad nyckel

Den vanligaste genvägen är en enda API-nyckel som alla delar. Då ser systemet bara "kopplingen", aldrig personen. I våra kopplingar till Fortnox, Next och iBinder loggar medarbetaren i stället in med sitt Microsoft-jobbkonto, via den sortens OAuth-inloggning som MCP-specifikationen beskriver². Kopplingen läggs till i Claude som en custom connector⁴, och varje person får sin egen åtkomst.

Rätt organisation räcker inte heller. I Fortnox-kopplingen ska personen dessutom stå på en namngiven lista, och den som tas bort från listan kommer inte in längre. Vem som står på listan bestämmer ni.

Regel 2: Läsa först, skriva sen

De flesta frågor till ett affärssystem handlar om att hitta och sammanställa: vilka fakturor är förfallna, hur går projektet mot budget. Därför kan våra kopplingar till Next, iBinder och Vitec bara läsa.

Fortnox visar varför gränsen måste byggas in i själva kopplingen. När vi byggde den lärde vi oss att Fortnox API inte har några behörigheter som bara läser, så om kopplingen inte sätter gränsen gör ingen det. I vår Fortnox-koppling ges skrivrätt per person, och den stannar vid att lägga upp kunder och fakturautkast. Bokföring och utskick görs fortfarande i Fortnox, av en människa, och Claude ska fråga innan varje skrivning.

Regel 3: Verktyg efter arbetsfrågor, inte efter API:et

Ett API kan ha hundratals ingångar. Speglar man dem rakt av får Claude en meny som ingen människa skulle orka läsa. Anthropic ger samma råd till alla som bygger verktyg för AI-agenter: bygg verktyg kring uppgifter, inte ett per ingång i API:et⁵.

Next-kopplingen har därför sex verktyg som heter som frågorna: sök projekt, projektöversikt, arbetsordrar, bokade timmar, sök kund och kundfakturor. Före: ett anrop mot en ingång med filter som bara en utvecklare kan läsa. Efter: "hur går projektet ekonomiskt?". Claude väljer rätt verktyg oftare, och svaren blir mindre, vilket gör dem både snabbare och billigare.

Regel 4: Bara det som behövs lämnar systemet

Det Claude aldrig får se kan inte hamna fel. Next-kopplingen skickar aldrig bankuppgifter, personnummer för privatkunder eller frånvaro till Claude, även om API:et har dem. Fortnox-kopplingen läser bokföringsfiler på servern och skickar bara de färdiga summorna vidare.

Det är samma princip som dataskyddsförordningen kallar uppgiftsminimering⁶, alltså att aldrig behandla fler personuppgifter än ändamålet kräver. Kopplingen ersätter inte er egen bedömning av vad som får behandlas, men den gör bedömningen enklare.

Regel 5: Nycklar i valvet, spår i loggen

Lösenord och API-nycklar till era system hör hemma i ett valv på servern, aldrig i koden och aldrig i en fil på en laptop. I Fortnox-kopplingen ligger nycklarna i ett sådant valv, och de token Claude får sparas bara som hash, alltså ett fingeravtryck som inte går att använda om någon kommer över det.

Lika viktigt är spåret. Fortnox- och iBinder-kopplingarna loggar varje anrop med vem, vad och när, men inte innehållet. När revisorn frågar vem som tittade på kundreskontran i mars finns svaret.

Regel 6: Drift som märker felen innan användarna gör det

Alla API:er har gränser för hur många anrop de tar emot. Fortnox tillåter 25 anrop per fem sekunder⁷, och Next tio anrop i sekunden. Våra kopplingar håller sig under gränserna och väntar in när de ändå nås, i stället för att ge Claude ett felmeddelande att gissa på. Skrivanrop görs aldrig om automatiskt efter ett serverfel, eftersom det kan ge dubbla fakturautkast.

API:er ändras också. Därför har Next-kopplingen en egen hälsokoll, och därför finns driften som en egen tjänst: satori-connect, 1 230 kronor i månaden per koppling, där det är vårt ansvar att laga kopplingen när leverantören ändrar något.

Vad gör en människa fortfarande när kopplingen finns?

Tre saker, och de försvinner inte. Någon bestämmer vilka som får åtkomst och tar bort dem som slutar. Någon läser svaret innan det blir ett beslut, särskilt när det gäller pengar. Och någon godkänner varje skrivning: Claude gör fakturautkastet, människan skickar fakturan.

Det är ingen brist i tekniken. Det är poängen med att bygga med struktur. Claude gör letandet, människan gör bedömningen.

Ska ni bygga MCP-servern själva eller köpa den?

Har ni utvecklare som kan OAuth och leverantörens API kan ni bygga själva, och då är reglerna ovan er kravlista. Finns det redan en officiell koppling från leverantören som täcker era frågor, använd den, för det är billigare och någon annan håller den uppdaterad. Varför så många svenska system saknar en sådan står i vår genomgång av AI-kopplingar till affärssystemet.

Vi bygger kopplingar som fastprisprojekt, med pris satt efter en genomgång av ert system. Hur det ser ut i ett riktigt system står i genomgången av Fortnox-kopplingen för Claude.

Checklista innan ni slår på en koppling

Loggar varje person in med sitt eget konto?
Finns det en lista över vem som får använda kopplingen, och vem på er sida äger listan?
Kan kopplingen skriva? I så fall vad, och frågar Claude först?
Vilka fält lämnar aldrig systemet?
Var ligger nycklarna, och finns det en logg över anropen?
Vem märker det när leverantörens API ändras?

Vad kan du göra i dag?

Öppna listan över integrationer i ert affärssystem och räkna hur många som använder en delad nyckel och hur många som har rätt att skriva. Den siffran säger mer om er säkerhet än en AI-policy på tio sidor, och den tar tio minuter att ta fram.

Vanliga frågor

Vad är en MCP-server?

En MCP-server är en tolk mellan Claude och ett system, byggd på Model Context Protocol, den öppna standard som Anthropic släppte i november 2024. Servern beskriver vilka verktyg Claude får använda, som sök kund eller hämta faktura, och översätter varje anrop till något systemet förstår. Det är också servern som avgör vem som får använda den och vad som loggas.

Hur bygger man en MCP-server för ett affärssystem?

Börja med de fem till tio frågor ni oftast ställer till systemet och bygg ett verktyg per fråga, inte ett per API-ingång. Lägg inloggningen på medarbetarnas egna jobbkonton, låt kopplingen bara läsa i början, skicka bara de fält som behövs, förvara nycklarna i ett valv och logga varje anrop. Sist: bestäm vem som lagar kopplingen när leverantörens API ändras.

Är det säkert att bygga en egen MCP-server?

Det är lika säkert som den är byggd. En server med en delad API-nyckel i en fil kan allt som nyckeln tillåter, utan spår av vem som frågade. En server med egen inloggning per person, läsrätt som standard, nycklar i ett valv och logg över anropen är en helt annan sak. Följ säkerhetsråden i MCP-specifikationen och kräv samma sak av den som bygger åt er.

Hur lång tid tar det att bygga en MCP-server?

En enklare koppling tar typiskt två till fyra veckor från genomgång till att teamet använder den. Koden går ofta snabbare än så. Det som tar tid är att få API-åtkomst från leverantören, bestämma vilka frågor kopplingen ska klara och testa med riktiga användare.

Måste en MCP-server kunna skriva i systemet?

Nej, och den bör inte göra det från start. De flesta frågor handlar om att hitta och sammanställa. Våra kopplingar till Next, Vitec och iBinder kan bara läsa. När skrivning behövs, som fakturautkast i Fortnox, ges den per person och Claude ska fråga innan varje ändring.

Vad kostar det att få en MCP-server byggd?

Hos oss är bygget ett fastprisprojekt som prissätts efter en genomgång av ert system, så ni vet priset innan arbetet börjar. Driften kostar 1 230 kronor i månaden per koppling med satori-connect och ingår om ni har satori-ai-avdelning.

Källor

Läs mer

Alla kopplingar vi har byggt: Fortnox, Next, Vitec, iBinder och Silverbucket, och vad de kan
AI-koppling till affärssystemet: varför den saknas: varför så få svenska system har en färdig koppling
Claude och Fortnox: så funkar kopplingen i vardagen: reglerna i ett riktigt system
Anthropic MCP: Nu pratar dina affärssystem med Claude: bakgrunden till MCP

Footnotes

Anthropic (2024). Introducing the Model Context Protocol. https://www.anthropic.com/news/model-context-protocol ↩
Model Context Protocol (2025). Authorization, version 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization ↩ ↩²
Model Context Protocol (2025). Security Best Practices. https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices ↩
Claude (2026). Add a connector that isn't in the directory. https://claude.com/docs/connectors/custom/remote-mcp ↩
Anthropic (2025). Writing effective tools for agents, with agents. https://www.anthropic.com/engineering/writing-tools-for-agents ↩
IMY. Grundläggande principer för behandling av personuppgifter. https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/grundlaggande-principer/ ↩
Fortnox Developer. Rate limits for Fortnox API. https://www.fortnox.se/developer/guides-and-good-to-know/rate-limits-for-fortnox-api ↩