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 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. Sådan fungerer den i praksis, og en rigtig 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 byggede en GitHub-integration ind i Claude. Fordi et sted — jeres IT-team, en leverandør, en udvikler på GitHub — skrev nogen et lille program, der taler en protokol, som hedder MCP, og Claude allerede ved, hvordan det taler med alt, der taler den. Det samme gælder nu for ChatGPT, Googles Gemini og Microsoft Copilot. Den samling, mere end nogen enkelt funktionsudgivelse, er grunden til, at MCP blev det, næsten alle AI-leverandører brugte 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. Lanceringmaterialet 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, heriblandt virksomhedssoftwarefirmaerne Block og Apollo samt værktøjsmagerne Zed, Replit, Codeium og Sourcegraph. Claudes skrivebordsapp udkom samme dag med evnen til at køre MCP-servere lokalt på en persons egen maskine.
Problemet den løser: N værktøjer gange M datakilder
Problemet MCP løser har et navn, ingeniører bruger i forbifarten: N-gange-M-integrationsproblemet. Sig, 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 tager 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 sit eget godkendelsesskema, sin egen fejlhåndtering og sin egen vedligeholdelsesafgift, hver gang et af de API'er skifter form. 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-forbindelse. 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ærdige servere til Google Drive, Slack, GitHub, Git, Postgres og et browserautomatiseringsværktøj, 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 forbi det, ét enkelt firma kunne bemande.
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 programmet, en person faktisk åbner — Claude Desktop, et IDE som Cursor, 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 sagsværktøj, et filsystem, et internt API. Klient og server udveksler beskeder formateret som 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
MCP's første måneder var et projekt kun hos Anthropic. Det ændrede sig hurtigt, og på en måde, der er oprigtigt 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 kan 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, beregnet til at lade uafhængige agenter koordinere med hinanden snarere end 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 landede 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 for at koble en agent til et værktøj. Det er sjældent nok i den her branche til at være den egentlige historie — mere end nogen enkelt funktion, MCP gør mulig.
Hvorfor det her er et tillidsspørgsmål, ikke kun rørføring
Den samling er oprigtigt 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, er en protokol, der gør det 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 — den siger intet om, hvem der må give en forbindelse, hvad den forbindelse må røre ved, eller om nogen opdager det, hvis noget går galt. De valg ligger helt hos den, der byggede eller konfigurerede den konkrete server eller klient foran dig. Nogle leverandører bygger det hele omhyggeligt. Nogle bygger det slet ikke, og protokollen vil ikke standse dem.
MCP er en trådprotokol, 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, nogen traf — eller undlod 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 fandt 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 godkend, og faktisk læser det svar, forbindelsesskærmen giver tilbage.
| Spørg om det her | Sådan ser godt 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." | Samlet "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 inkluderet automatisk, uden måde at se, hvilken evne 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; 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 tilsluttede den, hvad den rørte ved, og hvornår. | Ulogget Ingen registrering ud over det, AI-værktøjet selv vælger at fortælle, der skete. |
| Kan den trækkes tilbage med det samme? | Øjeblikkelig Én kontakt, virksom med det samme, fra en indstillingsside, du styrer. | Forsinket Tilbagetrækning kræver en supportsag, et opkald til leverandøren, eller er slet ikke mulig. |
| Ødelægger tilbagetrækning noget andet? | Isoleret Afgrænset til den ene forbindelse; at slukke den berører kun den. | Sammenfiltret Deler en legitimationsoplysning med andre værktøjer, så tilbagetrækning af ét i stilhed ø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 navngive den faktiske mekanik i stedet 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 holdkammerat.
Hver forbindelse, i begge retninger, begynder med en person, ikke et arbejdsområde. At tilslutte en ekstern klient som Cursor åbner et OAuth-samtykkesskærmbillede 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å det skærmbillede, under den ene persons tilladelser, 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 gennemfører stadig sit eget login, 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, leverandøren eksponerer.
Hver tilsluttede klient vises på et indstillingsskærmbillede ved siden af en Træk tilbage-kontrol, der afbryder den med det samme — på personens egen side, ikke i en supportsag. På Enterprise-planer lander den aktivitet — herunder MCP-tildelinger og hvad en tilsluttet agent faktisk gjorde — i en revisionslog, et sikkerhedsteam kan gennemgå på forespørgsel, 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, gentaget konsekvent: afgræns det, bind det til en person, log det, gør det muligt at trække tilbage uden sideskade. Det er det samme argument, dette site fører mere bredt om Læsbarhed — adgang, du kan navngive, logge og trække tilbage, slår adgang, ingen behøver at tænke over — og MCP leverer det kun, når nogen bygger det sådan. Protokollen gør rørføringen til standard. Den gør ikke styringen automatisk.
Beslutningen, der faktisk betyder noget
MCP forsvinder ikke, og at gøre indsigelse mod den på det her 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 udgave 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 i uden at læse det med småt. Beslutningen, der stadig faktisk er din, er, hvad du tjekker, før du klikker 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 give — den del er stadig, og vil blive ved med at være, en beslutning for den person, der klikker "godkend".