MCP förklarat: Så fungerar Model Context Protocol

LLM:er har kunnat anropa verktyg ett tag, men Model Context Protocol (MCP) ger ett strukturerat och standardiserat sätt att göra det.

Ändå finns det fortfarande förvirring kring vad MCP faktiskt är.

Många antar att MCP är en app, ett API eller något verktyg, men det är inget av detta. Det är ett protokoll, och det betyder något mycket specifikt.

Låt oss gå igenom det.

Om du bara vill se vad MCP möjliggör i praktiken kan du titta på den här korta videon:

Vad är ett protokoll?

Ett protokoll är helt enkelt en uppsättning regler som definierar hur två eller flera system kommunicerar med varandra.

Det gör ingenting av sig självt. Det definierar bara strukturen och förväntningarna för ett samtal mellan två entiteter. Tänk på det som ett gemensamt språk med strikta grammatiska regler som datorer följer för att utbyta information.

Postsystem gör något liknande. Alla postkontor i ett visst land följer ett standardiserat adressformat för att skicka brev.

Eller tänk på det som USB-C för AI-verktyg. För tjugo år sedan var marknaden full av olika typer av laddnings- och datakablar. På samma sätt har AI-ekosystem haft flera sätt att skicka verktyg till språkmodeller. Ramverk som LangChain, Haystack och Pydantic AI definierade alla egna format för att integrera verktyg, vilket innebar att om en utvecklare ville skriva en uppsättning verktyg för Google Maps behövde de göra det för varje specifik teknik.

För att göra detta mer konkret tittar vi på det mest populära protokollet, HTTP (Hypertext Transfer Protocol), som driver webbplatser. HTTP definierar bland annat hur en webbläsare (klient) begär en webbsida från en webbserver och hur servern ska svara.

Här är ett exempel på en HTTP-begäran och ett HTTP-svar:

1. Webbläsaren gör en HTTP-begäran

När du skriver https://example.com i webbläsaren skickar webbläsaren en strukturerad HTTP-begäran till webbservern:

Här är HTTP-parametrarna och värdena som används i vårt exempel:

"GET" – Detta är åtgärden (begär en webbsida).
"/index.html" – Den specifika webbsidan som begärs.
"HTTP/1.1" – Versionen av protokollet som används.
"Host: example.com" – Webbplatsens domännamn.
"User-Agent: Mozilla/5.0" – Information om webbläsaren som gör begäran.

Webbservern vet hur den ska tolka begäran eftersom HTTP standardiserar detta format. Den förstår detta “språk.”

2. Servern svarar med HTTP-protokollet

Servern behandlar begäran och skickar tillbaka ett strukturerat HTTP-svar:

"HTTP/1.1 200 OK" – Svarskoden (200 betyder att det lyckades).
"Content-Type: text/html" – Typen av innehåll som skickas tillbaka.
"Content-Length: 512" – Svarets storlek.
HTML Content – Det faktiska innehållet på webbsidan (det finns bara en rubrik, "Välkommen till Example.com")

Viktigt: HTTP i sig lagrar inte webbsidor och visar dem inte. Det definierar bara reglerna för hur webbläsare och webbservrar får kommunicera. Alla system som följer dessa regler kan kommunicera över det HTTP-definierade internet.

Hur MCP fungerar som protokoll

Nu tillämpar vi samma tänkande på MCP (Model Context Protocol).

MCP är ett protokoll som AI-agenter använder för att prata med externa verktyg och datakällor. Precis som HTTP lagrar det inte data och utför inte uppgifter själv. Det definierar helt enkelt ett standardiserat sätt för AI att begära och hämta information från verktyg.

Vad är då dessa “verktyg”?

I LLM-sammanhang är verktyg externa system, API:er eller tjänster som AI kan interagera med för att utöka sina förmågor bortom ren textgenerering. De låter AI-agenter hämta realtidsdata, boka möten eller skicka meddelanden till dina vänner, vilket gör dem mycket mer användbara för verkliga behov.

Anta att du frågar en AI-agent:

“Vad är klockan i London just nu?”

Eftersom AI:n själv inte vet rätt svar, eftersom AI-modeller har ett brytdatum för kunskap (oktober 2023 för OpenAI:s modeller), behöver den hämta live-data från en tidstjänst. Men i stället för att använda HTTP för att begära en webbsida använder AI:n MCP för att begära tidsdata.

Det här händer:

1. AI-agenten gör en MCP-begäran till tidstjänsten (exempel)

"method": "tools.call" → AI:n anropar ett externt verktyg.
"tool": "get_time" → Namnet på verktyget den vill använda.
"args": { "location": "London" } → De specifika indataparametrarna.

Precis som i HTTP följer denna begäran ett strikt format så att alla MCP-kompatibla verktyg vet exakt hur den ska tolkas.

2. MCP-tidsservern svarar

Det externa verktyget (tidsservern) följer MCP:s svarsregler och skickar tillbaka:

"status": "success" → Bekräftar att begäran behandlades korrekt.
"result" → Innehåller den faktiska tidsdatan.

Nu kan AI-agenten ta dessa data och formulera ett faktiskt svar till användaren:

“Aktuell tid i London är 12:20 PM (GMT).”

För att sammanfatta och reda ut förvirringen:

“MCP är en app.” → Nej, MCP är en uppsättning regler. Du behöver AI-programvara och verktyg som implementerar MCP för att faktiskt använda det, precis som Instagram-appen behöver levande Instagram-servrar för att svara på HTTP-begäranden och leverera data.

“MCP är en databas.” → Nej, MCP lagrar inte data. Det hjälper AI-agenter att prata med databaser eller API:er.

“MCP är som ett API.” → Inte exakt. Ett API är ett specifikt sätt att interagera med ett system, medan ett protokoll (som MCP eller HTTP) definierar ett universellt sätt som många olika system kan kommunicera på. MCP är ett språk som ett AI-system kan använda för att interagera med många faktiska API:er (tid, databaser, Stripe, Slack och så vidare).

Varför MCP är intressant

Nu när vi vet att MCP är ett standardiserat sätt för AI-programvara att interagera med externa verktyg och appar, och att MCP inte är ett API, kan vi förstå varför AI-utvecklarcommunityn (inklusive vi) blev intresserad av det.

Eftersom MCP inte är ett API utan snarare gör det möjligt för AI-appar att interagera med faktiska API:er i stor skala, hjälper det projekt som behöver ansluta till många externa system att komma igång snabbare. Verktyg ger också en modell räckvidd, och det som hände i OpenAI Hugging Face-incidenten visar hur den räckvidden ser ut när den överskrider uppgiften. För att göra detta behövde utvecklare ibland gå igenom en fullständig utvecklingscykel för API-integration, men i dag använder de vanligtvis befintliga bibliotek eller open source-projekt (till exempel tillgängliga på GitHub) som ger den funktionalitet som behövs.

Att använda dessa bibliotek påskyndar utvecklingen, men att integrera dem korrekt med ditt system (om det inte är kompatibelt med implementationen du hittade på GitHub) kräver fortfarande arbete för att få verktyget att fungera med AI:n.

Med MCP kan det, när ramverket väl är på plats, räcka med några rader kod för att lägga till en ny integration (till exempel en integration med Google Drive) genom att ansluta till Google Drive MCP-servern. Du stöter inte på kompatibilitetsproblem eftersom båda använder samma protokoll: MCP.

Låt oss jämföra båda angreppssätten för att se skillnaderna tydligare.

Standardintegration jämfört med att använda Model Context Protocol (MCP)

För att göra jämförelsen konkret går vi igenom hur man lägger till åtkomst till Google Drive-filer för en AI Agent, först manuellt och sedan med ett MCP-kompatibelt verktyg.

Standardintegration

1. Hitta och anpassa ett bibliotek: Du söker efter en Google Drive API-klient eller ett open source-projekt. Google tillhandahåller klientbibliotek (t.ex. Google Drive API for Python), du inkluderar detta i ditt projekt. Du måste fortfarande säkerställa att det fungerar med din AI:s miljö.

2. Implementera logiken: Du skriver funktioner för att till exempel söka efter filer eller hämta ett dokument från Drive. När AI:n behöver något måste den anropa dessa funktioner. Du formaterar AI:ns begäran till Google Drive-specifika API-anrop. Efter att ha fått ett svar från Google extraherar du innehållet för att skicka tillbaka det till AI:ns kontext.

3. Hantera fel och specialfall: Lägg till kod för att hantera fall som “filen hittades inte”, behörighetsfel eller API-hastighetsgränser. Om Googles API returnerar ett fel fångar du det och kanske svarar med ett ursäktande meddelande eller ber AI:n formulera om sig. Du behöver också skydda mot att din AI skickar för många begäranden för snabbt.

4. Underhåll: Med tiden, om Google uppdaterar sitt API eller biblioteket, måste du uppdatera din kod. Om du hittar ett fel i biblioteket kan du behöva patcha det eller hitta en annan källa. I praktiken blir du underhållare av denna Google Drive-integration i din AI-applikation.

Den här processen gäller även andra verktyg: vill du lägga till Slack eller en databas i din AI? Du behöver upprepa hela processen för varje verktyg.

MCP-integration

Nu ser vi hur den processen skulle se ut med MCP.

Först definierar vi nyckelbegreppen:

Client – en AI-applikation (ChatGPT, Claude app, Quickchat AI) som upprättar en anslutning till en eller flera servrar och begär information eller åtgärder för att utföra uppgifter som en användare har efterfrågat.

Server – Varje server kan ansluta till något som en databas eller ett API (Google Drive) och definiera en uppsättning “verktyg” eller data som den kan tillhandahålla. I det här fallet är servern ett program som exponerar dessa verktyg och funktioner för Client (AI-appen).

Utvecklare, beroende på vad de vill göra, kan välja vilken sida de vill vara på: bygga en server som exponerar data eller bygga en AI-klient som kan prata med vilka servrar som helst. De flesta vill ha det andra alternativet, men vi börjar ändå med serversidan för att förstå hur MCP fungerar steg för steg:

• Initiera en MCP-server. En utvecklare eller systemadministratör sätter upp en MCP-server för ett visst verktyg eller en viss datakälla. En MCP-server är vanligtvis bara ett litet program som implementerar MCP-specifikationen. Det finns till exempel en färdigbyggd Google Drive MCP-server tillgänglig som vet hur man söker efter och hämtar dokument.

  När du initierar servern ger du den åtkomst till målsystemet (Google Drive). Servern exponerar sedan en uppsättning verktyg som motsvarar åtgärder eller frågor den kan hantera. Den är i praktiken en API-adapter som talar MCP på ena sidan och den ursprungliga tjänsten på den andra sidan.

  När servern körs väntar den på begäranden.

• Ansluta en LLM (client) till en MCP-server. Därefter behöver AI-applikationen (“client”-sidan) ansluta till servern. I praktiken, om du använder en AI-plattform som stöder MCP (till exempel Claude Desktop), konfigurerar du den med adressen eller kommandot för att starta servern. När den är ansluten upprättar klienten en session med servern enligt MCP:s handskakning. Om du använder Claudes gränssnitt ser du att Claude är “connected” till vissa MCP-servrar (gränssnittet kan visa tillgängliga anslutningar).

Så ser det ut i Claude UI

• Upptäcka tillgängliga verktyg. När anslutningen är upprättad är det första steget att ta reda på vad servern erbjuder (ibland sker det automatiskt efter att du ansluter till servern). MCP-klienten skickar en tools/list-begäran till servern (detta definieras i protokollet). Servern svarar med en lista över sina tillgängliga verktyg, där varje verktyg har detaljer som namn, beskrivning och indataschema.

  En server kan till exempel svara att den har verktygen create_file(path, content), read_file(path) och search_files(query) tillgängliga. Klienten gör sedan denna information tillgänglig för LLM:en. I många implementationer formaterar klienten dessa verktygsbeskrivningar och inkluderar dem i modellens kontext (till exempel genom att lägga till i systemprompten: “Du har åtkomst till följande verktyg… [verktygslista]”).

Här är en AI-systemprompt tillsammans med användarens meddelande som efterfrågar aktuell tid

Med MCP-verktyg implementerade integreras ett verktyg som heter “get_current_time”, vilket gör att AI:n kan få åtkomst till en extern resurs och hämta exakt tid i London

Det betyder att du inte behöver tänka ut och programmera in alla potentiella åtgärder som din AI-app kan behöva för att slutföra en uppgift. Med MCP kan AI:n upptäcka alla möjliga åtgärder i stunden genom att fråga en MCP-server och välja det som behövs.

• Använda ett verktyg via MCP. När AI:n behöver utföra en åtgärd eller hämta data anropar den ett verktyg via MCP. Ur AI:ns perspektiv (särskilt för modeller som Claude som har inbyggt stöd för verktygsanvändning) avgör den i sin resonering: “Jag bör anropa verktyg X med dessa parametrar.” MCP-klienten fångar den intentionen och skickar en tools/call-begäran i MCP-format till rätt server (Google Drive MCP-servern).

• MCP-servern fungerar som en brygga. Den tar emot en strukturerad MCP-kompatibel begäran från AI-agenten, mappar den till rätt Google Drive API-endpoint, skriver om begäran till ett faktiskt Google Drive API-anrop, kör begäran, bearbetar svaret och omformaterar det till ett MCP-kompatibelt svar igen innan det skickas tillbaka till AI-agenten.

  Det är värt att notera att MCP-servrar följer ett strukturerat angreppssätt för felhantering, vilket säkerställer att AI Agents kan tolka och agera på fel effektivt.

  Anta att en AI Agent använder ett MCP-verktyg för att hitta en fil i Google Drive. Om begäran innehåller ett ogiltigt fil-ID (t.ex. en sträng med fem tecken i stället för det förväntade formatet) returnerar MCP-servern ett felmeddelande:

  I stället för att bara misslyckas kan AI Agent ta detta strukturerade svar och formulera om det till användarvänlig återkoppling:

  “Det verkar som att fil-ID:t du angav är för kort. Fil-ID:n i Google Drive är vanligtvis 28 tecken långa. Kan du kontrollera det och försöka igen?”

  Detta angreppssätt säkerställer att fel inte leder till återvändsgränder, utan i stället blir möjligheter för AI Agent att vägleda användaren mot en lyckad lösning.

• Svara på användarens fråga/begäran. När MCP-servern returnerar ett resultat skickar MCP-klienten dessa data tillbaka till AI-appen. Modellen införlivar sedan resultatet i sin resonering eller direkt i den utdata den genererar för användaren.

  Om användaren begär att en ny Google Sheets-fil ska skapas matas serverns svar (som innehåller fil-ID:t och en genererad länk) in i modellen. Modellen svarar sedan användaren med: “Klart. Din nya Google Sheets-fil är färdig. Du kan komma åt den här: [länk].”

Under hela processen behåller AI:n kontrollen över flödet: den avgör när ett verktyg ska anropas och hur resultatet ska användas när svaret formas. Samtidigt behöver utvecklaren inte orkestrera dessa steg manuellt, MCP-ramverket och AI-modellen hanterar det. Slutresultatet är att användaren kan be AI:n om komplexa frågor eller uppgifter som kräver extern information eller externa åtgärder, och AI:n kan utföra dem autonomt via MCP och ge tillbaka ett resultat.

Fördelar med att använda MCP

Notera hur detta angreppssätt abstraherar bort många detaljer: klienten hanterade inte API-nycklar eller HTTP-statuskoder, de hanteras av MCP-servern.

Huvudpoängen är enkelheten vid integrationspunkten: vi “ber” om kunder och får dem. Logiken för hur de hämtas är inkapslad någon annanstans. Det betyder att en utvecklare som arbetar på AI-sidan inte behöver skriva nya HTTP-anrop för varje ny åtgärd, utan bara anropar verktyg med namn. Det tunga arbetet (autentisering, anrop till Google Drives endpoints, formatering av svaret) görs i MCP-serverns kod, som är återanvändbar och standardiserad.

Här är en sammanfattning av de viktigaste fördelarna:

• Minskar API-specifik limkod. Före MCP krävdes vanligtvis en mängd “limkod” för att få en AI att använda en extern tjänst: anropa API:et, omvandla svaret till text som modellen kan hantera, sedan tolka modellens utdata för att eventuellt anropa ett annat API, och så vidare. Med MCP elimineras mycket av detta lim. Modellens klient och servern hanterar datautbyte på ett strukturerat sätt, så du behöver inte manuellt omvandla andra format (som JSON) till text eller tvärtom, protokollet gör det. Du behöver inte heller skriva logik för att avgöra när något ska anropas. AI:n (vägledd av verktygsbeskrivningarna och sin egen resonering eller prompt) gör det.

• Återanvändbara, delade anslutningar i stället för engångs-API-wrappers. Med MCP skriver du en integration en gång och kan återanvända den i många projekt och AI-system. Du kan till exempel skapa en MCP-server för företagets interna wiki. Alla AI-appar som stöder MCP kan ansluta till denna enda server för att fråga wikin. Du behöver inte implementera om “wiki-sökning” för varje ny AI-chatbot eller varje annan LLM-leverantör. Denna återanvändbarhet är ett skifte från tidigare, då varje team kunde skriva sin egen något annorlunda integration för samma API. MCP uppmuntrar ett bibliotek av anslutningar som kan delas och förbättras gemensamt.

• Plug-and-play-integration med olika LLM:er. MCP är modellagnostiskt. Protokollet bryr sig inte om klienten är Claude, GPT-4, DeepSeek eller någon framtida modell, så länge klienten kan hantera MCP-gränssnittet. Om du i framtiden vill byta till en annan modell kan du göra det utan att skriva om alla dina integrationer.

• Enklare underhåll. Eftersom det är en öppen standard finns det en växande community som bidrar med färdigbyggda servrar (för databaser, populära API:er och så vidare) som du kan använda i stället för att bygga från grunden. När du integrerar fler system hjälper MCP till att undvika “spagetti” av många punkt-till-punkt-integrationer. Och du behöver inte övervaka alla API-uppdateringar från andra leverantörer.

Blir API-integrationer föråldrade?

Både traditionella API-integrationer och MCP har sin plats. Det bästa angreppssättet kan bero på projektets karaktär, teamets kompetens och långsiktiga mål.

Om du bara behöver integrera med en eller två externa tjänster och interaktionerna är relativt enkla är en direkt API-integration ofta den snabbaste lösningen. Om din webbapp bara behöver verifiera en Stripe-betalningstoken i kassan är det enkelt och effektivt att anropa Stripes API direkt. Att införa MCP i det scenariot kan vara överdrivet. Du kan ansluta en AI Agent till vilket dokumenterat REST API som helst med en granskad HTTP Action, eller använda en integration med ett klick, till exempel Google Sheets för att logga leads och demoförfrågningar, utan att köra en MCP-server.

I fall där du behöver mycket strikt kontroll över begäran/svar (för prestandajustering, särskild datahantering eller proprietära protokoll) kan det vara bättre att skriva direkt mot API:et. Traditionella integrationer låter dig använda alla avancerade funktioner i ett API och skräddarsy anropen exakt. Om ett API har ovanliga krav eller om du vill undvika abstraktionslager för maximal tydlighet och kontroll är traditionell integration lämplig.

För ett konkret exempel på hur MCP-verktyg exponeras för en produktionssatt AI Agent tillsammans med anpassade API-åtgärder kan du se hur Quickchat AI Agents kombinerar båda angreppssätten. Den djupare diskussionen om när du ska använda MCP, enskilda AI Actions eller “Generate from Text” finns i API:er för AI Agents: från MCP till anpassade endpoints. För att prova själv följer du steg-för-steg-guiden för att ansluta din AI Agent till en fjärrbaserad MCP-server så att den anropar ett live-verktyg mitt i en konversation.

Lista över tillgängliga MCP-servrar

Om du vill komma igång med MCP kan du titta på katalogerna över MCP-servrar nedan:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Du kan också köra en utan att skriva någon kod: varje Quickchat AI Agent kan göras om till en MCP-server med en hostad URL som Claude, ChatGPT och Cursor anropar som ett verktyg. Anslutningen fungerar också åt andra hållet: en Quickchat AI Agent kan anropa en leverantörs hostade MCP-server som sina verktyg, vilket är hur AI-schemaläggningsassistenten byggd på Calendlys MCP-server kontrollerar faktisk tillgänglighet och bokar möten från en chatt, och hur en Notion AI-chatbot svarar från ett live-hjälpcenter och loggar supportärenden tillbaka till en Notion-databas.

Quickchat AI kör också en fjärrbaserad MCP-server för ditt eget konto. Anslut den till ChatGPT, Claude, Cursor eller Codex så kan du hantera dina AI Agents därifrån: analys, konversationstranskriptioner, uppdateringar av kunskapsbasen och skapande av nya Agents, bakom en enda OAuth-inloggning. Genomgången av konfigurationen för varje klient finns i Hantera din AI Agent från ChatGPT, Claude och Codex med MCP.

FAQ

Fungerar det bara med Claude?

MCP är modellagnostiskt. Protokollet bryr sig inte om klienten är Claude, GPT-4, en lokal LLaMA-variant eller någon framtida modell, så länge klienten kan hantera MCP-gränssnittet. Det betyder att du inte låser dig till en enda AI-leverantör när du bygger dina verktygsintegrationer.

Hur skiljer sig MCP från att bara ge modellen all information den behöver från början? Varför inte fylla prompten med data i stället?

MCP skiljer sig i grunden från att fylla modellens prompt med data eftersom det låter modellen hämta information dynamiskt när det behövs, i stället för att arbeta med en statisk, förinläst prompt. Att stoppa in text i prompten stöter på begränsningar, eftersom AI-modeller har ett fast kontextfönster. Det innebär att för mycket data kan leda till att viktiga detaljer går förlorade, att svaren blir långsammare och att API-kostnaderna ökar (på grund av per-token-prissättningsmodeller som används av LLM-leverantörer). Det ger också bara kunskap vid en enskild tidpunkt, medan MCP möjliggör realtidsåtkomst till levande externa data och låter AI:n vidta åtgärder, inte bara läsa information. En AI med en fullpackad prompt kan känna till kunduppgifter, men kan inte uppdatera poster eller behandla transaktioner.

Vad händer om vi ansluter dussintals verktyg till AI:n? Blir inte modellen överbelastad eller riskerar att använda dem fel?

Det beror på implementationen, men det är sant att dagens LLM:er har begränsningar i hur väl de skiljer mellan och väljer bland många alternativ. Om du presenterar en modell för till exempel 50 möjliga verktyg finns det en risk att den väljer fel. MCP-angreppssättet i sig tvingar dig inte att läsa in allt på en gång. Du bör ansluta relevanta verktyg baserat på kontexten. En bästa praxis är att bara ansluta de verktyg som behövs för den aktuella uppgiften/domänen och använda multiagent-samarbete, en typ av verktygsroutning eller en agent som först avgör vilken delmängd av verktyg som ska övervägas.

MCP jämfört med Function Calling

Traditionell function calling (som i OpenAI:s API eller andra LLM:er) låter en utvecklare definiera en uppsättning funktioner, ge deras definitioner till modellen och låta modellen “anropa” dem med namn och argument. Detta var ett stort steg för AI-integration, men det har begränsningar. En stor skillnad är när och hur verktyg definieras. I klassisk function calling måste alla möjliga funktioner deklareras i förväg (vid designtillfället) i prompten eller via API:et. Modellen kan bara anropa dessa fasta funktioner. I MCP kan verktyg upptäckas vid körning, AI:n kan fråga vad som finns tillgängligt och till och med få nya verktyg mitt under en session.

MCP jämfört med GPT Actions och Plugins

GPT Actions/Plugins syftar på OpenAI:s ekosystem där du kunde aktivera plugins (som en webbläsare eller en PDF-läsare) för ChatGPT, eller “GPTs” (anpassade ChatGPT-agenter) som kan använda verktyg. Dessa var intressanta, men de krävde anpassad utveckling för varje plugin och var begränsade till OpenAI:s plattformar. Om du ville ha en ChatGPT-plugin för en uppgift behövde du skapa ett API och ett manifest, och gå igenom OpenAI:s godkännande eller åtminstone aktivera den manuellt. Varje plugin var i praktiken en silo, en väderplugin, en reseplugin och så vidare, var och en med egna endpoints och egen logik. MCP förbättrar detta koncept genom att samordna det och öppna upp det.

MCP jämfört med RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) är en teknik där en LLM kompletteras med en extern kunskapsbas. Vanligtvis omfattar RAG en vektordatabas eller ett sökindex: användarens fråga används för att hämta relevanta dokument eller data (med semantisk sökning eller andra metoder), och dessa dokument ges till modellen som ytterligare kontext att “läsa” när den formulerar ett svar. RAG handlar om att ge modellen kunskap som den inte ursprungligen hade, särskilt användbart för faktabaserad QA eller domänspecifik information. Men RAG är skrivskyddat, modellen hämtar textpassager men utför inga åtgärder utöver hämtning.

MCP handlar däremot om att vidta åtgärder eller utföra godtyckliga operationer, inte bara hämta informationskontext. Med MCP kan en AI göra saker: skriva till en databas, skicka ett e-postmeddelande, köra kod och så vidare. Det är inte begränsat till att hämta kunskap, utan kan utlösa ändringar i externa system. Därför tjänar RAG och MCP på många sätt olika syften.