REST standardiserte hvordan tjenester snakker med hverandre. GraphQL standardiserte hvordan klienter spør etter data. MCP standardiserer hvordan AI-modeller samhandler med verktøy, data og systemer.

Hvis du bygger agentisk AI -- systemer der språkmodeller tar beslutninger, kaller verktøy og påvirker tilstand -- bygger du et integrasjonslag. Det laget er den viktigste delen av arkitekturen din. Ikke modellen. Ikke prompten. Laget som står mellom modellens intensjoner og verdens tilstand.

Vi har brukt MCP i produksjon på tvers av flere systemer. Denne artikkelen handler om hva vi lærte: hvorfor MCP eksisterer, hvordan det sammenlignes med det som fantes før, hvor sikkerhetsgrensene lever, og mønstrene som overlever møtet med ekte trafikk.

I. Problemet MCP løser

Hvert team som bygger med AI-modeller treffer den samme veggen: verktøyintegrasjon.

Modellen trenger å lese en database. Den trenger å kalle et API. Den trenger tilgang til filer. Den trenger å søke i en kunnskapsbase. Hver integrasjon er et skreddersydd oppdrag: skriv et JSON-skjema, koble opp autentisering, håndter feil, pars responser, be om at modellen kaller det riktig.

Multipliser dette med ti verktøy og tre modeller, og du har et kombinatorisk kaos. Hver modell har sitt eget format for funksjonskall. Hvert verktøy har sitt eget autentiseringsmønster. Hver integrasjon er skreddersydd. Testing er manuell. Revisjon er ønsketenkning.

Before MCP:


Model A ---custom--> Tool 1 (custom auth, custom schema)
  Model A ---custom--> Tool 2 (different auth, different schema)
  Model B ---custom--> Tool 1 (rewire everything)
  Model B ---custom--> Tool 2 (rewire everything again)



N models x M tools = N*M integrations

MCP kollapser dette. Det definerer en standardprotokoll slik at enhver modell kan snakke med enhver verktøyserver, og enhver verktøyserver kan betjene enhver modell. Integrasjonsmatrisen blir additiv, ikke multiplikativ.

After MCP:


Model A --MCP--> Server 1 (tools: DB, files)
  Model A --MCP--> Server 2 (tools: API, search)
  Model B --MCP--> Server 1 (same protocol)
  Model B --MCP--> Server 2 (same protocol)



N models + M servers = N+M integrations

Dette er det samme skiftet REST brakte til tjeneste-til-tjeneste-kommunikasjon. En delt protokoll som gjør integrasjonskostnaden forutsigbar.

II. Protokollen: Hva MCP faktisk definerer

MCP er en JSON-RPC 2.0-basert protokoll med tre kjernefunksjoner:

Tools

Tools er funksjoner modellen kan kalle. Hvert verktøy har et navn, en beskrivelse (som modellen leser for å avgjøre når den skal bruke det), og et JSON Schema for parameterne. Serveren registrerer verktøy; klienten (modellens kjøretidsmiljø) oppdager dem og presenterer dem for modellen som tilgjengelige handlinger.

{
  "name": "query_database",
  "description": "Execute a read-only SQL query against the analytics database",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "SQL SELECT query (read-only)"
      }
    },
    "required": ["query"]
  }
}

Modellen ser dette skjemaet og bestemmer -- basert på brukerens forespørsel og sin egen resonnering -- om og hvordan den skal kalle verktøyet. MCP-klienten sender kallet til serveren. Serveren utfører det og returnerer et strukturert resultat.

Resources

Resources er data modellen kan lese. Filer, databaseposter, API-responser, konfigurasjon -- alt modellen måtte trenge som kontekst. Resources har URI-er og kan listes, leses og abonneres på for oppdateringer.

Dette er «kontekst» i Model Context Protocol. I stedet for å stappe alt inn i systemprompten, kan modellen hente det den trenger, når den trenger det.

Prompts

Prompts er gjenbrukbare maler som servere kan tilby klienter. En databaseserver kan tilby en «schema exploration»-prompt. En dokumentasjonsserver kan tilby en «code review»-prompt. Disse er valgfrie, men nyttige for å standardisere vanlige arbeidsflyter på tvers av team.

Transportlaget

MCP støtter to transportmekanismer: stdio (for lokale prosesser) og HTTP med SSE (for eksterne servere). stdio-transporten er enkel: start en prosess, send JSON-RPC over stdin/stdout. HTTP-transporten legger til nettverkskapabilitet med Server-Sent Events for strømming.

stdio transport (local):


Client --stdin/stdout--> MCP Server Process



HTTP transport (remote):



Client --HTTP POST--> MCP Server --SSE--> Client

De fleste produksjonsoppsett bruker stdio for lokale verktøy (filsystem, database) og HTTP for eksterne tjenester. Protokollen er den samme; transporten er en implementasjonsdetalj.

III. MCP vs REST vs GraphQL: Ulike problemer, ulike æraer

Dette er ikke en «hva er best»-sammenligning. Disse protokollene løser ulike problemer for ulike konsumenter.

REST standardiserte tjeneste-til-tjeneste-kommunikasjon. Konsumenten er en programmerer som skriver kode mot et kjent API. API-et er designet for menneskelig forståelse: endepunkter er navngitte, dokumenterte og versjonerte. Konsumenten vet hva den vil ha før den sender forespørselen.

GraphQL standardiserte klientdrevne dataspørringer. Konsumenten er en frontendutvikler som trenger fleksibel tilgang til en datagraf. API-et er designet for spørringskomposisjon: klienten spesifiserer nøyaktig hvilke data den trenger. Konsumenten kjenner skjemaet og konstruerer spørringer mot det.

MCP standardiserer modell-til-verktøy-interaksjon. Konsumenten er en språkmodell som oppdager verktøy under kjøring og bestemmer hvilke den skal bruke basert på naturlig språkresonnering. API-et er designet for maskinforståelse: verktøybeskrivelser er skrevet slik at modeller kan forstå når og hvordan de skal bruke dem.

Protocol   Consumer     Discovery      Selection
  -------------------------------------------------------
  REST       Programmer   Documentation  Code-time choice
  GraphQL    Frontend     Schema intro   Query composition
  MCP        LLM          Runtime list   Reasoning-based

Nøkkelinnsikten: MCP-verktøy må være selvbeskrivende på en måte som modeller kan resonnere over. Et REST-endepunkt kalt /api/v2/analytics/query er greit for en programmerer som har lest dokumentasjonen. Et MCP-verktøy trenger en beskrivelse som «Execute a read-only SQL query against the analytics database. Use this when the user asks about metrics, usage patterns, or historical data.» Beskrivelsen er en del av grensesnittet, ikke en kommentar.

IV. Sikkerhetsgrenser: MCP-serveren som flaskehals

Det er her MCP virkelig viser sin verdi i produksjon. MCP-serveren er ikke bare en bro mellom modellen og verktøyene. Den er en sikkerhetsgrense.

Prinsipp: Modellen har ingen hemmeligheter

Modellen ser aldri databaselegitimasjon, API-nøkler eller autentiseringstokens. MCP-serveren holder hemmelighetene. Modellen holder verktøyskjemaer. Når modellen kaller et verktøy, autentiserer serveren forespørselen, anvender legitimasjonen, utfører handlingen og returnerer resultatet. Modellen ser outputen, ikke rørleggerarbeidet.

{
  "mcpServers": {
    "database": {
      "command": "mcp-server-postgres",
      "args": ["--read-only", "--connection", "$DB_URL"],
      "env": { "DB_URL": "postgres://readonly:***@db.internal/analytics" }
    }
  }
}

$DB_URL løses på serversiden. Modellen ser den aldri.

Prinsipp: Avgrens tilgang per server

Hver MCP-server bør eksponere minimalt med verktøy som trengs for sitt formål. En rapporteringsserver eksponerer skrivebeskyttede databasespørringer. En filserver eksponerer lesetilgang til spesifikke kataloger. En publiseringsserver eksponerer skrivetilgang til et spesifikt CMS.

Ikke bygg én MCP-server som kan gjøre alt. Bygg mange servere som hver kan gjøre én ting godt. Dette er prinsippet om minste privilegium anvendt på AI-verktøytilgang.

Prinsipp: Auditer alt

Hvert verktøykall passerer gjennom MCP-serveren. Det gjør den til det naturlige revisjonspunktet. Logg:

  • Tidsstempel
  • Verktøynavn og parametere
  • Kallende modell/agent-identitet
  • Brukerkontekst (hvem utløste oppgaven)
  • Resultatsammendrag
  • Latens og tokenkostnad

Denne revisjonssporingen er ikke bare for feilsøking. Den er for compliance. EU AI Act krever logging og sporbarhet for AI-systemer med høy risiko. MCP gir deg flaskehalsen der den loggingen naturlig hører hjemme.

Prinsipp: Ratebegrens på serveren

Modellen vet ikke at den er dyr. En modell i en retry-løkke vil gladelig kalle et verktøy femti ganger. MCP-serveren bør håndheve ratebegrensninger per verktøy, per agent, per oppgave. Når grensen er nådd, returner en strukturert feilmelding: «Rate limit exceeded. You have used 10 of 10 allowed calls to query_database for this task.»

Modellen kan resonnere over denne tilbakemeldingen og justere sin tilnærming. Dette er ikke en krasj. Det er en begrensning agenten kan jobbe innenfor.

V. Produksjonsmønstre

Mønster 1: Den skrivebeskyttede analytikeren

Det vanligste MCP-mønsteret i produksjon. En modell har skrivebeskyttet tilgang til databaser og filer. Den svarer på spørsmål ved å spørre data, ikke ved å endre tilstand.

User: "What was our conversion rate last week?"
       |
  Agent --MCP--> database server (read-only)
       |         -> SELECT ... FROM events WHERE ...
       |
  Agent: "Last week's conversion rate was 3.2%, up from 2.8%."

Sikkerhetsprofil: lav risiko. Modellen kan ikke endre data. Verste fall er en kostbar spørring, som serveren ratebegrenser.

Mønster 2: Den avgrensede skriveren

Modellen kan skrive til et spesifikt, avgrenset system. Et innholdsstyringssystem. En oppgavesporer. En deploy-pipeline. Skrivetilgang er avgrenset til spesifikke operasjoner med validering.

{
  "name": "create_draft",
  "description": "Create a new draft article in the CMS",
  "inputSchema": {
    "type": "object",
    "properties": {
      "title": { "type": "string", "maxLength": 200 },
      "body": { "type": "string", "maxLength": 50000 },
      "status": { "type": "string", "enum": ["draft"] }
    },
    "required": ["title", "body"]
  }
}

Merk: status-feltet er begrenset til "draft". Modellen kan ikke publisere direkte. Et menneske gjennomgår og publiserer. Skjemaet er guardrail-en.

Mønster 3: Flerserver-orkestratoren

Komplekse oppgaver krever flere MCP-servere. Agenten spør en database, leser dokumentasjon og oppdaterer en oppgavesporer -- hver gjennom en forskjellig server med forskjellige rettigheter.

Agent --MCP--> database (read-only)
       --MCP--> documentation (read-only)
       --MCP--> task-tracker (scoped write)
       --MCP--> slack-notifier (scoped write)

Hver server kan revideres uavhengig. Hver server har sine egne ratebegrensninger og rettigheter. Agenten orkestrerer; serverne håndhever.

Mønster 4: Gateway-serveren

For enterprise-utrullinger med mange verktøy aggregerer en gateway MCP-server flere backends bak et enkelt grensesnitt. Gatewayen håndterer autentisering, ruting og tverrgående bekymringer (logging, ratebegrensning, kretsbryting).

Agent --MCP--> Gateway Server ---> Backend A
                                ---> Backend B
                                ---> Backend C

Dette legger til et lag, men forenkler klientkonfigurasjon og sentraliserer sikkerhetspolicy.

VI. Bygge MCP-servere: Praktiske notater

Hold beskrivelser ærlige

Verktøybeskrivelsen er det viktigste feltet. Modeller bruker den for å avgjøre når de skal kalle verktøyet. En vag beskrivelse fører til feil verktøyvalg. En beskrivelse som lover mer enn verktøyet leverer, fører til kjøretidsfeil.

Skriv beskrivelser som om du forklarer verktøyet til en kompetent kollega som aldri har sett kodebasen din. Vær spesifikk om hva verktøyet gjør, hva det ikke gjør, og når det bør brukes.

Valider input strengt

Modellen vil hallusinere parametere. Den vil sende strenger der du forventer tall. Den vil utelate obligatoriske felt. Den vil finne opp feltnavn. Serveren din må validere all input mot skjemaet og returnere nyttige feilmeldinger.

En god feilmelding: «Parameter 'date_range' must be an object with 'start' and 'end' string fields in ISO 8601 format. Received: string.»

En dårlig feilmelding: «Invalid input.»

Modellen kan selvkorrigere med god tilbakemelding. Den kan ikke selvkorrigere med dårlig tilbakemelding.

Returner strukturerte resultater

Modeller resonnerer bedre over strukturerte data enn over prosa. Returner JSON-objekter med tydelige feltnavn, ikke avsnitt med tekst.

{
  "result": {
    "rows_returned": 42,
    "data": [...],
    "query_time_ms": 23,
    "note": "Results limited to 100 rows per policy"
  }
}

Håndter feil som data

Verktøyfeil er ikke eksepsjonelle i agentiske systemer. De er normale. En spørring som returnerer ingen resultater. En ratebegrensning som er nådd. En rettighet som er nektet. Returner disse som strukturerte feilresponser, ikke som unntak som krasjer agenten.

VII. Enterprise-adopsjonsstien

Start med skrivebeskyttet

Enhver enterprise MCP-adopsjon bør starte med skrivebeskyttede servere. Koble modellen til databaser, dokumentasjon og overvåkingssystemer. La teamene bygge tillit til at modellen bruker verktøy korrekt før du gir skrivetilgang.

Legg til skrivetilgang bak porter

Når skrivebeskyttet er bevist, legg til avgrenset skrivetilgang med human-in-the-loop-godkjenning. Modellen foreslår handlinger; mennesker godkjenner eller avviser. Spor godkjenningsrater, avvisningsgrunner og feilrater. Når feilraten er konsekvent lav, vurder å redusere godkjenningsporten til stikkprøvekontroll.

Standardiser på tvers av team

Kraften i MCP er den delte protokollen. Hvis hvert team bygger sin egen verktøyintegrasjon, mister du komposisjonsfordelen. Publiser interne MCP-servermaler. Definer navnekonvensjoner for verktøy. Etabler sikkerhetsgrunnlinjer for serverkonfigurasjon.

Overvåk verktøybruksmønstre

MCP-servere genererer rik telemetri: hvilke verktøy som kalles, hvor ofte, av hvilke agenter, med hvilke suksessrater. Disse dataene er gull for å forstå hvordan AI faktisk brukes i organisasjonen din -- og hvor den sliter.

VIII. Hva MCP ikke løser

MCP er en integrasjonsprotokoll. Den løser ikke:

  • Modellkvalitet. En dårlig modell med gode verktøy er fortsatt et dårlig system.
  • Prompt engineering. MCP gir verktøy; du må fortsatt instruere modellen i hvordan den skal bruke dem klokt.
  • Eval. MCP forteller deg ikke om modellen bruker verktøy korrekt. Du trenger eval-rammeverk for det.
  • Flermodell-orkestrering. MCP kobler en modell til verktøy. Koordinering av flere modeller er en bekymring på høyere nivå.
  • Datastyring. MCP håndhever tilgang på servernivå, men beslutningen om hvilke data modellen bør ha tilgang til er din.

MCP er en rørleggerstandard. Som REST ligger verdien i hva den muliggjør, ikke i hva den gjør alene.

IX. Hvorfor dette betyr noe nå

AI-industrien er ved integrasjonens vendepunkt. Modellenes kapabilitetskurve har løpt fra integrasjonsinfrastrukturen. Modeller kan resonnere over komplekse oppgaver, planlegge flerstegs arbeidsflyter og bruke verktøy effektivt -- men å koble dem til verktøyene de trenger er fortsatt en manuell, skjør, team-for-team-innsats.

MCP er det mest troverdige forsøket på å standardisere dette laget. Det er ikke det eneste forsøket -- OpenAI har function calling, Google har extensions, LangChain har verktøyabstraksjoner. Men MCP har tre fordeler: det er modellagnostisk, det er åpen kildekode, og det definerer sikkerhetsgrenser som en førsteklasses bekymring.

Vi bruker MCP fordi det lar oss bygge én gang og koble til enhver modell. Vi bruker det fordi server-som-flaskehals-arkitekturen gir oss revisjons- og sikkerhetsegenskapene vi trenger. Vi bruker det fordi det er kjedelig på de riktige måtene -- en protokoll, ikke et rammeverk; en standard, ikke en mening.

Teamene som bygger god MCP-infrastruktur nå vil ha en sammensatt fordel. Hvert nytt verktøy, hver ny modell, hver ny brukssituasjon kobles til eksisterende infrastruktur i stedet for å kreve en ny integrasjon. Det er løftet fra standarder. MCP innfrir det.

Referanser

  1. Model Context Protocol. Specification. spec.modelcontextprotocol.io
  2. Anthropic. Introducing the Model Context Protocol. anthropic.com
  3. MCP. Official Server Implementations. github.com/modelcontextprotocol/servers
  4. JSON-RPC 2.0 Specification. jsonrpc.org
  5. Fielding, R. (2000). Architectural Styles and the Design of Network-Based Software Architectures. Doctoral dissertation, UC Irvine.
  6. GraphQL Foundation. GraphQL Specification. graphql.org
  7. European Parliament. EU AI Act -- Logging and Traceability Requirements. artificialintelligenceact.eu
  8. OWASP. LLM Top 10. owasp.org
  9. Anthropic. Tool Use Documentation. docs.anthropic.com
  10. OpenAI. Function Calling. platform.openai.com
  11. Google. Gemini Function Calling. ai.google.dev
  12. NIST. AI Risk Management Framework. nist.gov