Hvad er MCP, og hvorfor taler hvert AI-værktøj det pludselig?
I det meste af det seneste årti betød det at koble en AI-model til virksomhedens værktøjer en skræddersyet integration for hvert par. Model Context Protocol, den åbne standard, som Anthropic præsenterede i november 2024, erstattede det med ét stik, der passer overalt, og OpenAI, Google og Microsoft har siden taget den til sig. Her er, hvordan den i praksis fungerer, og en reel tjekliste, før du kobler en til teamets data.
Åbn Claudes skrivebordsapp, og bed den tjekke teamets åbne pull requests, så kan den bare gøre det. Ikke fordi Anthropic har bygget en GitHub-integration ind i Claude, men fordi nogen et sted — jeres IT-team, en leverandør, en udvikler på GitHub — har skrevet et lille program, der taler en protokol kaldet MCP, og Claude ved allerede, hvordan den skal tale med alt, der taler den. Det samme gælder nu for ChatGPT, Googles Gemini og Microsoft Copilot. Den konvergens, mere end nogen enkelt funktionsudgivelse, er grunden til, at MCP er blevet det, som næsten alle AI-leverandører har brugt det seneste år på at bygge understøttelse af.
Hvad MCP faktisk er
MCP står for Model Context Protocol. Anthropic udformede den og udgav specifikationen som open source sammen med de første SDK'er den 25. november 2024. Lanceringsmaterialet beskrev ideen med en sammenligning, der blev hængende: Tænk på MCP som en USB-C-port til AI-programmer, én fysisk stikstandard i stedet for et andet kabel til hvert tilbehør. Ved lanceringen nævnte Anthropic tidlige brugere, der allerede byggede MCP-understøttelse ind i deres egne produkter, blandt andre softwarevirksomhederne Block og Apollo samt udviklerværktøjsfirmaerne Zed, Replit, Codeium og Sourcegraph. Claudes skrivebordsapp udkom samme dag med mulighed for at køre MCP-servere lokalt på en persons egen maskine.
Problemet, den løser: N værktøjer gange M datakilder
Det problem, MCP løser, har et navn, som ingeniører bruger uformelt: N-gange-M-integrationsproblemet. Lad os sige, at en virksomhed bruger fem AI-værktøjer, der skal handle på virksomhedens data (Claude, ChatGPT, GitHub Copilot, Cursor og en intern supportbot), og at dataene ligger otte steder: Slack, GitHub, en Postgres-database, Salesforce, Notion, Google Drive, Jira og et internt API. Uden en fælles protokol kræver det op til fyrre separate integrationer at koble hvert værktøj til hver kilde på en brugbar måde (fem gange otte), hver med sin egen godkendelsesmodel, sin egen fejlhåndtering og sin egen vedligeholdelsesbyrde, hver gang et af de API'er ændrer sig. Læg et sjette AI-værktøj til, og tallet springer til otteogfyrre. I praksis byggede ingen alle fyrre. Hver AI-leverandør byggede den håndfuld, den vurderede var ingeniørtiden værd, og resten blev manuelt: kopiér, indsæt, forklar igen, gentag.
MCP gør multiplikationen til addition. En virksomhed, der vil have Claude til at læse fra sin Postgres-database, bygger ikke en Claude-specifik Postgres-connector. Den bygger, eller genbruger en, som en anden allerede har udgivet, én MCP-server, der eksponerer Postgres, og den server virker med Claude, ChatGPT, Gemini eller enhver anden MCP-kompatibel agent uden yderligere kode. Anthropics egen liste nævnte ved lanceringen færdigbyggede servere til Google Drive, Slack, GitHub, Git, Postgres og et værktøj til browserautomatisering, der hedder Puppeteer. Pointen var aldrig, at Anthropic skulle bygge dem alle. Pointen var, at hvem som helst kunne, og kataloget over tilgængelige servere er vokset langt ud over, hvad ét enkelt firma kunne have personale til.
Sådan fungerer protokollen i praksis
Tag indpakningen væk, og MCP er en ret almindelig klient-server-protokol, bevidst uglamourøs i udformningen. Den definerer tre roller. En Host er det program, en person faktisk åbner: Claude Desktop, en IDE som Cursor eller ChatGPT-appen. Host'en indlejrer en MCP Client, som åbner en direkte, tilstandsbevarende forbindelse til en MCP Server — et lille program, der eksponerer ét bestemt system: en database, et sagsstyringsværktøj, et filsystem eller et internt API. Klient og server udveksler beskeder i formatet JSON-RPC 2.0, et letvægtsformat til fjernprocedurekald, der allerede er udbredt i eksisterende infrastruktur, over en af to transporter: stdio, når serveren er et program, der kører lokalt på samme maskine, eller Streamable HTTP, når det er en hostet tjeneste, der kører et andet sted.
Det, en server kan eksponere, koges ned til tre primitiver. Tools er funktioner, modellen kan kalde for at udføre en handling — create_task, run_query, send_message — og modellen afgør ud fra samtalen, hvornår den skal kalde en. Resources er skrivebeskyttet kontekst, som Host'en kan hente ind og give til modellen, uden at den behøver at bede om det — en fils indhold, et databaseskema, en supportsag. Prompts er genbrugelige, brugerudløste skabeloner — et færdigt "opsummer denne tråd" eller "udkast til en statusopdatering", som en person kalder eksplicit, i stedet for noget modellen selv beslutter at gøre. En velbygget server er tydelig om, hvilken af de tre den tilbyder til en given evne, fordi netop den forskel afgør, om et tilsluttet AI-værktøj kan se på noget eller ændre det.
Hvem ellers tog den til sig, og hvornår
I de første måneder var MCP et rent Anthropic-projekt. Det ændrede sig hurtigt, og på en måde, der er reelt usædvanlig i AI: Direkte konkurrenter samlede sig om ét firmas protokol i stedet for at udsende deres egne. OpenAI tilføjede MCP-understøttelse til sin Agents SDK i marts 2025, så udviklere kunne koble agentarbejdsgange til en hvilken som helst MCP-server i stedet for at bygge skræddersyede, OpenAI-specifikke værktøjsintegrationer. Måneden efter bekræftede Google DeepMind, at Gemini og selskabets eget udviklingskit til agenter også ville understøtte MCP, et skridt, Google parrede med sin egen supplerende protokol, Agent2Agent, der skal lade uafhængige agenter koordinere med hinanden og ikke kun med værktøjer. I maj 2025 havde Microsoft bragt indbygget MCP-understøttelse til Windows 11 gennem det, de kalder Windows AI Foundry, og understøttelsen kom også i GitHub Copilot og Copilot Studio.
Ingen af de fire virksomheder er enige om ret meget, når det gælder modelarkitektur, prissætning eller platformsstrategi. Alle fire udsender nu produkter, der taler den samme protokol, når en agent skal kobles til et værktøj. Det er sjældent nok i den her branche til at være selve historien, mere end nogen enkelt funktion, som MCP gør mulig.
Hvorfor det her er et tillidsspørgsmål og ikke bare rørlægning
Den konvergens er reelt nyttig, og netop derfor fortjener MCP granskning frem for blind tillid. En protokol, der gør det trivielt for en agent at forbinde sig til virksomhedens systemer, gør det også trivielt for en dårligt bygget eller dårligt konfigureret forbindelse at nå de samme systemer. MCP i sig selv forhindrer det ikke. Specifikationen definerer, hvordan en klient og en server taler sammen, men siger intet om, hvem der må give tilladelse til en forbindelse, hvad forbindelsen må røre ved, eller om nogen opdager det, hvis noget går galt. De valg ligger helt hos den, der har bygget eller konfigureret den konkrete server eller klient foran dig. Nogle leverandører bygger det hele omhyggeligt. Nogle bygger det slet ikke, og protokollen standser dem ikke.
MCP er en kommunikationsprotokol og ikke et system til adgangskontrol. Den standardiserer, hvordan en agent beder et værktøj om at gøre noget. Om den anmodning er afgrænset, logget og kan trækkes tilbage, er en beslutning, som nogen har truffet, eller undladt at træffe, oven på den.
En tjekliste, før du kobler en til
Før teamet kobler en MCP-server til, hvad enten det er en leverandørs produkt, et open source-værktøj, nogen har fundet på GitHub, eller noget, der er bygget internt, adskiller seks spørgsmål en styret forbindelse fra en åben dør. Ingen af dem kræver, at du læser specifikationen. De kræver bare, at nogen spørger, før de klikker på godkend, og faktisk læser det svar, som forbindelsesskærmen giver.
| Spørg om det her | Sådan ser det gode ud | Hold øje med |
|---|---|---|
| Hvilke scopes eller værktøjer beder den om? | Specificeret En navngivet, konkret liste, du kan læse, før du godkender: »opret opgaver, læs beskeder i denne kanal«. | Bredt »Fuld kontoadgang« uden en specificeret liste over, hvad den faktisk kan gøre. |
| Er den skrivebeskyttet, eller kan den skrive og handle? | Adskilt Læseadgang som standard; enhver handling, der ændrer data, kræver sit eget synlige samtykke. | Bundtet Skriveadgang er inkluderet automatisk, uden mulighed for at se, hvilken funktion der gør hvad. |
| Er den pr. person eller delt på tværs af teamet? | Pr. person Hver person logger ind med sit eget login, og agenten ser kun det, den person kan se. | Delt Én API-nøgle eller tjenestekonto, som hele teamet bruger, og som går uden om individuelle tilladelser. |
| Findes der en revisionslog over, hvad den gjorde? | Logget Hvert værktøjskald registreres: hvem der koblede det til, hvad det rørte ved, og hvornår. | Ulogget Ingen registrering ud over det, AI-værktøjet selv vælger at fortælle om, hvad der skete. |
| Kan den trækkes tilbage med det samme? | Øjeblikkelig Ét klik, der virker med det samme, fra en indstillingsside, som du selv styrer. | Forsinket Tilbagetrækning kræver en supportsag, et opkald til leverandøren, eller er slet ikke mulig. |
| Ødelægger det noget andet at trække den tilbage? | Isoleret Afgrænset til den ene forbindelse, og hvis du slår den fra, berører det kun den. | Sammenfiltret Deler legitimationsoplysninger med andre værktøjer, så tilbagetrækning af ét i det stille ødelægger tre andre. |
Sådan ser en velbygget forbindelse faktisk ud
FabricLoops egen MCP-opsætning er ét konkret svar på den tjekliste. Ikke fordi den er usædvanlig, men fordi hver del svarer direkte på et af de seks spørgsmål ovenfor, og det er værd at nævne den faktiske mekanik frem for markedsføringsudgaven. FabricLoop kører begge roller på én gang: Det er en MCP-server, som eksterne værktøjer kobler sig til, så Cursor, Claude eller ChatGPT kan oprette en opgave, tilføje en kommentar eller læse en note med en bestemt persons egne FabricLoop-tilladelser, og det er en MCP-klient, der forbinder udad, så en kanal kan hente en leverandørs MCP-app ind, som GitHub eller Linear, og @-nævne den som en kollega.
Hver forbindelse, i begge retninger, begynder med en person og ikke et arbejdsområde. Når en ekstern klient som Cursor tilsluttes, åbnes en OAuth-samtykkeskærm på app.fabricloop.com/oauth/consent, hvor personen vælger et arbejdsområde og godkender de konkrete værktøjer, klienten beder om. Klienten kan derefter kun handle med de scopes, der blev givet på den skærm, under den ene persons tilladelser og aldrig via en delt tjenestekonto. Den modsatte retning fungerer på samme måde: En administrator kan slå en leverandørs MCP-app til for hele teamet, men hver person logger stadig selv ind, før den virker for vedkommende, og en administrator kan sætte appen i skrivebeskyttet tilstand eller begrænse den til en positivliste over bestemte værktøjer i stedet for alt, hvad leverandøren eksponerer.
Hver tilsluttet klient vises på en indstillingsside ved siden af knappen Træk tilbage, der afbryder den med det samme. Det foregår på personens egen side og ikke via en supportsag. På Enterprise-planer havner den aktivitet, herunder MCP-tildelinger og hvad en tilsluttet agent faktisk gjorde, i en revisionslog, som et sikkerhedsteam kan gennemgå efter behov, i stedet for skærmbilleder trukket ud af en chattråd bagefter.
Intet af det er eksotisk ingeniørarbejde. Det er et lille, bevidst uglamourøst sæt beslutninger, der gentages konsekvent: Afgræns adgangen, bind den til en person, log den, og gør det muligt at trække den tilbage uden følgeskader. Det er det samme argument, som vi fører mere generelt om Læsbarhed — adgang, du kan navngive, logge og trække tilbage, slår adgang, som ingen behøver at tænke over — og MCP leverer det kun, når nogen bygger det sådan. Protokollen gør rørlægningen standard. Den gør ikke styringen automatisk.
Beslutningen, der faktisk betyder noget
MCP forsvinder ikke, og at gøre indsigelse mod den på nuværende tidspunkt minder lidt om at gøre indsigelse mod USB. Alle de store modeludbydere udsender den nu, listen over tilgængelige servere bliver ved med at vokse, og en agent, der ikke kan nå dine værktøjer, er for det meste af det virkelige arbejde en agent, der ikke kan udrette ret meget. Den interessante beslutning er ikke, om du lader et AI-værktøj forbinde sig til dine systemer. I stigende grad bliver en version af den beslutning allerede truffet for dig, én integration ad gangen, efterhånden som værktøjer, teamet allerede bruger, stille tilføjer MCP-understøttelse under en funktion, du klikkede ind på uden at læse det med småt. Den beslutning, der stadig er din, er, hvad du tjekker, før du klikker på godkend.
MCP standardiserede, hvordan en AI-agent beder et værktøj om at gøre noget. Den gjorde intet for at standardisere, om den anmodning er sikker at imødekomme. Den del er stadig, og bliver ved med at være, en beslutning for den person, der klikker »godkend«.