Dag Diewy,
ik denk niet dat dat 100% de juiste conclusie is.
Zoals ik het zie, maar, kan verkeerd zijn, is MCP gewoon een generieke manier om services/functies beschikbaar te maken aan een LLM. Maw, MCP is een generieke manier van RAG (Reality Augmented Generation) te doen, maar het blijft RAG, het is niet iets anders.
RAG is een concept waarbij je een LLM een aantal functies geeft die hij kan gebruiken om ofwel data op te vragen, ofwel om acties uit te voeren (wanneer je acties begint uit te voeren, spreekt men vaak van een “agent”, maar op zich is dat niets anders dan een RAG functie die iets effectief uitvoert in de wereld ipv enkel maar data opzoekt en teruggeeft aan het model). Achter de schermen is het eigenlijk niet meer dan letterlijk een “code functie” laten uitvoeren door een LLM. Bvb, als je met de Python API van OpenAI werkt dan ga je een aantal “tools” meegeven aan je LLM inference. Je kan bvb twee Python functies voorzien: “List Google Drive files” en “Delete Google Drive file”. Die functie moet jezelf implementeren in je Python script, met de libraries/sdks die je vindt van weet ik veel wie. Als iemand anders iets soortgelijk wil doen, moet die ook die functies implementeren. Dat is in essentie RAG. Elke vendor en framework heeft zijn eigen manier van werken. Je hebt Langchain/Langraph die daar een framework voor hebben, Semantic Kernel van .NET noemt dat plugins, … ieder zijn ding.
De clou van het verhaal zit hem in het “als iemand anders iets soortgelijke wil doen, moet die ook die functies implementeren” en “ieder zijn ding”. Wanneer developers zoiets tegenkomen, gaat er meestal een lampje branden: “kunnen we geen algemeen/wereldwijd/universeel protocol maken dat alle LLMs begrijpen zodat niet iedereen altijd maar diezelfde functies moet implementeren en meegeven aan zijn LLM”. Deze functies die dan beschreven worden met dit generiek protocol kunnen dan beschikbaar gemaakt worden door de leveranciers van die diensten, want die kennen hun diensten het best, en de LLM leveranciers zorgen dan dat zij op hun beurt dat kunnen interpreteren. Op die manier moet niet iedereen steeds diezelfde RAG functies schrijven om zijn LLM slimmer te maken.
Zo kan bvb Google zelf een MCP server ter beschikking stellen met alle functies die het ter berschikking wil stellen aan een LLM. En als Google het niet wil, kan een derde partij wel zo’n server ter beschikking stellen. Als LLM gebruiker moet je dan gewoon die dienst registreren (vermoedelijk met wat authenticatie natuurlijk) in whatever LLM tool die je graag gebruikt en MCP ondersteunt, en plotseling kan je LLM praten met Google.
Dus het is een standaardisatie van RAG die idd aan belang lijkt te winnen. Zeker nu OpenAI ook mee in dat bad gestapt is.
Nu, er waren al een aantal “generalisaties” aan de gang. Bvb, er waren al manieren om bvb een OpenAPI (let op, er staat een P in, dus niet OpenAI) specificatie om te zetten in RAG functies om een bepaalde manier, zodat je vanuit je LLM makkelijk een REST API kon aanspreken zonder heel het boeltje zelf te schrijven. Same goes voor SQL. Over OpenAPI gesproken, dat was uiteindelijk een soortgelijk verhaal: “kunnen we geen gemeenschappelijke manier vinden op web (REST) services te beschrijven zodat iedereen die kan gebruiken en geen proprietary SDKs moet gebruiken om de diensten van een bedrijf te implementeren”. In de software is dat al jaren traditie, de oudjes onder ons kennen ook het welkbekende SOAP, en wie kent er nog de COM componenten van Windows
(en de daarmee gepaardgaande pijnen
). Yup. Ik ben oud. Maar 't zijn altijd dezelfde beweegredenen al 30 jaar. Sommige van die initiatieven slagen, sommige falen… hangt er gewoon vanaf hoeveel volk er op de kar springt en of je genoeg grote bedrijven meekrijgt. Het succes van MCP ligt nu wel vast met OpenAI. Zolang die niet meegingen was het idd een dubbeltje op zijn kant want zij bepalen toch veel. Getuige daarvan is dat de meeste tools die je gebruikt om bvb een LLM op je eigen PC te draaien, de OpenAI “API” ter beschikking stellen, dat is eigenlijk al een beetje een standaard op zich omdat zij zo bepalend zijn/waren.
Op die manier zou het sneller en eenvoudiger zijn om allerlei diensten te integreren in onze “ChatGPT’s” die we gebruiken, of die nu van OpenAI, Google, Antrophic of eender wie komen, en of de integraties nu van Github, Google, Microsoft of eender wie komen. En op het moment dat die functies dingen uitvoeren, heb je een agent.
Het probleem/de moeilijkheid die ik nog zie is in de multi-agent ruimte… want met onze chat clients a la ChatGPT en Claude spelen wij zelf de link tussen de verschillende agent acties en zijn wij nog altijd het multi-agent brain dat informatie koppelt. Dat automatiseren in code is echter wat anders en dan wordt context een issue waar MCP nog niet voldoende antwoorden op heeft (mijn inziens) voor de problemen die zich dan stellen.
Maar dat is een ander verhaal…