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å gjør den bare det. Ikke fordi Anthropic har bygget en GitHub-integrasjon inn i Claude. Men fordi noen et sted – IT-teamet ditt, en leverandør, en utvikler på GitHub – har skrevet et lite program som snakker en protokoll som heter MCP, og Claude vet allerede hvordan den snakker med alt som bruker den. Det samme gjelder nå ChatGPT, Googles Gemini og Microsoft Copilot. Denne konvergensen, mer enn noen enkelt funksjonslansering, er grunnen til at MCP er blitt noe nesten alle AI-leverandører har brukt 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 som 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 supportbot – 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 krever det opptil førti separate integrasjoner å koble hvert verktøy til hver kilde på en nyttig måte – fem ganger åtte – hver med sin egen autentisering, sin egen feilhåndtering og sin egen vedlikeholdsbyrde hver gang ett av disse API-ene endrer form. Legg til et sjette AI-verktøy, og tallet hopper til førtiåtte. I praksis var det ingen som bygde 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 multiplikasjon 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 gjør Postgres tilgjengelig, og den serveren virker med Claude, ChatGPT, Gemini eller enhver annen MCP-kompatibel agent, uten mer kode. Anthropics egen liste nevnte ved lanseringen ferdige servere for Google Drive, Slack, GitHub, Git, Postgres og et verktøy for nettleserautomatisering 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 ha hatt folk til å drifte.
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 hostet tjeneste 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 rent Anthropic-prosjekt. Det endret seg raskt, og på en måte som er virkelig uvanlig i AI: Direkte konkurrenter samlet seg om ett selskaps protokoll i stedet for å lansere 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 utviklersett for agenter også skulle støtte MCP – et grep Google kombinerte med sin egen, utfyllende protokoll, Agent2Agent, som skal la uavhengige agenter samarbeide med hverandre og ikke bare med verktøy. Innen mai 2025 hadde Microsoft fått innebygd MCP-støtte i Windows 11 gjennom det de kaller Windows AI Foundry, og støtte kom også i GitHub Copilot og Copilot Studio.
Ingen av disse fire selskapene er enige om stort når det gjelder modellarkitektur, prising eller plattformstrategi. Alle fire leverer nå 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 spørsmål om tillit, ikke bare rørleggerarbeid
Denne konvergensen er genuint nyttig, og det er nettopp derfor MCP fortjener gransking framfor blind tillit. En protokoll som gjør det trivielt for en agent å koble seg til selskapets systemer, gjør det også 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 har lov til å godkjenne en tilkobling, hva tilkoblingen får røre, eller om noen vil merke det hvis noe går galt. De valgene ligger helt hos den som har bygget eller konfigurert den konkrete serveren eller klienten du står overfor. Noen leverandører bygger alt dette med omhu. Noen bygger det ikke i det hele tatt, og protokollen stopper dem ikke.
MCP er en overføringsprotokoll, ikke et system for tilgangskontroll. Den standardiserer hvordan en agent ber et verktøy om å gjøre noe. Om forespørselen er avgrenset, logget og kan trekkes tilbake, er en beslutning noen har tatt – eller latt være å ta – oppå protokollen.
En sjekkliste før du kobler til en server
Før teamet ditt kobler til en MCP-server – enten det er et produkt fra en leverandør, et verktøy med åpen kildekode som noen fant på GitHub, eller noe som er bygget internt – er det seks spørsmål som skiller 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.
| Spør om dette | Slik ser det bra ut | Se opp for |
|---|---|---|
| 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.» | Altomfattende «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. | Samlet Skrivetilgang er inkludert automatisk, uten mulighet til å se hvilken funksjon 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 det til, hva det rørte og når. | Ulogget Ingen registrering utover det AI-verktøyet selv velger å fortelle deg om hva som skjedde. |
| Kan den trekkes tilbake umiddelbart? | Umiddelbar Én bryter, virksom umiddelbart, fra en innstillingsside du styrer selv. | 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 påloggingsinformasjon med andre verktøy, slik at tilbaketrekking av ett i det stille ødelegger tre andre. |
Slik ser en godt bygd tilkobling faktisk ut
FabricLoops egen MCP-løsning er ett konkret svar på sjekklisten – ikke fordi den er uvanlig, men fordi hver del svarer direkte på ett av de seks spørsmålene ovenfor, og det er verdt å beskrive den faktiske mekanikken i stedet for markedsføringsversjonen. FabricLoop har 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 seg utover, slik at en kanal kan hente inn en leverandørs MCP-app, som GitHub eller Linear, og @-nevne den som et teammedlem.
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 nå er litt som å protestere mot USB. Alle de store modellleverandørene støtter den, listen over tilgjengelige servere vokser stadig, og en agent som ikke når verktøyene dine, er for det meste av det virkelige arbeidet en agent som ikke får gjort så mye. Den interessante beslutningen er ikke om du lar et AI-verktøy koble seg til systemene dine – i økende grad blir en eller annen versjon av den beslutningen allerede tatt for deg, én integrasjon om gangen, etter hvert som verktøyene teamet allerede bruker, i det stille legger til MCP-støtte under en funksjon du klikket deg inn i uten å lese det som sto med liten skrift. Beslutningen som fortsatt 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».