Model context protocol van Anthropic maakt het mogelijk een LLM te gebruiken om met natuurlijk taal met databronnen interageren.
Zijn er in de CC mensen bezig met het bouwen van eigen MCP server? Wie weet zijn er onontdekt pareltjes…
Voorbeelden https://mcpservers.org/
Yes, een MCP topic!
Toen ik er eerst over las had ik niet door dat het protocol in twee richtingen werkt: je kunt niet alleen informatie ophalen (zoals bestanden bekijken), maar ook acties uitvoeren in die tools. Bijvoorbeeld als Google Drive gekoppeld is, kun je via je prompt documenten doorzoeken én kan de AI bestanden aanmaken of bewerken.
Ik heb er zondag wat mee zitten prullen, dus Claude desktop opgezet en bestaande servers geïntegreerd. Al vrij snel krachtige toepassingen gezien, bijvoorbeeld de koppeling van GitHub. Ik heb als prompt een bug omschreven zonder veel technische details, en Claude heeft toen een pull request aangemaakt om het op te lossen.
Wil inderdaad graag zelf eens een server maken om het protocol goed te begrijpen. Nu vooral inspiratie aan het opdoen, aan het nadenken wat leuk zou zijn om te bouwen.
Zoals ze in de AI-report aflevering zeggen zijn het nu vooral developer-toepassingen, het zou leuk zijn om iets breed en lokaal te kunnen koppelen. Misschien iets uit de datavindplaats, maar dan is het wel alleen nog maar data lezen, terwijl je pas echt doorhebt hoe krachtig het is als het ook een actie uitvoert…
Ik begin morgen met een eerste testimplementatie voor een aantal interne “bronnen”. We hebben nu al een “multi agentic” bot applicatie die goed werkt maar het “plugin” systeem is niet 100% ok. Ik hoop met MCP het “plugin” karakter wel dynamisch en juist te krijgen, en dus voor elke integratie intern een MCP server container te kunnen opschieten. Volgens wat ik zie zou dat redelijk eenvoudig mogelijk moeten zijn. Wij hebben zeker ook de twee richtingen (zoals @Diewy vermeld) nodig, want anders is het allemaal maar praat voor de vaak. Als het lukt zullen we er al minstens drie nodig hebben…
Ik realiseer me dat ik precies veel hippe woorden gebruik 
Maar vooraleer je liket zal ik me nu onpopulair maken door te zeggen dat we voornamelijk in .NET werken, want echte programmeertalen zijn toch een stuk leuker.
Let the hating begin 
https://openai.github.io/openai-agents-python/mcp/
OpenAI ondersteunt nu ook MCP! 
ELI5:
The Model context protocol (aka MCP) is a way to provide tools and context to the LLM
What is het verschil met RAG?
Hoe ik het tot nu toe begrijp: Realtime informatie + Acties uitvoeren.
Met RAG kan je vooral informatie en context toevoegen aan de LLM. Terwijl je via MCP de LLM meer gestructureerd data kan laten opvragen en acties uitvoeren.
Dus met het voorbeeld van Google Drive: Via RAG krijgt het LLM op een specifiek moment alle context van de documenten mee. Maar via MCP kan het op het moment van de prompt specifiek een document zoeken en die context gebruiken. Plus, het krachtigste, acties uitvoeren zoals documenten aanmaken of bewerken.
Disclaimer: Ik probeer hier zelf nog over bij te leren, geen expert. Moest ik het fout hebben, please correct me.
Als niet techie en dus met beperkte kennis van SQL statements is het toch wel makkelijk om met gewone taal een db te kunnen bevragen. De integratie in cursor is heel vlot.
Cool! Ik ben er ook wat mee aan het spelen. Het ziet er allemaal zeer veelbelovend uit en op zich kon ik wel al snel een toffe proof of concept ineen steken. Eerlijk gezegd had ik veel last van AI-moeheid en met de komst van MCP ben ik terug hyped om er mee te spelen 
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…
Duidelijke uitleg! Bedankt voor de correctie @wimpi! 