Vad är MCP, och varför talar plötsligt varje AI-verktyg det?
Under större delen av det senaste decenniet innebar det att koppla en AI-modell till företagets verktyg en skräddarsydd integration för varje par. Model Context Protocol, den öppna standard som Anthropic presenterade i november 2024, ersatte det med en kontakt som passar överallt — och OpenAI, Google och Microsoft har sedan dess alla tagit den till sig. Så här fungerar den i praktiken, och en riktig checklista innan du kopplar en till teamets data.
Öppna Claudes skrivbordsapp och be den kontrollera teamets öppna pull requests, så kan den bara göra det. Inte för att Anthropic byggde in en GitHub-integration i Claude. Utan för att någonstans — ert IT-team, en leverantör, en utvecklare på GitHub — skrev någon ett litet program som talar ett protokoll som heter MCP, och Claude redan vet hur det pratar med allt som talar det. Samma sak gäller nu för ChatGPT, Googles Gemini och Microsoft Copilot. Den samstämmigheten, mer än någon enskild funktionsrelease, är skälet till att MCP blivit det som nästan varje AI-leverantör ägnade det senaste året åt att bygga stöd för.
Vad MCP faktiskt är
MCP står för Model Context Protocol. Anthropic utformade det och publicerade specifikationen som öppen källkod tillsammans med de första SDK:erna den 25 november 2024. Det egna lanseringsmaterialet beskrev idén med en liknelse som fastnade: tänk på MCP som en USB-C-port för AI-tillämpningar — en fysisk kontaktstandard i stället för en annan kabel till varje tillbehör. Vid lanseringen namngav Anthropic tidiga användare som redan byggde in MCP-stöd i sina egna produkter, däribland företagsmjukvarubolagen Block och Apollo samt verktygsmakarna Zed, Replit, Codeium och Sourcegraph. Claudes skrivbordsapp släpptes samma dag med förmågan att köra MCP-servrar lokalt på en persons egen dator.
Problemet det löser: N verktyg gånger M datakällor
Problemet som MCP löser har ett namn som ingenjörer använder i förbigående: N-gånger-M-integrationsproblemet. Säg att ett företag använder fem AI-verktyg som behöver agera på företagets data — Claude, ChatGPT, GitHub Copilot, Cursor och en intern supportbot — och att datan finns på åtta ställen: Slack, GitHub, en Postgres-databas, Salesforce, Notion, Google Drive, Jira och ett internt API. Utan ett gemensamt protokoll tar det upp till fyrtio separata integrationer att koppla varje verktyg till varje källa på ett användbart sätt — fem gånger åtta — var och en med sitt eget autentiseringsschema, sin egen felhantering och sin egen underhållsskatt varje gång något av de API:erna byter form. Lägg till ett sjätte AI-verktyg och siffran hoppar till fyrtioåtta. I praktiken byggde ingen alla fyrtio. Varje AI-leverantör byggde den handfull som den bedömde vara värd ingenjörstiden, och allt annat förblev manuellt: kopiera, klistra in, förklara igen, upprepa.
MCP gör multiplikationen till addition. Ett företag som vill att Claude ska läsa från dess Postgres-databas bygger inte en Claude-specifik Postgres-koppling. Det bygger — eller återanvänder en som någon annan redan publicerat — en MCP-server som exponerar Postgres, och den servern fungerar med Claude, ChatGPT, Gemini eller vilken annan MCP-kompatibel agent som helst, utan mer kod. Anthropics egen lista namngav vid lanseringen färdiga servrar för Google Drive, Slack, GitHub, Git, Postgres och ett webbläsarautomationsverktyg som heter Puppeteer. Poängen var aldrig att Anthropic skulle bygga dem alla. Poängen var att vem som helst kunde, och katalogen av tillgängliga servrar har vuxit långt förbi vad ett enda företag skulle kunna bemanna.
Hur protokollet faktiskt fungerar
Skala bort inramningen och MCP är ett ganska alldagligt klient-serverprotokoll, medvetet oglamoröst till sin utformning. Det definierar tre roller. En Host är programmet en person faktiskt öppnar — Claude Desktop, en IDE som Cursor, ChatGPT-appen. Host:en bäddar in en MCP Client, som öppnar en direkt, tillståndsbevarande anslutning till en MCP Server — ett litet program som exponerar ett visst system: en databas, ett ärendeverktyg, ett filsystem, ett internt API. Klient och server utbyter meddelanden formaterade som JSON-RPC 2.0, ett lättviktigt fjärranropsformat som redan är vanligt i befintlig infrastruktur, över en av två transporter: stdio, när servern är ett program som körs lokalt på samma maskin, eller Streamable HTTP, när det är en värdtjänst som körs någon annanstans.
Det en server kan exponera kokar ner till tre primitiver. Tools är funktioner som modellen kan anropa för att utföra en handling — create_task, run_query, send_message — och modellen avgör utifrån samtalet när den ska anropa en. Resources är skrivskyddad kontext som Host:en kan hämta in och ge till modellen utan att den behöver be om den — en fils innehåll, ett databasschema, ett supportärende. Prompts är återanvändbara, användarutlösta mallar — ett färdigt "sammanfatta den här tråden" eller "utkast till en statusuppdatering" som en person anropar uttryckligen, i stället för något modellen själv bestämmer sig för att göra. En välbyggd server är tydlig med vilken av de tre den erbjuder för en given förmåga, eftersom just den skillnaden avgör om ett anslutet AI-verktyg kan titta på något eller ändra det.
Vem mer tog upp det, och när
MCP:s första månader var ett projekt enbart hos Anthropic. Det ändrades snabbt, och på ett sätt som är genuint ovanligt inom AI: direkta konkurrenter samlades kring ett enda företags protokoll i stället för att skeppa sina egna. OpenAI lade till MCP-stöd i sin Agents SDK i mars 2025, så att utvecklare kan koppla agentflöden till vilken MCP-server som helst i stället för att bygga skräddarsydda, OpenAI-specifika verktygsintegrationer. Månaden därpå bekräftade Google DeepMind att Gemini och dess eget agentutvecklingskit också skulle stödja MCP — ett steg som Google parade med sitt eget kompletterande protokoll, Agent2Agent, avsett att låta oberoende agenter samordna sig med varandra snarare än bara med verktyg. I maj 2025 hade Microsoft fört in inbyggt MCP-stöd i Windows 11 genom det som kallas Windows AI Foundry, och stödet landade också i GitHub Copilot och Copilot Studio.
Inget av de fyra företagen är överens om särskilt mycket när det gäller modellarkitektur, prissättning eller plattformsstrategi. Alla fyra skeppar nu produkter som talar samma protokoll för att koppla en agent till ett verktyg. Det är sällsynt nog i den här branschen för att vara den egentliga historien — mer än någon enskild funktion som MCP möjliggör.
Varför det här är en förtroendefråga, inte bara rördragning
Den samstämmigheten är genuint användbar, och det är också exakt därför MCP förtjänar granskning i stället för blint förtroende. Ett protokoll som gör det trivialt för en agent att ansluta till företagets system är ett protokoll som gör det trivialt för en dåligt byggd eller dåligt konfigurerad anslutning att nå samma system. MCP i sig hindrar inte det. Specifikationen definierar hur en klient och en server pratar med varandra — den säger ingenting om vem som får bevilja en anslutning, vad den anslutningen får röra, eller om någon kommer att märka om något går fel. De valen ligger helt hos den som byggde eller konfigurerade den konkreta servern eller klienten framför dig. En del leverantörer bygger allt det med omsorg. En del bygger det inte alls, och protokollet kommer inte att stoppa dem.
MCP är ett trådprotokoll, inte ett system för åtkomstkontroll. Det standardiserar hur en agent ber ett verktyg att göra något. Om den begäran är avgränsad, loggad och återkallelig är ett beslut som någon fattade — eller inte fattade — ovanpå det.
En checklista innan du kopplar en
Innan teamet kopplar en MCP-server — vare sig det är en leverantörs produkt, ett verktyg med öppen källkod som någon hittade på GitHub, eller något som byggts internt — skiljer sex frågor en styrd anslutning från en öppen dörr. Ingen av dem kräver att du läser specifikationen. De kräver bara att någon frågar innan hen klickar på godkänn, och faktiskt läser svaret som anslutningsskärmen ger tillbaka.
| Fråga det här | Så ser bra ut | Håll utkik efter |
|---|---|---|
| Vilka scope eller verktyg begär den? | Specificerad En namngiven, konkret lista du kan läsa innan du godkänner — "skapa uppgifter, läs meddelanden i den här kanalen." | Generell "Full kontotillgång" utan en specificerad lista över vad den faktiskt kan göra. |
| Är den skrivskyddad, eller kan den skriva och agera? | Separerad Läsåtkomst som standard; varje handling som ändrar data behöver ett eget synligt medgivande. | Buntad Skrivåtkomst ingår automatiskt, utan sätt att se vilken förmåga som gör vad. |
| Är den per person eller delad i hela teamet? | Per person Varje person loggar in med sin egen inloggning; agenten ser bara det den personen kan se. | Delad En API-nyckel eller ett tjänstekonto som hela teamet använder, och som går förbi individuella behörigheter. |
| Finns det en granskningslogg över vad den gjorde? | Loggad Varje verktygsanrop registreras — vem som kopplade den, vad den rörde och när. | Ologgad Ingen post utöver det som AI-verktyget själv väljer att berätta hände. |
| Kan den återkallas omedelbart? | Omedelbar En omkopplare, med verkan direkt, från en inställningssida du styr. | Fördröjd Återkallelse kräver ett supportärende, ett samtal med leverantören, eller är inte möjlig alls. |
| Bryter en återkallelse något annat? | Isolerad Avgränsad till just den anslutningen; att stänga av den påverkar bara den. | Hoptrasslad Delar en autentiseringsuppgift med andra verktyg, så att återkallelse av ett i tysthet bryter tre andra. |
Så ser en välbyggd anslutning faktiskt ut
FabricLoops egen MCP-uppsättning är ett konkret svar på den checklistan — inte för att den är ovanlig, utan för att varje del motsvarar en av de sex frågorna ovan, och det är värt att namnge den faktiska mekaniken i stället för marknadsföringsversionen. FabricLoop kör båda rollerna samtidigt: det är en MCP-server som externa verktyg ansluter till, så att Cursor, Claude eller ChatGPT kan skapa en uppgift, lägga till en kommentar eller läsa en anteckning med en viss persons egna FabricLoop-behörigheter — och det är en MCP-klient som ansluter utåt, så att en kanal kan hämta in en leverantörs MCP-app, som GitHub eller Linear, och @omnämna den som en teamkamrat.
Varje anslutning, i båda riktningarna, börjar med en person, inte med en arbetsyta. Att koppla en extern klient som Cursor öppnar en OAuth-samtyckesskärm på app.fabricloop.com/oauth/consent, där personen väljer en arbetsyta och godkänner de specifika verktyg klienten ber om — klienten kan sedan bara agera med de scope som beviljats på den skärmen, under just den personens behörigheter, aldrig via ett delat tjänstekonto. Den omvända riktningen fungerar på samma sätt: en administratör kan aktivera en leverantörs MCP-app för hela teamet, men varje person slutför ändå sin egen inloggning innan den fungerar för hen, och en administratör kan sätta appen i skrivskyddat läge eller begränsa den till en tillåtelselista med specifika verktyg i stället för allt leverantören exponerar.
Varje ansluten klient syns på en inställningsskärm bredvid en Återkalla-kontroll som kopplar bort den omedelbart — på personens egen sida, inte i ett supportärende. På Enterprise-planer hamnar den aktiviteten — inklusive MCP-beviljanden och vad en ansluten agent faktiskt gjorde — i en granskningslogg som ett säkerhetsteam kan gå igenom på begäran, i stället för skärmdumpar som dras ur en chattråd i efterhand.
Inget av det är exotisk ingenjörskonst. Det är en liten, medvetet oglamorös uppsättning beslut, upprepade konsekvent: avgränsa, knyt till en person, logga, gör det återkalleligt utan sidoverkan. Det är samma argument som den här sajten för mer allmänt om Läsbarhet — åtkomst du kan namnge, logga och återkalla slår åtkomst som ingen behöver tänka på — och MCP levererar det bara när någon bygger det så. Protokollet gör rördragningen till standard. Det gör inte styrningen automatisk.
Beslutet som faktiskt spelar roll
MCP försvinner inte, och att invända mot det i det här läget påminner lite om att invända mot USB. Varje stor modellleverantör skeppar det nu, listan över tillgängliga servrar fortsätter att växa, och en agent som inte når dina verktyg är, för det mesta verkliga arbetet, en agent som inte kan göra särskilt mycket. Det intressanta beslutet är inte om du låter ett AI-verktyg ansluta till dina system — i allt högre grad fattas någon version av det beslutet redan åt dig, en integration i taget, när verktyg som teamet redan använder tyst lägger till MCP-stöd under en funktion du klickade in i utan att läsa det finstilta. Beslutet som fortfarande faktiskt är ditt är vad du kontrollerar innan du klickar på godkänn.
MCP standardiserade hur en AI-agent ber ett verktyg att göra något. Det gjorde ingenting för att standardisera om den begäran är säker att bevilja — den delen är fortfarande, och förblir, ett beslut för personen som klickar på "godkänn".