Overbelasting van MCP’s verantwoordelijkheden
Een veelgehoorde kritiek is dat MCP teveel verantwoordelijkheid wordt toebedeeld. De auteur stelt dat MCP primair moet dienen als een toegangspoort voor LLM’s om toegang te krijgen tot externe resources en ermee te interageren. Het beschouwen ervan als louter een ‘deur’ of ‘brug’ helpt om het doel en de beperkingen te verduidelijken.
Het toeschrijven van problemen zoals accidentele datalekken, prompt injectie kwetsbaarheden en tekortkomingen in kostenbeheersing rechtstreeks aan MCP is een misplaatste beschuldiging. Dit zijn problemen die ontwikkelaars moeten aanpakken binnen de grenzen die ze controleren. Ontwikkelaars moeten snelheidslimieten implementeren en het gebruik monitoren, ongeacht het gebruikte protocol. Dit gelijkstellen aan het de weg verwijten van te hard rijden is treffend – de infrastructuur is niet verantwoordelijk voor individueel gedrag.
Uiteindelijk zijn veel van de gerezen zorgen bredere problemen met betrekking tot het delegeren van taken aan AI-agenten. Ontwikkelaars moeten verantwoordelijkheid nemen voor het beheren van deze uitdagingen binnen hun specifieke applicaties, in plaats van te verwachten dat de API zelf alles afhandelt.
Het tweesnijdende zwaard van LLM’s en prompt injectie
Recente discussies rond MCP lijken vaak op waarschuwingen over de inherente gevaren van scherpe messen – ze kunnen snijden als ze verkeerd worden gehanteerd. Prompt injectie, een aanzienlijke zorg, is een gevolg van de aard van LLM’s zelf. Pogingen om prompt injectie te elimineren, riskeren het degraderen van de mogelijkheden die LLM’s waardevol maken.
Het idee van ‘controle vs. data’ scheiding, gebruikelijk in traditionele systemen, bestaat van nature niet in LLM’s. LLM’s ontlenen hun kracht en algemeenheid juist aan het feit dat ze deze rigide scheiding missen. Dit inherente kenmerk maakt ze kwetsbaar voor prompt injectie aanvallen.
Hoewel remote MCP’s as a Service risico’s kunnen opleveren, ligt de fout niet bij het protocol zelf, maar bij het toevertrouwen van gevoelige taken aan onbetrouwbare derden. Deze analogie strekt zich uit tot het idee van het vasttapen van een mes aan een grillige Roomba – het probleem is niet het mes zelf, maar de beslissing om het aan een onvoorspelbaar apparaat te bevestigen.
Aanmaningen om ‘voorzichtig te zijn’ of suggesties van beschermende kleding, hoewel technisch correct, missen de kern van de zaak: de ondoordachte beslissing om een scherp gereedschap te combineren met een ongecontroleerd systeem.
Schaalbaarheidsproblemen
Naast veiligheidsrisico’s kampt MCP met fundamentele schaalbaarheidsbeperkingen. De auteur benadrukt de negatieve correlatie tussen LLM-betrouwbaarheid en de hoeveelheid instructiecontext die wordt verstrekt. Dit daagt de algemene overtuiging uit dat het toevoegen van meer data en integraties automatisch problemen zal oplossen. Naarmate het aantal tools en integraties toeneemt, kan de prestatie van een agent achteruitgaan terwijl tegelijkertijd de kosten van elk verzoek stijgen.
De auteur benadrukt dat MCP niet verder schaalt dan een bepaalde drempel. Het proberen een onbeperkt aantal tools toe te voegen aan de context van een agent zal onvermijdelijk de mogelijkheden negatief beïnvloeden. Deze beperking is inherent aan het concept van MCP en vereist meer aandacht dan authenticatieproblemen.
Gebruikers kunnen uiteindelijk een prestatievermindering ervaren naarmate ze meer MCP-servers inschakelen, wat leidt tot interferentie tussen hen. Dit staat in schril contrast met typische pakketbeheersystemen, waar niet-interferentie een fundamentele eigenschap is.
Het kernprobleem met MCP is dat het feitelijke gedrag afwijkt van de verwachtingen van de gebruiker. Het is cruciaal om te erkennen dat MCP geen plug-and-play oplossing is die naadloos een onbeperkt aantal tools integreert zonder gevolgen.
Beperkingen aanpakken met UI en toolbeheer
Een voorgestelde oplossing voor MCP’s beperkingen is het verbeteren van de gebruikersinterface. Als een tool onbedoeld wordt uitgevoerd, moet de UI een gemakkelijke manier bieden om deze uit te schakelen of de beschrijving aan te passen om het beoogde gebruik te verduidelijken.
De auteur merkt ook op dat contextgroei vaak leidt tot verbeterde prestaties en real-world gebruiksmogelijkheden, wat de notie van een strikt negatieve correlatie tegenspreekt. Ze erkennen echter dat in bepaalde use cases of met slecht ontworpen contexten, prestatievermindering kan optreden.
Om de overweldigende keuze aan tools aan te pakken, wordt een “verdeel en heers” aanpak voorgesteld. Dit omvat het toevoegen van een tool die specifiek is ontworpen voor het selecteren van de meest relevante tools voor een bepaalde taak. Deze “tool-kiezende tool” kan een andere LLM-oproep zijn, belast met het terugsturen van een subset van beschikbare tools naar de “ouder” agent. Deze gelaagde aanpak voegt extra niveaus van indirectie toe om de complexiteit te beheren.
Het simpelweg hebben van tools in de context kan echter de output van een model aanzienlijk veranderen. Hoewel contextueel relevante tools (bereikt door middel van technieken zoals Retrieval-Augmented Generation of RAG) gunstig zijn, kan het verbergen van alle tools achter een “get_tools” verzoek schadelijk zijn.
MCP als transport- en autorisatielaag
MCP functioneert primair als een transport- en wire-formaat met een request/response lifecycle, waarbij de focus ligt op autorisatie op toolniveau. Het essay stelt dat het grootste probleem met MCP is dat het AI-agenten niet in staat stelt om tools functioneel samen te stellen.
De auteur stelt dat MCP in de eerste plaats misschien onnodig is, aangezien LLM’s al de mogelijkheid hebben om te interageren met API’s die zijn gedocumenteerd met behulp van OpenAPI-specificaties. Het ontbrekende element is autorisatie – de mogelijkheid om te bepalen tot welke API’s een AI toegang heeft. In plaats van MCP stelt de auteur voor om AI’s HTTP-verzoeken te laten doen terwijl autorisatie wordt toegepast op specifieke endpoints. Deze aanpak sluit aan bij de huidige trend van het wrappen van bestaande API’s met dunne MCP-tools.
Een bijzonder vervelend aspect van MCP is het gebrek aan ondersteuning voor streaming tool call resultaten. Het enkele request/response paar dwingt clients om herhaaldelijk tools aan te roepen voor paginering, wat langdurige processen belemmert. Het implementeren van een streaming mogelijkheid, misschien met behulp van gRPC, zou de efficiëntie van MCP aanzienlijk kunnen verbeteren.
Het gemak van het blootleggen van gevoelige data
Een aanzienlijke zorg bij MCP is de potentie voor gemakkelijke blootlegging van gevoelige data. Bovendien maakt MCP AI-agenten niet inherent betrouwbaarder; het geeft ze eenvoudigweg toegang tot meer tools, wat paradoxaal genoeg de betrouwbaarheid in bepaalde situaties kan verminderen.
De auteur erkent dat ze niet verwachten dat MCP al deze problemen oplost of er verantwoordelijk voor is. MCP creëert eerder een groter aanvalsoppervlak voor deze problemen, waardoor app-ontwikkelaars en gebruikers waakzaam moeten zijn.
Analogieën en stadsplanning
De auteur gebruikt de analogie van stadsplanning om het probleem te illustreren. Het vergelijken van MCP met een zesbaansweg in de stad met een snelheidslimiet van 40 km/u benadrukt de ontkoppeling tussen ontwerp en beoogd gebruik. Het simpelweg opleggen van boetes of het toevoegen van oppervlakkige ‘oplossingen’ pakt het onderliggende probleem van een slecht ontwerp niet aan.
Effectieve stadsplanning omvat het ontwerpen van wegen die van nature de naleving van snelheidslimieten aanmoedigen. Evenzo moet MCP worden ontworpen om potentiële risico’s inherent te mitigeren, in plaats van uitsluitend te vertrouwen op externe controles.
LLM’s die ongewenste acties ondernemen
Het artikel verschuift naar een bredere kritiek op protocollen die LLM’s toestaan acties op diensten uit te voeren. De auteur identificeert een kernprobleem: LLM’s kunnen acties ondernemen die gebruikers niet bedoelen dat ze ondernemen. Ze maken onderscheid tussen acties die LLM’s onafhankelijk kunnen ondernemen en acties die gebruikersprompting vereisen.
Hoewel het uiteindelijke doel misschien is om LLM’s hele bedrijven te laten beheren, is de technologie nog niet klaar voor dergelijke autonomie. Momenteel willen gebruikers misschien niet eens dat AI’s e-mails verzenden zonder voorafgaande beoordeling.
De auteur verwerpt de oplossing van het vragen van de gebruiker om bevestiging, waarbij het risico wordt aangehaald dat gebruikers in een patroon van automatische bevestiging (“YOLO-modus”) vallen wanneer de meeste tools onschadelijk lijken. Dit wordt vergeleken met het psychologische fenomeen dat mensen meer uitgeven met kaarten dan met contant geld – een probleem dat geworteld is in menselijk gedrag, niet in technologie.
De fundamentele vraag: Waarom niet gewoon API’s gebruiken?
Een terugkerende vraag in discussies over MCP is waarom niet gewoon API’s rechtstreeks gebruiken.
MCP staat LLM-clients toe die gebruikers niet rechtstreeks controleren (bijv. Claude, ChatGPT, Cursor, VSCode) om te interageren met API’s. Zonder MCP zouden ontwikkelaars aangepaste clients moeten bouwen met behulp van LLM API’s, een veel duurdere onderneming dan het gebruik van bestaande clients met een abonnement en het leren hoe specifieke tools te gebruiken.
Een ontwikkelaar deelt zijn ervaring met het bouwen van een MCP-server om verbinding te maken met zijn FM hardware synthesizer via USB, waardoor AI-gestuurde sound design mogelijk wordt.
LLM Client integratie en standaardisatie
Het kernprobleem is dat niet alle LLM-clients native directe API-interactie ondersteunen, waarbij ChatGPT aangepaste GPT-acties een opmerkelijke uitzondering zijn. Anthropic, Google en OpenAI zijn overeengekomen om MCP te adopteren als een gedeeld protocol om het proces voor LLM-aangedreven clients zoals Claude, ChatGPT en Cursor te stroomlijnen.
MCP vereenvoudigt het proces voor degenen die LLM-clients bouwen. Als je wilt dat een LLM interageert met een API, kun je niet simpelweg een API-sleutel verstrekken en verwachten dat het werkt – je moet een Agent creëren.
MCP kan worden gezien als een manier om API’s te documenteren en te beschrijven hoe ze aan te roepen, samen met gestandaardiseerde tooling om die documentatie bloot te leggen en oproepen te faciliteren. Het biedt net genoeg abstractie om API’s te wrappen zonder onnodige complicaties, maar deze eenvoud kan er ook toe leiden dat gebruikers ‘zichzelf in de voet schieten’.
De efficiëntie en herbruikbaarheid van MCP
Zonder MCP zouden ontwikkelaars herhaaldelijk aan de LLM moeten uitleggen hoe een tool te gebruiken telkens wanneer deze wordt aangeroepen. Dit brengt het risico met zich mee dat de LLM de tool niet correct gebruikt vanwege vergeten informatie of niet-standaard API-gedrag.
Dit constante uitleggen en dupliceren verspilt tokens in de context, waardoor de kosten en de tijd toenemen. MCP stroomlijnt dit proces door alle noodzakelijke informatie te bundelen, waardoor het gebruik van tools efficiënter wordt en het delen van tools wordt gefaciliteerd.
Door een LLM-provider te vertellen ‘hier is een tool die je kunt gebruiken’ samen met API-documentatie, kunnen gebruikers die tool hergebruiken in meerdere chats zonder herhaalde herinneringen. Dit stelt ook desktop LLM-clients in staat om verbinding te maken met programma’s die lokaal draaien, waardoor het probleem van OS-specifieke uitvoeringsprocessen wordt aangepakt.
MCP en lokale bron toegang
MCP faciliteert toegang tot lokale bronnen zoals bestanden, omgevingsvariabelen en netwerktoegang voor LLM’s. Het is ontworpen om lokaal te worden uitgevoerd, waardoor de LLM gecontroleerde toegang tot deze bronnen krijgt.
De standaard LLM tool call “vorm” komt sterk overeen met de MCP tool call “vorm”, waardoor het een eenvoudige standaard is voor het verbinden van tools met agents.
MCP fungeert als een brug tussen het functie aanroepschema dat aan het AI-model wordt blootgesteld en de onderliggende API’s. Het vertaalt functie aanroepen in tools, waardoor naadloze communicatie mogelijk is.
Als je een tool provider bent, biedt MCP een gestandaardiseerd protocol voor AI-agent frontends om verbinding te maken met je tool. Dit beantwoordt de vraag waarom het standaardprotocol niet simpelweg HTTP en OpenAPI kan zijn.
MCP is een meta-API die endpoints en hun operationele details in de specificatie opneemt, waardoor LLM’s effectiever met hen kunnen interageren.
MCP in specifieke scenario’s
MCP kan problemen oplossen wanneer gebruikers vragen stellen of niet zeker weten welke API’s ze moeten gebruiken. Het kan ook verzoeken verwerken op basis van eerdere berichten.
Een gebruiker deelt zijn ervaring met het willen ophalen van de “X” van een gebruiker en deze naar een endpoint willen verzenden. Ze vonden MCP overkill voor zo’n eenvoudige taak, wat aangeeft dat het niet altijd noodzakelijk is voor basis API-interacties.
MCP wordt vergeleken met een FastAPI web app framework voor het bouwen van software die via het netwerk kan communiceren, specifiek ontworpen voor agentic ervaringen. Het kan worden gezien als “Rails-for-Skynet”, dat een gestandaardiseerd framework biedt voor AI-agent ontwikkeling.
Zorgen over provider controle
Er zijn zorgen dat MCP wordt gepusht om de controle over het systeem aan de providerzijde te vergroten. LLM-providers kunnen uiteindelijk de API-toegang beperken, vergelijkbaar met hoe Google het moeilijk maakte om IMAP/SMTP met Gmail te gebruiken.
Met behulp van OpenAPI kunnen agents API-specificaties ophalen van /openapi.json.
MCP maakt snelle interacties mogelijk, waardoor gebruikers taken in seconden kunnen voltooien in plaats van tijd te besteden aan het voorbereiden van input data, het verzenden ervan naar de API, het parseren van de output en het herhalen van het proces voor elk bericht.
Sandboxing en veiligheidsrisico’s
Een van de grootste problemen is hoe de output van de tool van de ene MCP server andere tools in dezelfde berichtthread kan beïnvloeden. Dit vereist sandboxing tussen tools om onbedoelde gevolgen te voorkomen. Invariant labs pakte dit aan met toolbeschrijvingen, terwijl anderen MCP resource attachments hebben gebruikt. Het gebrek aan sandboxing verergert de prompt injectie risico’s.
Dit wordt vergeleken met SQL-injectie – een systeem dat in elkaar is geflanst waar kwetsbaarheden op elk moment met minimale observeerbaarheid kunnen worden uitgebuit.
De prompt interface is ook vatbaar voor een vorm van SQL-injectie, omdat het model geen onderscheid kan maken tussen betrouwbare delen van de prompt en door de gebruiker verontreinigde input. Het oplossen hiervan vereist fundamentele veranderingen in codering, decodering en model training.
Dit maakt zowel prompt injectie als tool injectie mogelijk, wat mogelijk leidt tot de uitvoering van onbetrouwbare code.
Containerisatie en gecontroleerde toegang
Een ontwikkelaar heeft een MCP server gemaakt die een Docker container start met projectcode gemonteerd. Deze aanpak stelt de LLM in staat toegang te krijgen tot de gehele Unix toolset en projectspecifieke tooling binnen een sandbox omgeving.
Deze agentic workflow, aangedreven via een chat-based interface, is effectiever gebleken dan traditionele methoden.
De sleutel is om MCP agents toegang te geven tot wat ze nodig hebben, en niets meer. Containerisatie en transparante tool UX zijn cruciaal voor het mitigeren van veiligheidsrisico’s.
Virtuele machines en internet toegang
Het geven van agents een computer met een minimale Linux installatie (als een VM of container) kan betere resultaten opleveren, waardoor ze informatie van internet kunnen ophalen. Dit roept echter veiligheidsrisico’s op met betrekking tot kwaadaardige instructies en data exfiltratie.
Het beperken van toegang tot vertrouwde websites kan sommige risico’s mitigeren, maar zelfs vertrouwde bronnen kunnen kwaadaardige inhoud hosten. De afweging tussen de waarschijnlijkheid van het tegenkomen van kwaadaardige instructies en de productiviteitsvoordelen moet zorgvuldig worden overwogen.
De verschillen tussen werknemers en AI-agenten zijn significant. Werknemers zijn rechtspersonen die onderworpen zijn aan wetten en contracten, wat verantwoordelijkheid biedt. AI-agenten missen dit juridische kader, waardoor vertrouwen moeilijker wordt.
De vroege stadia van MCP ontwikkeling
MCP werd pas in november 2024 aangekondigd en de RFC is actief in ontwikkeling.
Sommigen beschouwen het hele AI personal assistant concept, inclusief MCP, als fundamenteel gebrekkig.
De initiële push voor AI Assistants in de late jaren 1990 en vroege jaren 2000 mislukte omdat content aggregators met verticale integratie en bulk buying power effectiever bleken. Dit leidde tot de opkomst van platforms zoals Expedia en eBay.
Multi-agent systemen vereisen dat programmeurs de status van agents beïnvloeden, een uitdagende programmeertaak.
De grenzen van gratis waarde
De wens om ‘resultaten te rangschikken op basis van parkeermogelijkheden’ benadrukt het probleem van het toegang krijgen tot data achter betaalde API’s of advertentie-ondersteunde frontends. Bedrijven zullen waarschijnlijk geen gratis toegang tot hun hele dataset verstrekken via een API.
Hoewel niet alle bedrijven hun data in AI-agenten zullen integreren, blijft het potentieel voor het combineren van verschillende tools om workflows aan te drijven significant.
Bedrijven die prioriteit geven aan het behouden van een data moat, zullen waarschijnlijk nieuwe technologieën weerstaan die die moat bedreigen.
Als booking.com een API had, zouden ze waarschijnlijk dezelfde resultaten teruggeven als hun website, mogelijk met JSON- of XML-formattering.
Het omzeilen van de tussenpersoon
Het heeft weinig zin voor een tussenpersoon zoals booking.com om gebruikers toe te staan hun diensten volledig te omzeilen.
Individuele hotels zouden het echter nuttig kunnen vinden om booking.com, een tussenpersoon die ze vaak niet leuk vinden, te omzeilen.
Een Deep Research AI zou kunnen scannen naar hotels op basis van specifieke criteria en interageren met Hotel Discovery MCP servers die door individuele hotels worden gerund, waardoor het niet nodig is om door de interface en advertenties van booking.com te navigeren.
Praktische use cases
MCP kan taken faciliteren zoals het ophalen van logs van Elasticsearch of het op een meer gestructureerde manier bevragen van databases.
De statische aard van MCP serverconfiguratie, waarbij nieuwe servers het bewerken van een .json bestand en het herstarten van de app vereisen, kan beperkend zijn.
Fijnafgestelde modellen
MCP kan worden gezien als een klein, fijnafgestemd model dat talloze MCP tools begrijpt en de juiste tools kiest voor elk gesprek.
Het dynamisch aanpassen van tools op basis van context kan noodzakelijk zijn voor bepaalde scenario’s.
Open-ended gesprekken en zakelijke problemen
MCP is zeer geschikt voor algemene, open-ended gesprekssystemen zonder vooraf gedefinieerde stroom. Het is echter geen one-size-fits-all oplossing voor elk zakelijk probleem. Het is niet bedoeld om frameworks zoals LangChain te vervangen.
Het alternatief voor MCP, een open community-gedreven standaard, is gefragmenteerd, propriëtair en vendor-locked protocollen. Een gebrekkige maar evoluerende standaard is te verkiezen boven geen standaard.
De beste manier om MCP te bekijken is als een verschuiving van individuele ontwikkelaars die client wrappers rond API’s bouwen naar API providers of community-onderhouden wrappers die ze bouwen. Dit biedt een grote toolbox, vergelijkbaar met NPM of PyPi. Orchestratie, veiligheid en gebruiksdefinitie zijn echter nog steeds vereist.
De volgende generatie Langchains zal profiteren van deze grotere toolchest, maar innovatie is nog steeds nodig.
Gebruikersspecifieke tools
In sommige gevallen kunnen tools specifiek zijn voor gebruikersdata, zoals tools voor het slicen en manipuleren van geüploade CSV bestanden.
Een vaak over het hoofd gezien probleem is dat MCP de modelcontext kan overladen met te veel opties. Prioritering en metadata blootstelling zijn cruciaal om verspillend tokengebruik en grillig modelgedrag te vermijden.
Standaarden en evoluerende technologie
Er ontstaan in de loop van de tijd nieuwe standaarden, en het is zo lang geleden dat standaarden er echt toe deden dat mensen vergeten zijn hoe ze zich ontwikkelen.
Het downloaden van kleine serverprogramma’s van willekeurige ontwikkelaars om ‘tools’ toe te voegen aan LLM-clients kan riskant zijn.
De gerezen problemen zijn legitieme problemen die het MCP-ecosysteem moet aanpakken. Sommige oplossingen zullen binnen de MCP-specificatie vallen, terwijl andere extern zullen zijn.
Claude Code en real-world gebruik
Er zijn contrasterende meningen over het succes van MCP. Sommigen hebben verhalen gehoord van bedrijven die integreren met MCP, terwijl anderen van gebruikers hebben gehoord die het teleurstellend vonden.
Dit benadrukt het nadeel van hype en vroege adoptie.
Sommige ontwikkelaars vinden dat HTTP API’s superieur zijn aan MCP voor de meeste use cases. Ze stellen dat het gebruik van “tool” neerkomt op API endpoints voor mogelijkheden en functionaliteit.
API’s zijn niet standaard zelfbeschrijvend, wat een gemiste kans is voor REST- en HATEOAS-voorstanders om hun benaderingen te laten zien.
MCP als een LangChain alternatief?
MCP is beschreven als een “LangChain geur” hebben – het lost geen dringend probleem op, is overdreven abstract en heeft moeite om de voordelen uit te leggen.
Misschien moet het zeggen “END OF LINE” en wannabe hackers verbannen naar de game grid!
Een belangrijke vraag is of het “algemene” Chatbot paradigma zal blijven bestaan. Gespecialiseerde apps met hun eigen tools hebben MCP misschien niet nodig.
Omgekeerd, naarmate LLM’s capabeler worden, kunnen externe tools minder noodzakelijk worden. Waarom zou je een MCP willen om Photoshop aan te sturen als de LLM de afbeelding gewoon rechtstreeks kan bewerken?
De sci-fi robot assistant droom komt misschien niet uit, en gespecialiseerde taalmanipulatie tools zijn misschien nuttiger.
Het gebruikersbestand en beveiligingsbewustzijn
Het gebruikersbestand van MCP omvat minder technische individuen, waardoor beveiligingsproblemen bijzonder relevant zijn. Het vergroten van het bewustzijn van security best practices is cruciaal.
Het baseren van Xops op OpenRPC, wat het definiëren van het resultaatschema vereist, helpt bij het plannen hoe outputs op inputs aansluiten, waardoor de betrouwbaarheid voor complexe workflows wordt verbeterd.
De technologie zal waarschijnlijk evolueren en zich na verloop van tijd vestigen.
Redundantie en cloud infrastructuur
Sommigen betwijfelen de winst van het gebruik van MCP ten opzichte van de OpenAPI standaard en beschouwen het als redundant.
Wat zal de LLM gebruiken om naar een OpenAPI systeem te bellen? Hoe zal het binden aan de shell? Hoe zal de host van de LLM dat orkestreren?
MCP biedt een gestructureerde manier voor LLM’s om tool calls te doen.
MCP servers zijn al HTTP servers.
Het grootste voordeel van MCP is voor LLM providers zoals OpenAI, niet voor applicatieontwikkelaars.
LLM’s zijn hersenen zonder tools, en tool calling geeft ze kracht. Met normale API’s hebben LLM providers echter geen toegang tot die tools. MCP geeft hen toegang, waardoor ze worden gepositioneerd als de gateway naar AI.
CLI vs. API
Waarom niet de CLI rechtstreeks gebruiken, aangezien LLM’s getraind zijn op natuurlijke taal en CLI’s een veelvoorkomende door mensen leesbare en schrijf bare oplossing zijn?
MCP kwam te snel op en heeft tijd nodig om te rijpen. Het mist doorlichting door een conventioneel standaardenorgaan en wordt aangedreven door hype.
Er is een gebrek aan real-world applicaties.
Belangrijkste toepassingen van MCP
MCP wordt gebruikt in Claude Desktop en niche AI chat apps, code automation tools en agent/LLM automation frameworks.
Het is weer een gehaaste technologie die waarschijnlijk zal worden weggegooid wanneer het volgende hype able acroniem arriveert.
Er zijn twee soorten language model tool calling protocollen: degene waar mensen over klagen en degene die niemand gebruikt.
Anthropic heeft deze “standaard” in een vacuüm ontwikkeld, wat leidt tot veiligheidsproblemen.
JSON-RPC 2.0
MCP is gebouwd op JSON-RPC 2.0, een lichtgewicht protocol dat client- en servercommunicatie mogelijk maakt met behulp van JSON.
Het voelt als een gecentraliseerde specificatie ontworpen voor een specifiek ecosysteem, die universaliteit claimt zonder het te verdienen.
MCP is krachtig genoeg om nuttige dingen te doen, wat veiligheidsrisico’s oproept.
Het is geen volwassen standaard en is niet ontworpen om veilig te zijn.
Hoewel er aanbevelingen bestaan, worden ze niet afgedwongen of geïmplementeerd.
Langchain en tool calling
Langchain is een van de vele frameworks die het “tool calling” patroon implementeren.
MCP is een specificatie voor hoe externe informatie de context window van een language model binnenkomt, inclusief tool calling, templated input, annulering, progress tracking en statefulness van tool servers.
Het helpt details te standaardiseren, zodat elke assistant/integratie combo compatibel is.
Hoewel MCP legitieme problemen heeft, moeten critici hun argumenten verfijnen.
Authenticatie is cruciaal en had niet mogen worden weggelaten uit de eerste versie.
Er zijn te veel complexiteiten.