In het huidige AI-landschap is er een concept dat veel aandacht trekt: MCP, oftewel Model Context Protocol. Verrassend genoeg heeft de aandacht rond dit protocolsysteem zelfs de nieuwste modelreleases van OpenAI overschaduwd en is het een centraal punt van discussie in de industrie geworden.
De toename in populariteit van Agent-technologie, aangewakkerd door de opkomst van Manus, heeft het enthousiasme van wereldwijde ontwikkelaars aangewakkerd. MCP, gepositioneerd als een ‘unified protocol’ voor Agent tool invocation, heeft snel aan populariteit gewonnen en binnen slechts twee maanden steun gekregen van grote AI-spelers zoals OpenAI en Google. Deze snelle opkomst heeft MCP getransformeerd van een relatief obscure technische specificatie tot een fundamentele standaard binnen het AI-ecosysteem, wat een ‘fenomenaal evenement’ markeert op het gebied van AI-infrastructuur.
Naarmate de eerste opwinding afneemt, komen er echter kritische vragen naar voren: is MCP echt universeel toepasbaar? Zijn de verwachtingen van de mogelijkheden ervan te hooggespannen?
Deze verkenning duikt in de oorsprong van MCP, ontleedt de belangrijkste sterke punten en beperkingen, verduidelijkt de heersende misvattingen en onderzoekt het potentiële toekomstige traject. Het doel is niet om de inherente waarde van MCP te verwerpen, maar eerder om een meer gefundeerd begrip van de rol en grenzen ervan te bevorderen. Alleen door dergelijke duidelijkheid kan het potentieel volledig worden gerealiseerd.
MCP Ontsluierd: Een Unified Tool Invocation Protocol
MCP Definiëren
MCP is een open technisch protocol dat is ontworpen om de manier te standaardiseren waarop Large Language Models (LLM’s) communiceren met externe tools en services. Beschouw het als een universele vertaler binnen de AI-wereld, waardoor AI-modellen kunnen ‘converseren’ met een breed scala aan externe tools. Het biedt een gemeenschappelijke taal en structuur voor LLM’s om functionaliteiten aan te vragen en te gebruiken die worden aangeboden door verschillende applicaties en services.
De Noodzaak van MCP
Vóór de komst van MCP werd AI tool invocation geplaagd door twee belangrijke uitdagingen:
- Interface Fragmentatie: Elke LLM gebruikte verschillende instructieformaten, terwijl elke tool API zijn eigen unieke datastructuren had. Ontwikkelaars werden gedwongen om aangepaste verbindingscode te schrijven voor elke combinatie, wat leidde tot een complex en inefficiënt ontwikkelingsproces.
- Ontwikkeling Inefficiëntie: Deze ‘one-to-one vertaling’-aanpak bleek kostbaar en moeilijk te schalen. Het was alsof je een toegewijde vertaler inhuurde voor elke buitenlandse klant, wat de productiviteit en flexibiliteit belemmerde.
MCP pakt deze pijnpunten aan door een gestandaardiseerd framework te bieden voor LLM’s om te communiceren met externe tools, waardoor het ontwikkelingsproces wordt vereenvoudigd en een grotere schaalbaarheid mogelijk wordt.
Het Begrijpen van MCP’s Functionaliteit
De technische architectuur van MCP kan worden geconceptualiseerd als een systeem dat bestaat uit drie kerncomponenten: MCP Host, MCP Client en MCP Server. Deze elementen werken synergetisch samen om naadloze communicatie tussen AI-modellen en de buitenwereld te faciliteren.
Om de rol van MCP te begrijpen, kunt u een moderne bedrijfsomgeving overwegen. In deze analogie:
- Gebruikers vertegenwoordigen senior executives, verantwoordelijk voor het begrijpen van gebruikersbehoeften en het nemen van definitieve beslissingen.
- Large Language Models (LLM’s) (zoals Claude of GPT) begrijpen executive instructies, plannen taakstappen, bepalen wanneer externe services moeten worden gebruikt en consolideren informatie om antwoorden te geven.
- Agent Systems functioneren als persoonlijke assistenten of executive secretaries, die taken uitvoeren zoals geïnstrueerd.
- MCP fungeert als een gestandaardiseerd communicatieplatform of enterprise service access systeem dat wordt gebruikt door de secretaries. Het neemt geen beslissingen, maar volgt in plaats daarvan instructies op en communiceert met verschillende serviceproviders in een uniforme indeling en protocol.
Vóór MCP was AI-interactie met externe tools te vergelijken met een tijdperk van chaotische communicatiestandaarden. Elke keer dat een secretary (Agent) contact moest opnemen met een andere afdeling of externe leverancier, moest hij een ander communicatieapparaat of software gebruiken. Dit vereiste bekendheid met diverse systemen, wat resulteerde in inefficiëntie. Ontwikkelaars moesten afzonderlijke verbindingscodes schrijven voor elke tool, wat leidde tot verspilde tijd en beperkte schaalbaarheid.
MCP stroomlijnt dit proces door een uniform communicatieplatform te bieden, waardoor secretaries contact kunnen opnemen met elke afdeling of serviceprovider met behulp van hetzelfde systeem en communicatieprotocol. Ontwikkelaars hoeven de MCP-interface slechts één keer te implementeren, waardoor AI-systemen kunnen communiceren met alle tools die het protocol ondersteunen.
MCP: Een Toolbox Gebouwd op Function Call
Het is cruciaal om te begrijpen dat MCP geen vervanging is voor traditionele Function Call; het is eerder een aanvullende component die de mogelijkheden ervan verbetert.
Function Call is het kernmechanisme waarmee LLM’s communiceren met externe tools of API’s. Het is een fundamentele mogelijkheid van LLM’s, waardoor ze kunnen identificeren wanneer een tool nodig is en welk type tool vereist is.
MCP fungeert als een toolclassificatiesysteem en biedt een gestructureerd framework voor het organiseren en openen van verschillende tools. Daarom vervangt MCP Function Call niet, maar werkt het eerder samen met Agents om complexe taken te volbrengen.
Het complete tool invocation proces omvat een combinatie van ‘Function Call + Agent + MCP System’.
In wezen drukt de LLM de behoefte uit om een specifieke tool aan te roepen via Function Call. De Agent volgt instructies om de tool invocation uit te voeren, terwijl MCP een gestandaardiseerde tool invocation specificatie biedt.
Neem de volgende analogie: een baas (gebruiker) wil koffie. In het kantoor (MCP Host) instrueert de office manager (LLM) de secretary (Agent) om een Americano te kopen (Function Call). De secretary controleert de leverancierslijst en constateert dat een Americano koffieleverancier is geïntegreerd met Meituan of het unified procurement systeem van het bedrijf (geïmplementeerde MCP Server). De secretary zoekt vervolgens de leverancier in het procurement systeem (MCP Client) en plaatst een bestelling.
Zonder MCP, toen de LLM een Function Call uitgaf, zou de Agent vertalen en rechtstreeks verbinding maken met de API om de tool aan te roepen. Elke API vereiste een afzonderlijke invocation modus en een gedefinieerde toollijst en invocation modus voor de Agent om te interpreteren. Met MCP kunnen veel API’s rechtstreeks worden besteld via de MCP Client van de leverancier, waardoor de Agent tijd en moeite bespaart. De Function Call van de LLM blijft echter ongewijzigd, nog steeds in de indeling {tool: ‘koffie kopen’, ‘type’: ‘Americano’}.
Door onderscheid te maken tussen Function Call en MCP, wordt het duidelijk dat MCP niet bepaalt welke tool moet worden gebruikt, noch behandelt het taakplanning of gebruikersintentie. Deze aspecten vallen onder de bevoegdheid van de Agent-laag. MCP biedt simpelweg een uniforme tool interface en wordt een erkend standaardprotocol binnen de industrie.
MCP’s Ontwikkelingsuitdagingen en Marktlandschap
Het Ontwikkelingsraadsel
Sinds februari heeft de AI-ontwikkelingscommunity een ‘MCP gold rush’ meegemaakt. Bij gebrek aan een officiële app store hebben duizenden tools zich binnen drie maanden vrijwillig geïntegreerd met het MCP-protocol.
Deze snelle groei heeft MCP in de schijnwerpers van de industrie geplaatst, maar heeft ook de kloof blootgelegd tussen aspiratie en realiteit. Ontwikkelaars zagen MCP aanvankelijk als een ‘universele sleutel’, maar hebben ontdekt dat het meer een ‘gespecialiseerde sleutel’ is, die uitblinkt in bepaalde scenario’s maar minder effectief is in andere.
De deelnemers van MCP kunnen worden gecategoriseerd als lokale clientapplicaties, cloud clientapplicaties en MCP server ontwikkelaars. Lokale applicaties zijn vergelijkbaar met lokale AI-assistenten, terwijl cloud clientapplicaties lijken op webgebaseerde versies van ChatGPT. MCP server ontwikkelaars zijn de daadwerkelijke providers van tools, die hun API’s opnieuw moeten verpakken om te voldoen aan de MCP-regels.
De opkomst van MCP werd aanvankelijk verwelkomd door lokale clientapplicaties, maar cloud clientapplicaties en MCP server ontwikkelaars stonden voor uitdagingen.
MCP is ontstaan uit de Claude Desktop applicatie van Anthropic, aanvankelijk ontworpen als een interfaceprotocol voor het aanroepen van lokale bestanden en functies, diep geworteld in client-side behoeften.
Voor lokale clientgebruikers vertegenwoordigde MCP een revolutie, met een oneindig uitbreidbare toolbox waarmee gebruikers de mogelijkheden van hun AI-assistenten continu konden uitbreiden.
Lokale clientapplicaties zoals Cursor en Claude Desktop hebben MCP gebruikt om gebruikers in staat te stellen tools dynamisch toe te voegen op basis van individuele behoeften, waardoor een onbeperkte uitbreiding van de mogelijkheden van AI-assistenten wordt bereikt.
MCP pakt een belangrijk pijnpunt aan in de ontwikkeling van lokale clients: hoe AI-applicaties naadloos kunnen communiceren met lokale omgevingen en externe tools zonder afzonderlijke interfaces voor elke tool te ontwikkelen. Dit unified protocol vermindert de integratiekosten aanzienlijk en biedt kleine startups en individuele ontwikkelaars een shortcut naar het bouwen van feature-rijke AI-applicaties met beperkte middelen.
De aantrekkingskracht van MCP neemt echter af bij het overwegen van server-side development (MCP Server) en cloud clients. Vroege versies van MCP gebruikten een dual-link mechanisme voor cloud servers (remote), met behulp van een SSE long connection voor unidirectionele berichtpushing van de server naar de client en een HTTP short connection voor het verzenden van berichten.
Deze aanpak werkte goed voor tijdige user feedback en interventie, maar creëerde een reeks technische uitdagingen in server-side omgevingen.
Ten eerste vertegenwoordigt de implementatie van de MCP-interface een extra workload voor grote enterprise serviceproviders, zonder noodzakelijkerwijs overeenkomstige voordelen op te leveren. Deze services hebben vaak volwassen API-systemen en het bieden van een extra MCP-aanpassingslaag kan alleen de onderhoudskosten verhogen zonder substantiële waarde te creëren. Veel enterprise-level applicaties geven de voorkeur aan gesloten, controleerbare tool invocation mechanismen boven het open ecosysteem van MCP.
Om high-concurrency invocations te verwerken, moeten MCP-services bovendien vaak worden geschaald naar multi-server architecturen. Het dual-connection model van MCP introduceert de complexiteit van cross-machine addressing. Wanneer een long connection wordt tot stand gebracht op de ene server en een verzoek wordt gerouteerd naar een andere server, is een extra broadcast queue mechanisme nodig om deze gedistribueerde verbindingen te coördineren, waardoor de implementatiemoeilijkheid en de onderhoudskosten aanzienlijk toenemen.
Ten tweede heeft MCP beperkingen op het gebied van cloudapplicaties. Cloud AI Agents (server-side Agents) draaien doorgaans in stateless services, verwerken taken na acceptatie en geven resources vrij na voltooiing. Het gebruik van MCP Client aan de serverkant vereist de tijdelijke aanmaak van een SSE-link, het verzenden van een tool invocation verzoek, het ontvangen van het resultaat van de SSE en het vervolgens sluiten van de SSE-link, wat een inefficiënte aanpak is die de complexiteit verhoogt en de prestaties vermindert. Een enkel RPC-verzoek zou in dit scenario voldoende moeten zijn.
In de praktijk vertrouwen cloudapplicaties die MCP gebruiken vaak op vooraf ingestelde toolsets en gebruiken ze niet de signature capability van MCP van dynamische tool discovery en flexibel laden.
De data interactie modus van cloudomgevingen beperkt de mogelijkheid om tools vrijelijk te gebruiken zoals MCP bedoeld is. Het vereist een sterk gestandaardiseerd proces voor het aanroepen van specifieke, hard-gecodeerde tools, waardoor flexibiliteit wordt opgeofferd.
Het MCP-team heeft blijk gegeven van reactievermogen op user feedback. Na ontvangst van feedback van server-side ontwikkelaars heeft MCP zijn protocol op 26 maart bijgewerkt en de originele SSE transport vervangen door streamable HTTP transport. Het nieuwe protocol ondersteunt zowel stateless service scenario’s die slechts één tool invocation verzoek vereisen als real-time push requirements die voorheen werden vervuld via HTTP + SSE dual links.
Deze verbeteringen suggereren dat de huidige MCP-problemen voortkomen uit initiële ontwerpbeperkingen, maar niet onoverkomelijk zijn.
De Wanorde van de Markt
Een andere uitdaging voor MCP is de lage usability van veel implementaties op de markt.
De huidige MCP-markt beleeft een typische technology hype cycle. Vergelijkbaar met de chaos van de vroege App Store heeft minder dan 20% van de duizenden MCP-tools die momenteel beschikbaar zijn praktische waarde. Veel implementaties hebben ernstige problemen, variërend van eenvoudige configuratiefouten tot volledige onbruikbaarheid. Sommige worden overhaast op de markt gebracht zonder adequate tests, terwijl andere experimentele producten zijn die nooit bedoeld waren voor praktisch gebruik.
Een fundamenteler probleem is dat veel MCP-implementaties mogelijk niet nodig zijn voor de markt. Veel tools die via MCP worden aangeboden, zijn simpelweg opnieuw verpakte API’s die al beschikbaar en in gebruik waren vóór de opkomst van MCP, wat weinig unieke waarde toevoegt.
Er worden bijvoorbeeld tientallen zoekservices aangeboden via MCP, maar hun kwaliteit varieert aanzienlijk. Sommige services kunnen onnauwkeurig of traag zijn, waardoor ze minder aantrekkelijk zijn dan bestaande oplossingen.
MCP mist bovendien een robuust evaluatiesysteem, waardoor het voor Agents moeilijk is om de meest geschikte tool te selecteren op basis van betrouwbare metrics. Dit inefficiënte selectieproces verspilt computing resources, verlengt de taakvoltooiingstijden en verslechtert de gebruikerservaring.
Het ontbreken van een evaluatiesysteem maakt het voor agents moeilijk om de meest geschikte tool te selecteren. Als meerdere MCP-services tools aanbieden met vergelijkbare namen en beschrijvingen, kan de agent moeite hebben om de beste optie te kiezen, wat leidt tot verspilde tokens en verminderde efficiëntie.
De meest succesvolle AI-applicaties volgen vaak de tegenovergestelde aanpak en bieden meer precise tools in plaats van een grotere hoeveelheid tools. Manus koos er bijvoorbeeld voor om interne applicaties te bouwen in plaats van het MCP-protocol te adopteren, ondanks het bestaan ervan. Manus prioriteerde call-nauwkeurigheid en stabiliteit boven integratie met het MCP-ecosysteem.
Code editors zoals Cursor hebben ingebouwde ontwikkelingsfuncties, waardoor de meeste externe MCP-tools overbodig zijn.
De huidige chaotische toestand van de MCP-markt is niet noodzakelijkerwijs een teken van mislukking, maar eerder een noodzakelijke fase van groei voor elk opkomend technologie-ecosysteem. Historische precedenten suggereren dat deze initiële overexpansie geleidelijk zal convergeren via marktselectie mechanismen, waardoor de meest waardevolle elementen achterblijven.
Dit proces zal de industrie in staat stellen te leren van de huidige uitdagingen en een sterker, betrouwbaarder MCP-framework te creëren. Net zoals de dot-com bubble leidde tot game-changing innovaties in e-commerce en sociale media, kan de MCP-trend leiden tot een meer gestroomlijnd en waardevol tool-ecosysteem.
De open houding van het MCP-team ten opzichte van user feedback is bemoedigend en de industrie heeft betere tools nodig om de kwaliteit van MCP-services te evalueren en te waarborgen, wat zal helpen om het ecosysteem bruikbaarder te maken.
MCP Is Goed, Geen Wondermiddel
De hierboven genoemde problemen komen voort uit de beperkingen en tekortkomingen van MCP, waarbij wordt benadrukt wat het realistisch kan bereiken. Andere kritiek komt echter voort uit onrealistische verwachtingen.
Een recente kritiek bestempelt MCP als een gebrekkig protocol omdat het de interactiepatronen tussen LLM’s en MCP niet dicteert.
Sommigen verwachten dat MCP automatisch de besluitvorming van AI-systemen zal verbeteren of de efficiëntie van taakplanning zal verhogen. Deze verwachting verwart tools met ambachtslieden.
Het probleem komt voort uit een cognitieve mismatch – verwachten dat een communicatieprotocol taken van een intelligent systeem uitvoert. Dit is alsof je USB de schuld geeft van het niet bewerken van foto’s of 5G-standaarden de schuld geeft van het niet schrijven van code. MCP is in de eerste plaats een gestandaardiseerde ‘tool socket’, die plug-compatibiliteit garandeert in plaats van te dicteren welk apparaat moet worden gebruikt of hoe.
De effectiviteit van Agent-tool invocation hangt af van factoren zoals tool selectie proficiency, taakplanning skills en context comprehension, die geen van allen onder de bevoegdheid van MCP vallen. MCP garandeert alleen een gestandaardiseerde tool interface, niet hoe die tools zullen worden gekozen en gecombineerd.
We zoeken vaak naar silver bullets in technologie, universeel toepasbare oplossingen. Net als het ‘no silver bullet’-axioma van software engineering, heeft AI-toolgebruik geen magische oplossing. Een sterk AI-systeem heeft ontworpen componenten nodig: LLM’s voor het begrijpen en genereren, Agent frameworks voor het plannen en uitvoeren en MCP gericht op unified tool interfaces.
MCP toont een goed protocolontwerp – focussen op één probleem en het goed oplossen, in plaats van alles. De terughoudendheid helpt het vooruitgang te boeken bij client-side toolintegratie.
Entiteiten zoals Alibaba’s Qwen, Baidu’s ‘Xinxiang’ en ByteDance’s Kouzi Space omarmen het MCP-protocol en proberen efficiëntere interne MCP-ecosystemen tot stand te brengen.
Er zijn echter belangrijke verschillen in deployment: Baidu en ByteDance zijn agressiever. Baidu probeert een C-end aanpak, waarbij verschillende AI-modellen en externe tools worden geïntegreerd via de ‘Xinxiang’ (Kokone) gebruikmakend van het MCP-protocol, voornamelijk voor mobiele apparaten, om te integreren in het dagelijks leven van de gebruiker en adoptie aan te moedigen.
ByteDance’s Kouzi Space heeft 60+ MCP extension plugins. Toegankelijk via een webpagina lanceerde het ook een AI-native IDE, Trae, die MCP ondersteunt, voornamelijk gericht op productiviteitsscenario’s.
Alibaba integreerde het MCP-protocol in producten zoals Alipay, waardoor one-click AI-tool invocation mogelijk is en open-sourced het Qwen3-model, dat het MCP-protocol ondersteunt, waardoor de Agent-mogelijkheden worden verbeterd.
Tencent Cloud-ontwikkelaars brachten een AI-ontwikkelingssuite uit die MCP plugin hosting services ondersteunt. De large model knowledge engine van Tencent Cloud stelt gebruikers in staat om MCP plugins aan te roepen. De Craft software development intelligent agent gelanceerd door Tencent Cloud’s CodeBuddy is compatibel met het open MCP-ecosysteem. Bovendien hebben Tencent Maps en Tencent Cloud Storage hun eigen MCP SERVER uitgebracht.
AI-toolgebruik kan evolueren van directe, single-tool operatie naar professionele Agent-samenwerking, net zoals programmeerstijlen evolueerden van assembly language naar object orientation.
In dit paradigma kan MCP simpelweg onderdeel worden van de onderliggende infrastructuur, in plaats van een user- of developer-facing interface. Een completer plan vereist mogelijk architecturen zoals Agent to Agents (A2A) om taakplanning en tool selectie efficiëntie te verbeteren door abstractieniveaus te verhogen.
Door MCP terug te brengen naar zijn ‘protocol’-rol, kunnen we de ware kracht ervan erkennen om industriestandaardisatie te stimuleren – dit is misschien wel het meest gekoesterde ‘de-mystificatie’-moment in de technologische evolutie.