Hva er MCP, og hvorfor snakker plutselig hvert AI-verktøy det?
I mesteparten av det siste tiåret betydde det å koble en AI-modell til bedriftens verktøy en skreddersydd integrasjon for hvert par. Model Context Protocol, den åpne standarden Anthropic la fram i november 2024, erstattet det med én plugg som passer overalt — og OpenAI, Google og Microsoft har siden tatt den i bruk. Slik fungerer den i praksis, og en ekte sjekkliste før du kobler en til teamets data.
Åpne skrivebordsappen til Claude og be den sjekke teamets åpne pull requests, så kan den bare gjøre det. Ikke fordi Anthropic bygde en GitHub-integrasjon inn i Claude. Fordi et sted — IT-teamet deres, en leverandør, en utvikler på GitHub — skrev noen et lite program som snakker en protokoll som heter MCP, og Claude allerede vet hvordan det snakker med alt som snakker den. Det samme gjelder nå for ChatGPT, Googles Gemini og Microsoft Copilot. Den samlingen, mer enn noen enkelt funksjonslansering, er grunnen til at MCP ble det nesten alle AI-leverandører brukte det siste året på å bygge støtte for.
Hva MCP faktisk er
MCP står for Model Context Protocol. Anthropic utformet den og åpnet spesifikasjonen sammen med de første SDK-ene 25. november 2024. Lanseringsmaterialet beskrev ideen med en sammenligning som ble hengende igjen: tenk på MCP som en USB-C-port for AI-applikasjoner — én fysisk kontaktstandard i stedet for en egen kabel til hvert tilbehør. Ved lanseringen navnga Anthropic tidlige brukere som allerede bygde MCP-støtte inn i egne produkter, blant dem bedriftsprogramvareselskapene Block og Apollo, pluss verktøymakerne Zed, Replit, Codeium og Sourcegraph. Skrivebordsappen til Claude kom samme dag med evnen til å kjøre MCP-servere lokalt på en persons egen maskin.
Problemet den løser: N verktøy ganger M datakilder
Problemet MCP løser har et navn ingeniører bruker i forbifarten: N-ganger-M-integrasjonsproblemet. Si at et selskap bruker fem AI-verktøy som må handle på selskapsdata — Claude, ChatGPT, GitHub Copilot, Cursor og en intern støttebot — og at dataene ligger på åtte steder: Slack, GitHub, en Postgres-database, Salesforce, Notion, Google Drive, Jira og et internt API. Uten en felles protokoll tar det opptil førti separate integrasjoner å koble hvert verktøy til hver kilde på en nyttig måte — fem ganger åtte — hver med sitt eget autentiseringsskjema, sin egen feilhåndtering og sin egen vedlikeholdskost hver gang ett av de API-ene skifter form. Legg til et sjette AI-verktøy, og tallet hopper til førtiåtte. I praksis bygde ingen alle førti. Hver AI-leverandør bygde den håndfullen den mente var verdt ingeniørtiden, og resten ble manuelt: kopier, lim inn, forklar på nytt, gjenta.
MCP gjør multiplikasjonen til addisjon. Et selskap som vil at Claude skal lese fra Postgres-databasen, bygger ikke en Claude-spesifikk Postgres-kobling. Det bygger — eller gjenbruker en som noen andre allerede har publisert — én MCP-server som eksponerer Postgres, og den serveren virker med Claude, ChatGPT, Gemini eller enhver annen MCP-kompatibel agent, uten mer kode. Anthropics egen liste navnga ved lanseringen ferdige servere for Google Drive, Slack, GitHub, Git, Postgres og et nettleserautomatiseringsverktøy som heter Puppeteer. Poenget var aldri at Anthropic skulle bygge alle. Poenget var at hvem som helst kunne, og katalogen over tilgjengelige servere har vokst langt forbi det ett enkelt selskap kunne bemanne.
Slik fungerer protokollen i praksis
Ta bort innpakningen, og MCP er en ganske alminnelig klient-server-protokoll, bevisst uglamorøs i utformingen. Den definerer tre roller. En Host er programmet en person faktisk åpner — Claude Desktop, en IDE som Cursor, ChatGPT-appen. Host-en bygger inn en MCP Client, som åpner en direkte, tilstandsbevarende tilkobling til en MCP Server — et lite program som eksponerer ett bestemt system: en database, et saksverktøy, et filsystem, et internt API. Klient og server utveksler meldinger formatert som JSON-RPC 2.0, et lettvektsformat for fjernprosedyrekall som allerede er vanlig i eksisterende infrastruktur, over én av to transporter: stdio, når serveren er et program som kjører lokalt på samme maskin, eller Streamable HTTP, når det er en vertstjeneste som kjører et annet sted.
Det en server kan eksponere, koker ned til tre primitiver. Tools er funksjoner modellen kan kalle for å utføre en handling — create_task, run_query, send_message — og modellen avgjør ut fra samtalen når den skal kalle en. Resources er skrivebeskyttet kontekst som Host-en kan hente inn og gi til modellen uten at den må be om det — innholdet i en fil, et databaseskjema, en supportsak. Prompts er gjenbrukbare, brukerutløste maler — et ferdig «oppsummer denne tråden» eller «utkast til en statusoppdatering» som en person kaller eksplisitt, i stedet for noe modellen selv bestemmer seg for å gjøre. En godt bygd server er tydelig på hvilken av de tre den tilbyr for en gitt evne, fordi nettopp det skillet avgjør om et tilkoblet AI-verktøy kan se på noe eller endre det.
Hvem andre tok den i bruk, og når
De første månedene var MCP et prosjekt bare hos Anthropic. Det endret seg fort, og på en måte som er genuint uvanlig i AI: direkte konkurrenter samlet seg om ett selskaps protokoll i stedet for å sende ut sine egne. OpenAI la til MCP-støtte i Agents SDK i mars 2025, slik at utviklere kan koble agentarbeidsflyter til en hvilken som helst MCP-server i stedet for å bygge skreddersydde, OpenAI-spesifikke verktøyintegrasjoner. Måneden etter bekreftet Google DeepMind at Gemini og selskapets eget utviklingssett for agenter også skulle støtte MCP — et grep Google knyttet til sin egen utfyllende protokoll, Agent2Agent, ment å la uavhengige agenter samordne seg med hverandre heller enn bare med verktøy. Innen mai 2025 hadde Microsoft brakt innebygd MCP-støtte til Windows 11 gjennom det de kaller Windows AI Foundry, og støtten landet også i GitHub Copilot og Copilot Studio.
Ingen av de fire selskapene er enige om stort når det gjelder modellarkitektur, prising eller plattformstrategi. Alle fire sender nå ut produkter som snakker samme protokoll for å koble en agent til et verktøy. Det er sjeldent nok i denne bransjen til å være den egentlige historien — mer enn noen enkeltfunksjon MCP gjør mulig.
Hvorfor dette er et tillitsspørsmål, ikke bare rørlegging
Den samlingen er genuint nyttig, og nettopp derfor fortjener MCP gransking framfor blind tillit. En protokoll som gjør det trivielt for en agent å koble seg til selskapets systemer, er en protokoll som gjør det trivielt for en dårlig bygd eller dårlig konfigurert tilkobling å nå de samme systemene. MCP i seg selv hindrer ikke det. Spesifikasjonen definerer hvordan en klient og en server snakker sammen — den sier ingenting om hvem som får innvilge en tilkobling, hva den tilkoblingen får røre, eller om noen vil merke det hvis noe går galt. De valgene ligger helt hos den som bygde eller konfigurerte den konkrete serveren eller klienten foran deg. Noen leverandører bygger alt det med omhu. Noen bygger det ikke i det hele tatt, og protokollen vil ikke stoppe dem.
MCP er en trådprotokoll, ikke et system for tilgangskontroll. Den standardiserer hvordan en agent ber et verktøy om å gjøre noe. Om den forespørselen er avgrenset, logget og kan trekkes tilbake, er en beslutning noen tok — eller lot være å ta — oppå den.
En sjekkliste før du kobler til en
Før teamet kobler til en MCP-server — enten det er et produkt fra en leverandør, et åpen kildekode-verktøy noen fant på GitHub, eller noe som er bygd internt — skiller seks spørsmål en styrt tilkobling fra en åpen dør. Ingen av dem krever at du leser spesifikasjonen. De krever bare at noen spør før de klikker godkjenn, og faktisk leser svaret tilkoblingsskjermen gir tilbake.
| Spør om dette | Slik ser bra ut | Se etter |
|---|---|---|
| Hvilke scope eller verktøy ber den om? | Spesifisert En navngitt, konkret liste du kan lese før du godkjenner — «opprett oppgaver, les meldinger i denne kanalen.» | Samlet «Full kontotilgang» uten en spesifisert liste over hva den faktisk kan gjøre. |
| Er den skrivebeskyttet, eller kan den skrive og handle? | Adskilt Lesetilgang som standard; enhver handling som endrer data trenger et eget synlig samtykke. | Buntet Skrivetilgang inkludert automatisk, uten måte å se hvilken evne som gjør hva. |
| Er den per person eller delt i hele teamet? | Per person Hver person logger inn med sin egen pålogging; agenten ser bare det den personen kan se. | Delt Én API-nøkkel eller tjenestekonto som hele teamet bruker, og som går utenom individuelle tillatelser. |
| Finnes det en revisjonslogg over hva den gjorde? | Logget Hvert verktøykall registreres — hvem som koblet den til, hva den rørte, og når. | Ulogget Ingen registrering utover det AI-verktøyet selv velger å fortelle at skjedde. |
| Kan den trekkes tilbake med en gang? | Umiddelbar Én bryter, virksom med en gang, fra en innstillingsside du styrer. | Forsinket Tilbaketrekking krever en supportsak, en samtale med leverandøren, eller er ikke mulig i det hele tatt. |
| Ødelegger tilbaketrekking noe annet? | Isolert Avgrenset til den ene tilkoblingen; å slå den av berører bare den. | Sammenfiltret Deler en legitimasjon med andre verktøy, slik at tilbaketrekking av ett i stillhet ødelegger tre andre. |
Slik ser en godt bygd tilkobling faktisk ut
FabricLoops egen MCP-oppsett er ett konkret svar på den sjekklisten — ikke fordi det er uvanlig, men fordi hver del svarer direkte på ett av de seks spørsmålene over, og det er verdt å navngi den faktiske mekanikken i stedet for markedsføringsversjonen. FabricLoop kjører begge rollene samtidig: det er en MCP-server som eksterne verktøy kobler seg til, slik at Cursor, Claude eller ChatGPT kan opprette en oppgave, legge til en kommentar eller lese et notat med en bestemt persons egne FabricLoop-tillatelser — og det er en MCP-klient som kobler utover, slik at en kanal kan hente inn en leverandørs MCP-app, som GitHub eller Linear, og @-nevne den som en lagkamerat.
Hver tilkobling, i begge retninger, starter med en person, ikke et arbeidsområde. Å koble til en ekstern klient som Cursor åpner et OAuth-samtykkeskjermbilde på app.fabricloop.com/oauth/consent, der personen velger et arbeidsområde og godkjenner de konkrete verktøyene klienten ber om — klienten kan deretter bare handle med scope-ene som ble innvilget på det skjermbildet, under den ene personens tillatelser, aldri via en delt tjenestekonto. Motsatt retning fungerer på samme måte: en administrator kan slå på en leverandørs MCP-app for hele teamet, men hver person fullfører likevel sin egen pålogging før den virker for vedkommende, og en administrator kan sette appen i skrivebeskyttet modus eller begrense den til en tillatelsesliste over bestemte verktøy i stedet for alt leverandøren eksponerer.
Hver tilkoblede klient vises på et innstillingsskjermbilde ved siden av en Trekk tilbake-kontroll som kobler den fra med en gang — på personens egen side, ikke i en supportsak. På Enterprise-planer havner den aktiviteten — inkludert MCP-innvilgelser og hva en tilkoblet agent faktisk gjorde — i en revisjonslogg et sikkerhetsteam kan gå gjennom på forespørsel, i stedet for skjermbilder som hentes ut av en chattråd i etterkant.
Ingenting av dette er eksotisk ingeniørarbeid. Det er et lite, bevisst uglamorøst sett med beslutninger, gjentatt konsekvent: avgrens det, knytt det til en person, logg det, gjør det mulig å trekke tilbake uten sideskade. Det er det samme argumentet dette nettstedet fører mer generelt om Lesbarhet — tilgang du kan navngi, logge og trekke tilbake slår tilgang ingen trenger å tenke på — og MCP leverer det bare når noen bygger det slik. Protokollen gjør rørleggingen til standard. Den gjør ikke styringen automatisk.
Beslutningen som faktisk betyr noe
MCP forsvinner ikke, og å protestere mot den på dette tidspunktet minner litt om å protestere mot USB. Alle de store modellleverandørene sender den ut nå, listen over tilgjengelige servere fortsetter å vokse, og en agent som ikke når verktøyene dine er, for det meste av virkelig arbeid, en agent som ikke får gjort særlig mye. Den interessante beslutningen er ikke om du lar et AI-verktøy koble seg til systemene dine — i økende grad blir en versjon av den beslutningen allerede tatt for deg, én integrasjon om gangen, etter hvert som verktøy teamet allerede bruker stille legger til MCP-støtte under en funksjon du klikket inn i uten å lese det som sto med liten skrift. Beslutningen som fortsatt faktisk er din, er hva du sjekker før du klikker godkjenn.
MCP standardiserte hvordan en AI-agent ber et verktøy om å gjøre noe. Den gjorde ingenting for å standardisere om den forespørselen er trygg å innvilge — den delen er fortsatt, og vil forbli, en beslutning for personen som klikker «godkjenn».