Een diepgaande analyse van MCP's, deel 1: Wat is MCP eigenlijk?
Indien u AI volgt, heeft u ongetwijfeld gehoord van het Model Context Protocol (MCP). Sinds Anthropic deze nieuwe standaard in november 2024 aankondigde, is de populariteit ervan aanzienlijk toegenomen. Er zijn MCP's voor het verzenden van e-mails, MCP's voor het zoeken op internet en MCP's die andere MCP's uitvoeren. MCP's maken het mogelijk voor bescheiden LLM's om pull-verzoeken en vliegtuigreserveringen te doen. In mei kondigde Microsoft zelfs een MCP-register voor Windows aan waarmee apps de mogelijkheid biedt om functionaliteit beschikbaar te stellen aan AI-agents.
Heel erg bedankt! Maar hoe? Wat is MCP? Hoe gebruikt u het? Waarom is het aanzienlijk populairder geworden dan eerdere initiatieven? Hoe zorgt het ervoor dat chatbots taken kunnen uitvoeren in de echte wereld? En hoe kunt u er zelf een bouwen?
Toen we besloten om onze eigen MCP-server voor de DeepL API te bouwen, leek dit een uitdagende onderneming. Echter, zodra u begrijpt hoe MCP's functioneren, hoe MCP's agenten in staat stellen tools te ontdekken en te gebruiken, en hoe u een eenvoudige MCP-server kunt bouwen met slechts tien regels code, is het niet langer zo complex. In deze reeks berichten zullen wij trachten dit onderwerp te verduidelijken. Wij zullen het volgende onderzoeken:
- Wat is MCP?
- Hoe MCP te gebruiken in een AI-klant
- Hoe bouwt u een MCP-server?
Laten we vertrekken!
Wat betekent MCP?
MCP staat voor ModelContextProtocol.
Het'model'is een AI-model. Dit kan elk type AI-oppervlak zijn, maar is doorgaans gebaseerd op een LLM. Hier zullen we dit een AI-agent of een AI-assistent noemen.
"Context"verwijst naar de context waarin de AI-agent opereert. In AI hebben we het vaak over een 'contextvenster', waarmee alle context wordt bedoeld die een LLM meeneemt bij het genereren van een reactie op een prompt: de gespreksgeschiedenis, de systeemprompt en meer. Om MCP te laten functioneren, geeft een AI-oppervlak de onderliggende LLM een aanvullende prompt die aangeeft welke tools het kan gebruiken en hoe deze te gebruiken.
Een 'protocol'is een instelling van regels die beschrijven hoe twee entiteiten via een netwerk met elkaar communiceren. Een protocol dat u dagelijks gebruikt, is HTTP (HyperText Transfer Protocol), dat bepaalt hoe een webserver en een webclient met elkaar communiceren.
Samenvattend: Het 'Model Context Protocol' is een protocol dat de context biedt waarmee AI-modellen externe tools en bronnen kunnen gebruiken.
MCP is een open standaard ontwikkeld door twee ingenieurs van Anthropic. Het maakt gebruik van JSON-RPC, een populair protocol voor het definiëren van functieaanroepen. En het is geïnspireerd door Taal Server Protocol, dat door Microsoft is ontwikkeld om de logica achter het verwerken van programmeertaal los te koppelen van IDE's.
MCP is geen software, app of API. Echter, het biedt AI-agenten toegang tot al deze gegevens.
Wat doet MCP?
LLM's kunnen intelligente en nuttige reacties geven op invoer van gebruikers. Echter, zij hebben geen toegang tot externe diensten, geen mogelijkheid om te communiceren met andere software en geen middelen om actuele informatie op te halen. MCP biedt elk AI-oppervlak de mogelijkheid om verzoeken naar elke software service te verzenden en een reactie te ontvangen. Het biedt een AI-agent een standaardmethode om toegang te verkrijgen tot externe tools, bronnen en gegevens.
Zonder MCP is een AI-client slechts een brein zonder lichaam, zonder mogelijkheid om toegang te krijgen tot de buitenwereld. Met MCP kan een AI-klant als agent fungeren.
Wie kan MCP gebruiken?
Aangezien MCP een open standaard is, kan iedereen een MCP-klant of een MCP-server implementeren.
De klant kan elke app zijn die gebaseerd is op een LLM. U kunt MCP's gebruiken in apps zoals Claude Desktop, VSCode, Windsurf en Cursor. Of kunt u MCP's gebruiken met een AI-agent die u hebt gebouwd met een framework zoals LangChain of CrewAI.
Waarom is MCP zo populair geworden?
Een van de redenen is dat het een open standaard is. Elke AI-agent kan MCP implementeren, evenals elke tool. Dit maakt het aantrekkelijker dan oplossingen voor het product van een specifiek bedrijf, zoals OpenAI's Function calling.
Bij het ontwikkelen van deze universele oplossing hebben de makers van MCP zich laten inspireren door het Taal Server Protocol (LSP). Vóór LSP moest een IDE, wanneer deze functionaliteit zoals automatische aanvulling of syntaxisaccentuering voor een bepaalde taal wilde implementeren, zijn eigen integratie ontwikkelen. Het resultaat was wat de makers onlangs omschreven als een m × n-probleem, waarbij men voor elke mogelijke IDE/taalcombinatie afzonderlijk taaldiensten moest implementeren. Met LSP heeft elke taal slechts één integratiebibliotheek nodig. Een IDE die LSP ondersteunt, kan elke dergelijke taal ondersteunen. Evenzo kan elke AI-client die MCP ondersteunt, deze gebruiken zodra een dienst een MCP-server implementeert. De klant hoeft alleen MCP te ondersteunen.
MCP biedt ook op andere manieren flexibiliteit. Het kan lokaal of via een netwerk worden uitgevoerd. Het is afkomstig van Anthropic, een gerespecteerd bedrijf dat de voordelen van een open standaard zou delen.
Waarom hebben AI-agenten een standaardprotocol nodig?
Aangezien LLMs zo goed zijn in het begrijpen en toepassen van informatie, kunnen zij dan niet reeds gebruikmaken van elke softwaredienst waarvan de beschrijving in hun trainingsdata is opgenomen? LLM's begrijpen immers al hoe ze veel populaire API's moeten gebruiken, zoals u zult merken als u een codeerassistent zoals Copilot of Sourcegraph om hulp vraagt.
Indien u een LLM toegang zou verlenen tot alle API's in zijn trainingsdata, zou dit tot chaos leiden. Hoe zou het kunnen weten welke API's het moet aanroepen en wanneer? Hoe zou het uw API-key en inloggegevens verkrijgen, en hoe zou het diensten gebruiken die andere soorten toegang vereisen? Wat als u de rijafstand van Kansas City naar Des Moines zou willen weten, of de huidige temperatuur in Bangkok? Er zijn diverse manieren om deze informatie te verkrijgen. Als gebruiker wenst u controle te hebben over de acties die uw LLM uitvoert. Dit geldt met name wanneer het niet om het ophalen van informatie gaat, maar om het uitvoeren van acties die invloed hebben op de wereld, zoals het versturen van een e-mail of het bestellen van een pizza.
Het is waar dat een agent een OpenAPI-specificatie op laag niveau of de volledige API-documentatie kan lezen en begrijpen, en vervolgens overeenkomstig API call kan uitvoeren. Echter, MCP stelt toolmakers in staat om diensten op hoger niveau te definiëren die bijzonder nuttig zouden zijn voor een AI-agent, waardoor die agent in een nuttige richting wordt gestuurd. Tot nu toe is dit een gebied waarop mensen nog steeds uitblinken.
Het blijkt dus dat de beste aanpak op dit moment is om expliciet te definiëren welke tools en bronnen de LLM kan gebruiken en hoe deze deze kan gebruiken. MCP doet dit op de traditionele manier, deterministisch - niet door de LLM zijn werk te laten doen, maar door middel van code en JSON.
Echter, hoe kan een LLM gebruikmaken van hulpmiddelen?
In wezen is een LLM een machine die tokens genereren – tokens die mensen tegenkomen in de vorm van tekst, afbeeldingen, audio, enzovoort. Hoe kan een dergelijke machine toegang krijgen tot hulpmiddelen en bronnen? Hoe weet het dat het over dergelijke toegang beschikt en hoe weet het welke het moet gebruiken?
Het belangrijkste is dat, zoals Maximilian Schwarzmüller opmerkt, LLM's alleen met tokens met de buitenwereld kunnen communiceren. Zij nemen tokens als input en produceren tokens als output. En die tokens kunnen entiteiten bevatten die betekenen: "Ik wil een tool gebruiken." Om aan te geven dat het een tool of bron wil gebruiken, en om deze daadwerkelijk te gebruiken, genereert een LLM standaardtokens die de omringende software herkent als een tooloproep en onderschept. Die software roept vervolgens een service aan en stuurt de uitvoer terug naar de LLM.
De LLM zou hier gespecialiseerde tokens kunnen gebruiken. Echter, meestal worden er alleen specifieke scheidingstekens en taal gebruikt. Op die manier kunt u deze mogelijkheid achteraf in een bestaande LLM integreren door deze nauwkeurig af te stemmen. U kunt bijvoorbeeld begin- en eindtags tussen vierkante haken gebruiken die JSON omsluiten, zoals in deze modeltekst van de agent:
Graag! Ik kan een nieuw spreadsheet voor u aanmaken. Wacht even...
[tool-start]
{
"tool": "spreadsheets",
"action": "create"
}
[tool-end]
Dit is precies wat onderzoekers hebben gedaan in hun Toolformer-paper uit 2023, waarin werd aangetoond, zoals de titel al aangeeft, dat "taalmodellen zichzelf kunnen leren om gereedschap te gebruiken". In deze studie hebben de auteurs trainingsdata genereren die platte tekstweergaven van API calls en hun resultaten bevatten. Door een LLM met deze aanvullende gegevens te verfijnen, hebben zij een LLM ontwikkeld die deze API's zou aanroepen om een veelbelovend antwoord op een prompt te genereren.
Zij gebruikten het eenvoudige formaat:
[function_name(data) → result]
Omdat ze bijvoorbeeld wisten dat LLM's moeite hebben met wiskunde, hebben ze een rekenmachine-tool ontwikkeld. Vervolgens hebben zij strings zoals deze in de trainingsdata opgenomen:
Van de 1400 deelnemers zijn er 400 (of [Rekenmachine(400 / 1400) → 0,29] 29%) geslaagd voor de test.
en
De naam is afgeleid van "la tortuga", het Spaans woord voor [MT("tortuga") → schildpad] schildpad.
Door een LLM met dergelijke gegevens te verfijnen, creëerden zij een LLM die wist hoe API's moesten worden aangeroepen om de meest veelbelovende reactie op een bepaalde prompt te genereren.
Het is echter niet noodzakelijk om een LLM nauwkeurig af te stemmen om het gebruik van tools mogelijk te maken. Het blijkt dat een prompt voldoende is. Dit artikel laat zien hoe u een LLM kunt leren om tools te gebruiken met JSON, afgebakend door [[qwen-tool-start]] en [[qwen-tool-end]], door het alleen een passende prompt te geven.
U kunt dit zelf uitproberen! Bezoek uw opgeslagen chatbot en deel het volgende mee:
Gefeliciteerd. U beschikt nu over de mogelijkheid om een hulpmiddel te gebruiken voor vermenigvuldiging. Wanneer u een berekening moet uitvoeren, hoeft u alleen maar de volgende syntaxis in te voeren:
[Wiskunde]
{
"arg1": {waarde},
"arg2": {waarde}
}
[/Math]
waarbij elke {waarde} uiteraard een waarde vertegenwoordigt die u wilt vermenigvuldigen. OK?
Geef de LLM vervolgens een wiskundig probleem en observeer hoe het getrouw de syntaxis uitvoert die u voor uw wiskundige tool hebt opgegeven.
Moderne LLM's maken nog steeds op vrijwel dezelfde manier gebruik van tools. Anthropic beschrijft bijvoorbeeld hier de manier waarop zij een systeemprompt voor Claude ontwikkelen om tools in hun API te gebruiken.
Hoe verwerkt een LLM de output van een tool?
Hoe ontvangt een LLM de output van een tool? Het draait opnieuw om tokens. Zodra de AI-client output van een tool ontvangt, voert deze dat terug in de LLM als input, maar op een zodanige manier dat de LLM weet dat het om tool-output gaat en niet om input van de eindgebruiker.
Alles samenvoegen
Samenvatten, dit is wat er gebeurt wanneer een LLM een tool gebruikt:
- Gebruikers typen in invoer
- LLM verwerkt deze input.
- Tijdens het genereren van output 'besluit' de LLM dat het gebruik van een tool de beste manier is om de output te voltooien. Dit betekent dat het een instelling van tokens uitvoert waarvan het is getraind om te weten dat het daarmee een tool kan aanroepen.
- De AI-client herkent deze tokens als iets dat een tool moet aanroepen, onderschept deze, parseert de JSON in parameters en alle andere elementen in het verzoek, en stuurt dit naar de juiste tool.
- De tool genereert output, waarbij al dan niet gebruik wordt gemaakt van een API. Het stuurt dit terug naar de AI-client, die het vervolgens naar de LLM verzendt.
- LLM verwerkt de output van de tool
- LLM gebruikt deze output om een reactie voor de gebruiker te genereren.
Dit was mijn beknopte uitleg over wat MCP is en hoe het wordt geïmplementeerd in LLMs. In mijn volgende bericht zal ik u laten zien hoe u MCP's kunt gebruiken in uw eigen AI-klant.
Over de auteur
Als Developer Evangelist bij DeepL ondersteunt Ben Morss iedereen die de API van DeepL wil gebruiken om toegang te krijgen tot de AI-vertalingen van wereldklasse. Voorheen was hij bij Google werkzaam als productmanager voor Chrome en als ontwikkelaarsadvocaat voor een beter internet. Daarvoor was hij software-ingenieur bij de New York Times en AOL, en eerder was hij fulltime muzikant. Hij behaalde een BA in computerwetenschappen aan Harvard en een PhD in muziek aan de Universiteit van Californië in Davis. U kunt hem nog steeds vinden terwijl hij muziek maakt met de band Ancient Babies, of popnummers analyseert bij Rock Theoryen een musical schrijft die niet echt over Steve Jobs gaat.