En djupdykning i MCP:er, del 1: Vad är egentligen MCP?
Om du följer AI har du säkert hört talas om Model Context Protocol (MCP). Sedan Anthropic tillkännagav denna nya standard i november 2024 har dess popularitet exploderat. Det finns MCP:er för att skicka e-post, MCP:er för att söka på webben och MCP:er som kör andra MCP:er. MCP:er låter ödmjuka LLM:er göra pull-förfrågningar och flygbokningar. I maj tillkännagav Microsoft till och med ett MCP-register för Windows som gör det möjligt för appar att exponera funktionalitet för AI-agenter.
Fantastiskt! Men hur? Vad är MCP? Hur använder man den? Varför har det blivit så mycket mer populärt än tidigare försök? Hur gör det möjligt för chatbots att utföra uppgifter i den verkliga världen? Och hur kan du bygga en egen?
När vi beslutade att bygga vår egen MCP-server för DeepL API, kändes det skrämmande. Men när du väl förstår hur MCP:er fungerar, hur MCP:er låter agenter upptäcka och använda verktyg, och hur du kan bygga en grundläggande MCP-server med 10 rader kod, är det inte så skrämmande. I denna serie inlägg kommer vi att försöka förklara detta ämne. Vi kommer att undersöka:
- vad MCP är
- hur man använder MCP i en AI-klient
- hur man bygger en MCP-server
Kom igen!
Vad betyder MCP?
MCP står för ModelContextProtocol.
”Modellen”är en AI-modell. Det kan vara vilken typ av AI-yta som helst, men vanligtvis är den byggd på en LLM. Här kommer vi att referera till detta som en AI-agent eller en AI-assistent.
”Kontext”avser den kontext inom vilken AI-agenten verkar. Inom AI talar vi ofta om ett ”kontextfönster”, vilket avser all kontext som en LLM införlivar när den genererar sitt svar på en prompt – konversationshistoriken, systemprompten och mer. För att MCP ska fungera ger en AI-yta den underliggande LLM en ytterligare uppmaning som specificerar vilka verktyg den kan använda och hur de ska användas.
”Protokoll”är en uppsättning regler som beskriver hur två enheter kommunicerar över ett nätverk. Ett protokoll som du använder varje dag är HTTP – HyperText Transfer Protocol – som styr hur en webbserver och en webbklient kommunicerar.
Sammanfattning: ”Model Context Protocol” är ett protokoll som tillhandahåller den kontext som gör det möjligt för AI-modeller att använda externa verktyg och resurser.
MCP är en öppen standard som har utvecklats av två ingenjörer från Anthropic. Den använder JSON-RPC, ett populärt protokoll för att definiera funktionsanrop. Och det är inspirerat av Språk Server Protocol, som Microsoft skapade för att separera logiken bakom hanteringen av kodningsspråk från IDE:er.
MCP är inte en mjukvara, en app eller ett API. Men det ger AI-agenter tillgång till alla dessa!
Vad gör MCP?
LLM kan ge intelligenta och användbara svar på användarinspelningar. Men de har ingen tillgång till externa tjänster, ingen möjlighet att kommunicera med annan programvara och inga möjligheter att hämta aktuell information. MCP ger alla AI-ytor möjlighet att skicka förfrågningar till valfri programvarutjänst och få svar. Det ger en AI-agent ett standardverktyg för att få tillgång till externa verktyg, resurser och data.
Utan MCP är en AI-klient bara en hjärna utan kropp, utan möjlighet att nå omvärlden. Med MCP kan en AI-klient vara en agent!
Vem kan använda MCP?
Eftersom MCP är en öppen standard kan vem som helst implementera en MCP-klient eller en MCP-server.
Klient kan vara vilken app som helst som baseras på en LLM. Du kan använda MCP:er i applikationer som Claude Desktop, VSCode, Windsurf och Cursor. Eller så kan du använda MCP:er med en AI-agent som du har byggt med ett ramverk som LangChain eller CrewAI.
Varför har MCP blivit så populärt?
En anledning är att det är en öppen standard. Alla AI-agenter kan implementera MCP, liksom alla verktyg. Detta gör den mer attraktiv än lösningar för ett specifikt företags produkt, såsom OpenAI:s Funktionsanrop.
När de skapade denna universella lösning inspirerades MCP:s skapare av Language Server Protocol (LSP). Innan LSP, när en IDE ville implementera funktioner som autofullständning eller syntaxmarkering för ett visst språk, behövde den skapa sin egen integration. Resultatet blev vad skaparna nyligen kallade ett m × n-problem, där man behövde implementera språks tjänster separat för varje möjlig IDE/språkkombination. Med LSP behöver varje språk endast ett integrationsbibliotek. Och en IDE som stöder LSP kan stödja vilket språk som helst. På samma sätt kan alla AI-klienter som är till support av MCP använda den när en tjänst har implementerat en MCP-server. Klient behöver endast till support MCP.
MCP är flexibelt även på andra sätt. Den kan köras lokalt eller över ett nätverk. Och det kommer från Anthropic, som är väl respekterat och som skulle dela fördelarna med en öppen standard.
Varför behöver AI-agenter ett standardprotokoll?
Eftersom LLM är så bra på att förstå och tillämpa information, kan de inte redan använda alla mjukvarutjänster vars beskrivning ingår i deras träningsdata? LLM:er förstår ju redan hur man använder många populära API:er, vilket du kommer att upptäcka om du ber en kodningsassistent som Copilot eller Sourcegraph om hjälp.
Men om man gav en LLM tillgång till alla API:er i dess träningsdata skulle det uppstå kaos. Hur skulle den veta vilka API:er den ska anropa och när? Hur skulle den få tag på din API-nyckel och dina inloggningsuppgifter, och hur skulle den använda tjänster som kräver andra typer av åtkomst? Vad händer om du vill veta körsträckan från Kansas City till Des Moines – eller den aktuella temperaturen i Bangkok? Det finns många sätt att hitta denna information. Som användare vill du ha kontroll över de åtgärder som din LLM väljer. Detta gäller särskilt när det inte handlar om att hämta information, utan om att vidta åtgärder som påverkar omvärlden, som att skicka ett e-postmeddelande eller beställa pizza åt dig.
Det är sant att en agent kan läsa och förstå en låg nivå OpenAPI-specifikation, eller hela API-dokumentation, och sedan göra API-anrop i enlighet med detta. Men MCP låter verktygstillverkare definiera tjänster på högre nivå som skulle vara särskilt användbara för en AI-agent, och pekar agenten i en användbar riktning. Hittills är detta ett område där människor fortfarande utmärker sig.
Det visar sig alltså att det bästa sättet för tillfället är att uttryckligen definiera vilka verktyg och resurser LLM kan använda och hur det kan använda dem. MCP gör detta på det gamla sättet, deterministiskt – inte genom att låta LLM utföra sin magi, utan genom kod och JSON.
Men hur kan en LLM använda verktyg?
I grund och botten är en LLM en maskin som genererar tokens – tokens som människor möter i form av text, bilder, ljud och så vidare. Så hur kan en sådan maskin få tillgång till verktyg och resurser? Hur vet den att den har sådan åtkomst, och hur vet den vilken den ska använda?
Nyckeln är att, precis som Maximilian Schwarzmüller påpekar, LLM endast kan kommunicera med omvärlden med hjälp av tokens. De tar tokens som indata och producerar tokens som utdata. Och dessa tokens kan inkludera enheter som betyder "Jag vill använda ett verktyg." För att ange att den vill använda ett verktyg eller en resurs, och för att faktiskt använda ett sådant, genererar en LLM standardtoken som den omgivande programvaran känner igen som ett verktygsanrop och fångar upp. Den programvaran anropar sedan en tjänst och returnerar resultatet till LLM.
LLM skulle kunna använda specialiserade tokens här. Men vanligtvis använder den bara specifika avgränsare och språk – på så sätt kan du eftermontera denna funktion i en befintlig LLM genom att finjustera den. Du kan till exempel använda start- och slut-taggar i hakparenteser som omsluter JSON, som i detta exempel på agentutdata:
Visst! Jag kan skapa ett nytt kalkylblad åt dig. Vänta lite...
[tool-start]
{
"tool": "spreadsheets",
"action": "create"
}
[tool-end]
Det är precis vad forskarna gjorde i sin artikel om Toolformer från 2023, som visade, som titeln säger, att ”språkmodeller kan lära sig själva att använda verktyg”. I denna studie genererade författarna träningsdata som inkluderade ren textrepresentation av API-anrop och deras resultat. Genom att finjustera en LLM med dessa ytterligare data skapade de en LLM som skulle anropa dessa API:er för att generera ett lovande svar på en prompt.
De använde det enkla formatet:
[funktionens namn(data) → resultat]
Eftersom de visste att LLM har svårt för matematik tillhandahöll de till exempel ett kalkylatorverktyg. De inkluderade sedan strängar som denna i träningsdata:
Av 1 400 deltagare var 400 (eller [Kalkylator(400 / 1400) → 0,29] 29 %) klarade testet.
och
Namnet kommer från ”la tortuga”, det spanska ordet för [MT(“tortuga”) → sköldpadda] sköldpadda.
Genom att finjustera en LLM med sådan data skapade de en LLM som visste hur man anropar API:er för att generera det mest lovande svaret på en given prompt.
Men du behöver inte finjustera en LLM för att den ska kunna använda verktyg. Det visar sig att allt du behöver är en uppmaning. Denna artikel visar hur man lär en LLM att använda verktyg med JSON avgränsat av [[qwen-tool-start]] och [[qwen-tool-end]], enbart genom att ge den en lämplig prompt.
Du kan prova själv! Besök bara din favorit-chatbot och säg till den:
Grattis! Du har nu möjlighet att använda ett verktyg för att göra multiplikation. När du behöver göra en beräkning behöver du bara skriva ut följande syntax:
[Matematik]
{
"arg1": {värde},
"arg2": {värde}
}
[/Math]
där varje {värde} naturligtvis representerar ett värde som du vill multiplicera. Förstått?
Ge sedan LLM ett matematiskt problem och se hur det troget matar ut den syntax du gav det för ditt matematiska verktyg.
Moderna LLM-modeller använder fortfarande verktyg på ungefär samma sätt. Till exempel beskriver Anthropic här hur de konstruerar ett system som uppmanar Claude att använda verktyg i deras API.
Hur hanterar en LLM utdata från ett verktyg?
Hur tar en LLM emot verktygsutdata? Återigen handlar det om tokens. När AI-klienten tar emot utdata från ett verktyg matar den tillbaka det till LLM som indata, men på ett sådant sätt att LLM vet att det är verktygsutdata och inte indata från slutanvändaren.
Att sätta ihop allt
Sammanfatta, är detta vad som händer när en LLM använder ett verktyg:
- Användare i inmatning
- LLM bearbetar denna information
- När LLM genererar utdata "beslutar" den att det bästa sättet att slutföra utdatat är att anropa ett verktyg. Det innebär att den genererar en uppsättning tokens som den har tränats att känna igen och som gör att den kan anropa ett verktyg.
- AI-klienten känner igen dessa tokens som något som ska anropa ett verktyg, avlyssnar det, analyserar JSON till parametrar och allt annat i begäran och skickar detta till rätt verktyg.
- Verktyget genererar utdata, vilket kan innebära användning av ett API eller inte. Den returnerar detta till AI-klienten, som skickar det till LLM.
- LLM-processer verktygsutdata
- LLM använder denna utdata för att fortsätta skapa ett svar till användaren.
Och det var min snabba genomgång av vad MCP är och hur det implementeras i LLM. I mitt nästa inlägg visar jag hur du använder MCP:er i din egen AI-klient!
Om författaren
Som DeepL:s utvecklarevangelist arbetar Ben Morss med att hjälpa alla som vill använda DeepL:s API för att få tillgång till dess förstklassiga AI-översättningar. Tidigare arbetade han på Google som produktchef för Chrome och utvecklingsförespråkare för ett bättre webben. Innan dess var han mjukvaruutvecklare på New York Times och AOL, och en gång i tiden var han heltidsmusiker. Han har en kandidatexamen i datavetenskap från Harvard och en doktorsexamen i musik från University of California i Davis. Du kanske fortfarande kan se honom spela musik med bandet Ancient Babiesoch analysera poplåtar på Rock Theoryoch skriver en musikal som inte egentligen handlar om Steve Jobs.