MCP is stilletjes dood. Corsair laat zien wat het vervangt.

MCP is stilletjes dood. Corsair laat zien wat het vervangt.

Ik had drieënveertig tools aangesloten op één enkele agent en ik zag hoe hij in realtime gek werd.

De taak was stom eenvoudig. "Haal de laatste tien e-mails uit mijn Gmail en vat alles samen wat te maken heeft met het voorstel dat ik dinsdag heb verzonden." Een taak in twee stappen. E-mail lezen. Samenvatten. Dat is het. In plaats daarvan belde de agent een Slack-zoektool. Vervolgens een kalendertool die ik voor een ander project had aangesloten. Vervolgens probeerde het gmail_get_messages aan te roepen, maar dat was niet de functienaam. Het eigenlijke hulpmiddel was read_gmail_inbox. De agent had een plausibel klinkende API-oproep gehallucineerd vanuit een schema dat hij zich half herinnerde via 38.000 tokens aan voorafgaande tooldefinities.

Ik stopte de run, opende het invoerlogboek en telde. Voordat mijn prompt zelfs maar het model had bereikt, had MCP meer dan 40.000 tokens aan toolschema's in het contextvenster geïnjecteerd. Veertigduizend tokens. Om een ​​vraag over tien e-mails te beantwoorden. De agent heeft nooit een kans gehad.

Dat was het moment waarop ik stopte met het verdedigen van MCP en begon te zoeken naar wat er daarna zou komen. Ik ga doornemen wat ik heb gevonden - inclusief een klein open-sourceproject genaamd Corsair dat volgens mij verwijst naar de echte architectuur voor toolgebruik in 2026. Maar eerst moet je begrijpen wat er feitelijk kapot is gegaan. Omdat "MCP dood is" geen hype is. Dat is wat de wiskunde zegt als je het protocol voorbij de speelgoeddemo's duwt.

Wat MCP moest doen

Anthropic heeft het Model Context Protocol eind 2024 op de markt gebracht met een zuivere, ambitieuze pitch. LLM's zijn hersenen zonder handen en benen. Ze kunnen briljant redeneren over code, taal en strategie, maar ze kunnen geen tweet posten, je inbox lezen of een spreadsheet bijwerken zonder externe leidingen. MCP moest dat sanitair zijn: gestandaardiseerd, leveranciersneutraal en universeel.

De monteur was duidelijk. Je stelt een instrument bloot. De tool maakt reclame voor een JSON-schema waarin de naam, parameters en wat het doet worden beschreven. De MCP-client injecteert aan het begin van het gesprek het schema van elk beschikbaar hulpmiddel in het contextvenster van het model. Het model kiest de juiste tool, genereert een gestructureerde oproep en de runtime voert deze uit. Gereedschap toevoegen. Krijg mogelijkheden. Herhalen.

Ik heb me er volledig in verdiept. Vorig jaar schreef ik over de drie MCP's die van Claude mijn operationele hub maakten — De combinatie van Canva, Zapier en Stripe veranderde de manier waarop ik werkte ongeveer zes maanden lang. Met drie of vier tools voelt MCP magisch aan. Het protocol verdwijnt. Je vraagt ​​om dingen in gewoon Engels en ze gebeuren.

Maar drie of vier gereedschappen is de speelgoedversie. Op het moment dat je opschaalt – het moment dat je probeert de daadwerkelijke stapel die een werkende professional gebruikt met elkaar te verbinden – barst de architectuur op drie specifieke manieren open.

Het opgeblazen probleem van het contextvenster

Hier is het nummer dat voor mij een einde maakte aan de romance.

Volgens een benchmark uit 2025 van Scalekit kostte dezelfde bewerking waarbij 1.365 tokens via een CLI nodig waren, 44.026 tokens via MCP. Dat is ruwweg 32x de token-overhead, en bijna alles was schema-injectie: 43 tooldefinities die in context werden geplaatst voordat de agent ook maar één teken van de eigenlijke vraag van de gebruiker had gelezen. Elke andere gerenommeerde analyse die ik sindsdien heb gelezen, komt in dezelfde buurt terecht. Het technische team van CodeRabbit heeft vooraf enkele MCP-servers gemeten die meer dan 55.000 tokens aan schema verbruikten. Uit het onderzoek van Cyclr is gebleken dat schema's bij meer dan 50 tools 5-7% van een contextvenster van 200K kunnen in beslag nemen voordat het gesprek begint.

Lees die cijfers aandachtig. Vijf tot zeven procent van je context – verdwenen – voordat iemand iets heeft getypt.

Het probleem is architectonisch, niet op implementatieniveau. MCP is ontworpen vanuit de veronderstelling dat het model elk gereedschap moet zien om elk gereedschap *te kunnen gebruiken. Die veronderstelling was redelijk als agenten vier of vijf gereedschappen hadden. Het is catastrofaal als ze er veertig hebben. En veertig is niet de bovengrens; dat is ongeveer wat een enkele werkende ontwikkelaar verzamelt tussen GitHub, Slack, Linear, Sentry, hun database, hun e-mail, hun agenda en hun CMS.

Ik heb mijn eigen instellingen voorbij de zestig gereedschappen zien vliegen zonder het te proberen. Ze zien er allemaal "gratis" uit als je ze toevoegt. Elk ervan belast elk toekomstig verzoek, of u het nu gebruikt of niet.

Wanneer de hallucinaties beginnen

Dit is het deel dat de meeste artikelen begraven. Tokenkosten zijn het saaie probleem. Het interessante probleem is wat er gebeurt met de redenering van het model wanneer de aandacht zich over tientallen gereedschapsschema's moet verspreiden.

Er is een patroon dat ik nu herhaaldelijk heb gezien in zowel mijn eigen logboeken als in het gepubliceerde onderzoek. Zodra het contextgebruik ongeveer 70% overschrijdt, stort de nauwkeurigheid van de gereedschapsselectie van het model in. Het begint parameters tussen vergelijkbare tools samen te voegen. Het roept de juiste tool aan met argumenten uit het schema van een andere tool. Het bedenkt tools die niet bestaan, maar klinken zoals ze zouden moeten. En – deze is echt zenuwslopend – hij doet dit allemaal met volledig vertrouwen. De gehallucineerde oproepen lijken precies op de echte.

De benchmarks in Scalekit-stijl komen ook overeen met academisch werk. Het RAG-MCP-papier van arXiv (2505.03275) voerde een stresstest uit waarbij ze een LLM een groeiende verzameling MCP-gereedschapsbeschrijvingen gaven en zagen hoe de nauwkeurigheid van de selectie van een klif daalde. Met de volledige schemadumpbenadering (de manier waarop MCP vandaag de dag werkt) maten ze een nauwkeurigheid van 13,62% van de gereedschapsselectie. Met op retrieval gebaseerde selectie bereikte hetzelfde model voor dezelfde zoekopdrachten 43,13%. Meer dan driemaal de nauwkeurigheid met minder dan de helft van de prompttokens.

Dat is geen afstemmingsprobleem. Dat is een probleem van ‘de hele aanpak is verkeerd’.

Ik zal u het meest concrete voorbeeld geven uit mijn eigen tests. Ik had twee tools aangesloten: send_email (via Gmail MCP) en send_message (via Slack MCP). Dezelfde werkwoordstructuur. Verschillende platforms. Verschillende parametervormen. Ongeveer één op de zeven runs genereert de agent een aanroep naar send_email met de parameters channel en text van Slack. De runtime zou het afwijzen. De agent verontschuldigde zich, probeerde het opnieuw en slaagde er soms in en soms mislukte het op een andere manier. Bij elke nieuwe poging werden tokens verbrand. Elke faalwijze was uniek. Het debuggen voelde als het achtervolgen van geesten.

Toen ik terugging naar twaalf gereedschappen, daalde het uitvalpercentage tot bijna nul. Twaalf tools – voor één agent die één taak uitvoert. Dat is het praktische plafond dat MCP u biedt in de productie.

De schemafragmentatiebelasting

Hoewel de specificaties van MCP technisch gestandaardiseerd zijn, is de realiteit van het gebruik ervan bij verschillende providers in 2026 rommeliger dan de marketing suggereert.

Ik heb nu MCP-servers van minstens acht verschillende leveranciers verbonden, en ik kan je met absolute zekerheid vertellen dat "JSON-schema" een oceaan van inconsistentie verbergt. Sommige servers retourneren fouten als gestructureerde objecten. Sommige retourneren fouten als tekenreeksen die in succesvolle reacties zijn geplaatst. Some servers paginate. Sommigen niet, en stilletjes afkappen. Sommige servers respecteren het optionele veldonderscheid /required. Sommigen behandelen alles zoals vereist en breken als je iets weglaat. Authenticatie varieert van schone OAuth tot "plak dit token in een configuratiebestand en bid."

Elk van deze inconsistenties dwingt het model of de ontwikkelaar om defensieve logica te schrijven. Vermenigvuldig dat met het aantal MCP-servers dat u gebruikt, en de belofte van het 'unified protocol' verandert in 'JSON-schemasoep met adaptercode in het midden'.

Het diepere probleem is dat MCP het transport standaardiseerde, maar niet de semantiek. Twee servers kunnen beide geldige MCP zijn en zich in niets op elkaar gedragen. Dat is prima als je er een of twee hebt. Het is een integratiebelasting als je twintig hebt.

Meer bouwers dan gebruikers

Dit is het signaal waar niemand in het marketingmateriaal van MCP over wil praten. Kijk naar de registers. Puls MCP. De connectorenlijst van Anthropic. Smederij. Glama. Er zijn nu duizenden MCP-servers. De meesten van hen hebben een handvol GitHub-sterren en bijna geen echte gebruikers.

De community zit vol met mensen die MCP-servers bouwen. Er zijn verrassend weinig mensen die ze op grote schaal in productie nemen. De reden is geen mysterie; het zijn de drie problemen waar ik zojuist doorheen ben gelopen. De eerste keer dat je vijftien van deze dingen in één agent probeert te stoppen, loop je tegen de muur. Je trekt je stilletjes terug op drie of vier tools, of je verlaat MCP helemaal en gaat terug naar directe API-aanroepen, of je begint agressieve contextbeheercode te schrijven om te comprimeren wat MCP injecteert.

Ik schreef over precies dit patroon in mijn stuk over [hoe Context Mode mijn Claude Code-geheugenprobleem oploste] (https://www.mejba.me/blog/context-mode-claude-code-bloat). Contextmodus is een slimme oplossing voor dit symptoom: het verwijdert de uitvoer van het MCP-hulpprogramma uit de context nadat deze is gebruikt. Maar het lost niet het stroomopwaartse probleem op van elk schema dat bij het opstarten wordt geïnjecteerd. Het zorgt er alleen maar voor dat de bloeding de patiënt niet doodt.

Wanneer het ecosysteem van de tijdelijke oplossing groter wordt dan het protocol zelf, komt het protocol in de problemen.

De mentale modelverschuiving: van bibliotheekpas naar encyclopedie

Hier is de framing die uiteindelijk op mij klikte. MCP behandelt gereedschappen zoals boeken die u ronddraagt. Elke keer dat je een gesprek begint, stop je alle boeken die je nodig hebt in je rugzak, en dan redeneer je terwijl je verpletterd wordt door hun gewicht. Het model moet ze allemaal in overweging nemen, altijd, voor het geval dat.

Er is een duidelijk betere manier. Draag de boeken niet. Draag een index. Als u informatie nodig heeft, zoekt u op welk boek deze informatie bevat, haalt u alleen dat boek op en leest u.

Dit is het encyclopediemodel. Het model weet welke boeken bestaan – hun titels, een beschrijving van één regel, het ruwe domein – en haalt het volledige schema alleen op als een zoekopdracht er echt om vraagt. Dit is precies de architectuur die RAG (retrieval-augmentedgeneration) enkele jaren geleden heeft geïntroduceerd om Q&A te documenteren. We hebben het alleen niet toegepast op de gereedschapsselectie, omdat het originele MCP-ontwerp niet anticipeerde op de schaal.

Pas RAG toe op gereedschappen in plaats van op documenten en de wiskunde wordt omgekeerd. In plaats van dat elk gesprek begint met 40.000 tokens aan het schema, begint het met misschien 200 tokens aan de tool index. Wanneer de gebruiker om iets vraagt, haalt een vectorzoekopdracht de twee of drie relevante toolschema's op, deze worden in de context geïnjecteerd en het model kiest er één. Het aantal hallucinaties neemt af omdat het model niet verdrinkt in gelijksoortige opties. De tokenkosten dalen omdat u betaalt voor wat u gebruikt en niet voor wat u zou kunnen gebruiken. Het aantal gereedschappen wordt feitelijk onbeperkt.

Karpathy wijst al een tijdje op verwante ideeën - ik heb enkele van zijn RAG-architectuurideeën besproken toen ik schreef over [het bouwen van een persoonlijke RAG-kennisbank in Obsidian] (https://www.mejba.me/blog/karpathy-obsidian-rag-knowledge-base). Gereedschap is gewoon een ander soort terug te vinden artefact. Zo moeten we ze behandelen.

Voer Corsair in

Corsair is een open-sourceproject op GitHub (github.com/corsairdev/corsair) dat precies dit patroon implementeert. Ik ga nog niet doen alsof het een gepolijst product is; dat is het niet. De repo is jong, de documenten zijn dun en de gemeenschap is klein. Maar de architectuur is het eerlijkste antwoord dat ik heb gezien op de vragen die MCP niet kan beantwoorden.

Hier ziet u hoe het op mechanisch niveau werkt.

U installeert Corsair als laag tussen uw agent en uw tools. Het wordt geleverd met een catalogus met plug-indefinities voor algemene services: Slack, Gmail, GitHub, Google Agenda en er worden er nog meer toegevoegd. De metagegevens van elke plug-in bevinden zich in een vectorindex. Wanneer uw agent een vraag krijgt, voert Corsair eerst een semantische zoekopdracht uit in de plug-incatalogus, haalt alleen de relevante toolschema's van de plug-in op en stelt deze bloot aan het model. Al het andere blijft buiten de context.

Voor de agent lijkt Corsair op een klein aantal metatools: doorzoek de catalogus, haal een plug-in op, voer een oproep uit. Voor jou als ontwikkelaar is het blootleggen van twintig integraties grofweg één regel code. De complexiteit zit binnen de runtime van Corsair, waar deze thuishoort.

Het referentiemodel is het onderdeel dat ik het meest waardeerde. Corsair slaat authenticatie lokaal op in een database in het bestand. Geen verplichte cloudrelay. Geen dashboard van derden dat uw OAuth-tokens beheert. Als u uw persoonlijke Gmail en de GitHub van uw klant met dezelfde agent wilt verbinden, blijven de geheimen op uw machine. Voor iedereen die agents heeft gebouwd die gevoelige systemen aanraken, is dit belangrijker dan welke functiespecificatie dan ook.

Het verschil in ontwikkelaarservaring

Laat me het contrast concreet maken met hoe een typische bedradingsklus bij elke aanpak aanvoelt.

Onder MCP is het toevoegen van een dienst een ceremonie die uit meerdere stappen bestaat. Vind de juiste MCP-server. Lees de README ervan. Configureer het in uw client (Claude Desktop, Cursor, aangepaste runtime - ze verschillen allemaal enigszins). Authenticeren. Start uw klant opnieuw op. Test. Realiseer je dat een parameter een iets andere naam heeft dan de documenten zeggen. Foutopsporing. Realiseer je dat het antwoordformaat van de server niet overeenkomt met de standaard. Schrijf defensieve parsering. Opnieuw opstarten. Doe dit nu voor de volgende onderhoudsbeurt. En de volgende.

Onder het ophaalpatroon in Corsair-stijl komt het toevoegen van een service dichter bij "de plug-in registreren, de inloggegevens opslaan, klaar." De agent hoeft niet opnieuw te worden geconfigureerd. Het contextvenster groeit niet. Niets anders in het systeem hoeft dit te weten.

Ik wil hier precies zijn, omdat ik echt probeer niet te veel te verkopen. Corsair is specifiek vroeg. De plug-incatalogus is klein. Je zult ruwe randen tegenkomen als je het vandaag voor iets niche probeert te gebruiken. Maar het patroon – RAG-gestuurde tool retrieval – is waar elk serieus agent-infrastructuurproject waar ik naar heb gekeken naar toe convergeert. Anthropic zelf publiceerde onlangs onderzoek naar lazy schemaloading en dynamic tool gating. Het arXiv-artikel "Tool Attention Is All You Need" (2604.21816) maakt hetzelfde architecturale argument vanuit een andere hoek. De richting is bepaald, ook al is de leidende implementatie nog niet volledig uitgekristalliseerd.

Waar MCP nog steeds zinvol is

Ik wil eerlijk zijn, omdat ik denk dat veel "X is dead"-posts hun zaak overdrijven en de geloofwaardigheid verliezen. MCP is niet nutteloos. Het is gewoon slecht geschikt voor de schaal waar de meesten van ons naartoe streven.

MCP is echt goed als je een kleine, vaste, samengestelde set tools hebt (bijvoorbeeld drie tot zeven) waartoe je wilt dat elk gesprek toegang heeft. Het schema-upfront-model is prima op die schaal. De latentie is laag. De aandacht van het model heeft ruimte om zich te verspreiden zonder te breken. De standaardisatievoordelen van het protocol wegen zwaarder dan de overhead. Als je een gerichte agent bouwt die één ding doet (een code-reviewer met drie tools, een schrijfassistent met vier), is MCP prima. Het is mogelijk het juiste antwoord.

MCP is ook zinvol als backend. Je kunt je voorstellen dat ophaalsystemen zoals Corsair MCP onder de motorkap gebruiken voor de daadwerkelijke aanroep van het gereedschap, terwijl de ontdekkingslaag erboven op ophaalprincipes werkt. Het protocol wordt een infrastructuur in plaats van een gebruikersgericht model. Dat is waarschijnlijk waar dit allemaal op de lange termijn terechtkomt.

Waar MCP niet goed voor is, is het eigenlijke werk dat de meeste ambitieuze agenten moeten doen: coördineren tussen tientallen diensten, dynamisch bepalen welke tools relevant zijn voor welke taak, en onder de drempel voor contextgebruik blijven waar de redenering instort. Voor die werklast is het schema-injectiemodel structureel verkeerd, en geen enkele hoeveelheid contextcompressie kan dit redden.

Wat ik nu doe

Ik heb mijn eigen agenteninfrastructuur in twee sporen opgesplitst. Voor agenten met een strak bereik en een enkel doel (mijn codebeoordelingsbot, mijn screenshot-naar-CSS-converter, mijn e-mailtriageagent) blijf ik op MCP. Drie tot vijf gereedschappen elk. Geen ophaalactie nodig. Het protocol werkt.

Voor mijn algemene operations-agent (degene die e-mail, agenda, GitHub, mijn CMS, mijn analyses, mijn CRM en een tiental andere systemen moet aanraken) ben ik overgestapt op een op retrieval gebaseerde architectuur. Corsair-stijl vandaag, mogelijk iets volwassener over zes maanden. Alleen al de symbolische rekening rechtvaardigde de migratie. De scherpe daling van het aantal gehallucineerde toolcalls rechtvaardigde dit twee keer.

Het mentale model dat ik nu op elke nieuwe agent toepas, is dit: hoeveel tools heeft hij nodig? Als het antwoord 'vijf of minder, ooit' is, is MCP prima. Als het antwoord luidt: 'Ik weet het echt niet en waarschijnlijk meer dan tien', reik ik naar de ophaalmogelijkheid. Naar mijn ervaring ligt het crossover-punt ergens rond de acht tools, en het is niet sierlijk: de prestaties gaan snel achteruit als je er eenmaal overheen bent.

Dat ene beslissingspunt heeft mij uren bespaard van het debuggen van gehallucineerde oproepen en instortingen van redeneringen. Ik wou dat iemand het een jaar geleden aan mij had overhandigd.

Veelgestelde vragen

Is MCP eigenlijk dood of worstelt het gewoon op schaal?

MCP is niet dood voor kleine, gefocuste agenten met drie tot zeven tools: daar werkt het prima. Het is functioneel dood voor agenten voor algemene doeleinden die toegang nodig hebben tot tientallen diensten, omdat schema-injectie een opgeblazen gevoel in de context veroorzaakt en hallucinaties over gereedschapsselectie die op retrieval gebaseerde benaderingen netjes oplossen. De meeste productieteams zijn stilletjes aan het hybridiseren.

Wat is Corsair en is het klaar voor productie?

Corsair is een open-source integratielaag voor AI-agents (github.com/corsairdev/corsair) die RAG gebruikt om dynamisch alleen relevante toolschema's per query op te halen in plaats van ze allemaal vooraf te injecteren. Het is nog vroeg (kleine plug-incatalogus, evoluerende documenten) maar het architecturale patroon dat het vertegenwoordigt is waar de serieuze agent-infrastructuur op convergeert.

Waarom maakt het toevoegen van meer MCP-tools agenten slechter?

Elke MCP-tool injecteert 550-1.400 tokens van het schema in de context bij het begin van het gesprek. Bij de afgelopen 50 tools neemt dit 5-7% van een contextvenster van 200K in beslag voordat de vraag van de gebruiker zelfs maar arriveert. Zodra het contextgebruik ongeveer 70% overschrijdt, versnippert de aandacht van het model over op elkaar lijkende tools, stijgt het aantal hallucinaties en neemt de nauwkeurigheid van de toolselectie af.

Hoe verbetert RAG-MCP de nauwkeurigheid van de gereedschapsselectie?

Uit het RAG-MCP-paper (arXiv 2505.03275) bleek dat op retrieval gebaseerde gereedschapsselectie een nauwkeurigheid van 43,13% behaalde, tegenover 13,62% voor de basislijn voor schema-injectie op dezelfde benchmark – meer dan drie keer zoveel nauwkeurigheid met minder dan de helft van de prompttokens. Het model ziet alleen de tools die relevant zijn voor de huidige zoekopdracht, zodat de aandacht niet gefragmenteerd is.

Moet ik nu meteen migreren van MCP naar een op retrieval gebaseerde aanpak?

Als uw agent minder dan acht tools gebruikt en goed werkt, blijf dan. Als je last hebt van hallucinatie-uitbarstingen, de tokenkosten moet stijgen of van plan bent om voorbij de tien tools te schalen, begin dan nu met het prototypen van een ophaallaag zoals Corsair. Het crossover-punt is niet mooi: de prestaties gaan snel achteruit als je er eenmaal overheen bent, en de migratie is eenvoudiger voordat je productieverkeer hebt, afhankelijk van de oude architectuur.

Laten we samenwerken

Wilt u AI-systemen bouwen, workflows automatiseren of uw technische infrastructuur schalen? Ik help je graag.

• Fiverr (aangepaste builds en integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (ondernemingsoplossingen): ramlit.com
• ColorPark (ontwerp en branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io