MCP of CLI: wat de tools van je agent echt kosten

Zoek op "MCP vs CLI" en je krijgt een muur van factoren. Een CLI is 4x goedkoper. 10x. 32x. 137x. Elke post noemt een getal, elk getal komt uit één benchmark, en geen twee benchmarks zijn het eens.

Dus heb ik het zelf gemeten. Ik heb elke server op deze machine rechtstreeks via MCP aangesproken, om zijn tool-lijst gevraagd en de bytes geteld.

Negenenveertig tools. 72.612 tekens aan tool-definities, tegenover 817 tekens als je niets anders opsomt dan de namen. Dat is 88,9x, en dat valt precies binnen de bandbreedte die iedereen citeert.

De vorm klopt. Alleen beantwoordt het getal een vraag van vorig jaar.

Wat die bytes werkelijk zeggen ​

Dit is de meting. De servers zijn geanonimiseerd, want het zijn de mijne en hun namen doen er niet toe.

De tekens zijn exact. De tokens zijn een schatting van ongeveer vier tekens per token, en die heb ik geijkt in plaats van gegokt: MCP-issue #2808 mat in mei 2026 elf tools van de context-mode-plugin via Anthropics token-counting-API, en als ik diezelfde elf tools hier opnieuw meet kom ik uit op 4,11. Lees de tokenkolom dus als een afgerond getal met een echte methode erachter.

Er vallen twee dingen op die in de factor-posts ontbreken.

Het schema is de kostenpost. Van die 72.612 tekens gaan er 11.911 op aan de leesbare tool-beschrijvingen. Zestien procent. De rest is JSON Schema: parameternamen, geneste types, enums, constraints. Het gangbare advies om je tool-beschrijvingen korter te maken richt zich dus op een zesde van het probleem. Issue #2808 kwam van de andere kant bij hetzelfde uit, met bijna een factor tien verschil tussen de goedkoopste en de duurste tool binnen één server, en de conclusie dat "the 10x delta is entirely in JSON Schema size".

Het aantal tools is de verkeerde maatstaf. Mijn server met drie tools kost 5.440 tekens per tool. Die met 33 tools kost er 1.359. Een server met een tiende van de tools kan per tool vier keer zo duur zijn, omdat er één bij zit die een diep genest object aanneemt terwijl de rest een string wil. Tools tellen zegt bijna niets over wat een server je kost.

De client is allang verdergegaan ​

Het hele MCP-is-duur-argument steunt op één aanname: elk schema staat in je prompt voordat je iets hebt getypt. Dat klopte toen die benchmarks gedraaid werden, en ik heb die som hier eerder gemaakt: een volgestapelde installatie kwam toen eerlijk geteld uit op zo'n elfduizend tokens overhead voordat er ook maar iets gedaan was.

Anthropic publiceerde de oplossing in november 2025. De post over code-executie van 4 november betoogde dat een agent tool-definities moet lezen zoals hij bestanden leest, op het moment dat hij ze nodig heeft, en zette de besparing op 98,7%, van 150.000 tokens naar 2.000. De post over advanced tool use van 24 november leverde het mechanisme onder de naam Tool Search Tool, en hun eigen cijfers over hun eigen opstelling zijn het lezen waard: "That's 58 tools consuming approximately 55K tokens before the conversation even starts", en nog directer: "At Anthropic, we've seen tool definitions consume 134K tokens before optimization."

Op 17 februari 2026 hield het op een experiment te zijn. In de release notes kwam te staan dat de code execution tool, web fetch tool, tool search tool, tool use examples en memory tool "no longer require a beta header". Tien maanden na de aankondiging is het de standaard in de client waarin ik dit zit te typen. Claude Code 2.1.260 kent per server een alwaysLoad-instelling, in de binary omschreven als:

When true, all tools from this server are always included in the prompt and never
deferred behind tool search. Equivalent to setting defer_loading: false on the API.
Default: tools are deferred when tool search is enabled.

Lees die laatste regel twee keer. Uitstel is wat je krijgt, en alwaysLoad is hoe je het per server uitzet, op het moment dat je de tools van die server vanaf beurt één in je prompt wilt hebben.

In deze sessie kwamen alle 49 tools binnen als kale namen. Om er daadwerkelijk bij te komen betaalde ik een zoekopdracht en een paar duizend tokens voor de drie of vier schema's die ik echt nodig had. Die 88,9x die ik mat is het gat tussen wat een server aanbiedt en wat een client besluit te versturen, en mijn client verstuurt de namen.

Wat uitstel in plaats daarvan kost ​

De tokens zijn niet verdampt. Ze zijn round trips geworden.

Een tool die altijd geladen is, is één aanroep. Een uitgestelde tool is een zoekopdracht en daarna een aanroep, en die zoekopdracht kan ernaast zitten: hij matcht op namen en beschrijvingen, precies die zestien procent waarvan ik net zei dat het de kostenpost niet was. Je betaalt nu in aandacht en wachttijd wat je eerst in context betaalde.

Er is een derde kostenpost, en die vond ik alleen omdat de mensen die over het protocol steggelen er eerder waren. In diezelfde MCP-discussie merkte een collaborator op 26 augustus op dat uitstel "doesn't deal with prompt cache invalidation, where even models that support lazy loading of tools bust the prompt cache if" de lijst met tool-definities verandert, "even if defer loading is true on them all". Je schema's kunnen dus uitgesteld zijn terwijl je cache toch koud staat, want elke wijziging in de verzameling tool-definities maakt hem ongeldig, hoe klein die verzameling ook is. Start je halverwege een sessie een server op, dan heb je daarvoor betaald.

Diezelfde binary is eerlijk over de andere kant van die ruil. De omschrijving van alwaysLoad gaat verder: de instelling "also blocks startup until the server is connected (capped at the standard 5s connect timeout) even though MCP startup is otherwise non-blocking by default, since the tools must be present when the turn-1 prompt is built". Tokenkosten en opstarttijd zitten aan dezelfde knop. Zet je de tools van een server vast in je prompt, dan heb je meteen besloten dat je op die server wacht voordat je eerste bericht de deur uit kan.

De tools die er stilletjes niet zijn ​

Dit is het deel dat ik niet verwachtte te vinden, en de reden dat deze post niet alleen over tokens gaat.

Claude Code laat MCP-tools vallen waar hij niets mee kan. De binary heeft er twee meldingen voor. De ene noemt de tool bij naam: "toolName" (MCP server "X"): "reason". De andere is een samenvatting die luidt MCP server "X": 12 tools excluded (invalid input schema). De grens ertussen is een constante die op 30 staat. Bij minder dan dertig geschrapte tools uit één server hoor je welke en waarom. Daarboven krijg je alleen een getal.

Een server kan dus een tool aanbieden die jouw client nooit aan het model voorlegt, omdat het schema iets gebruikt wat die client niet accepteert. Jouw tool-lijst en de tool-lijst van de server zijn twee verschillende lijsten, en het detailniveau van de melding daarover neemt af naarmate het probleem groter wordt.

Dat is een betrouwbaarheidseigenschap, en het enige wat een CLI werkelijk niet heeft. git commit verdwijnt niet uit beeld omdat zijn argumentparser te barok was.

Een CLI is ook niet gratis ​

Het argument voor de CLI wordt meestal gebracht alsof commando's niets kosten. Ze rekenen af bij het ontdekken.

Een agent die jouw CLI nog nooit gebruikt heeft, moet hem leren, en dat doet hij door --help te draaien en de uitvoer in zijn context te lezen. Op deze machine is gh --help 2.007 tekens en gh pr --help nog eens 1.433. Twee keer help voor één taak is grofweg duizend tokens, betaald in de sessie waarin je het gebruikt, en opnieuw betaald in de volgende sessie tenzij iemand het heeft opgeschreven.

Het echte voordeel van een CLI is dat het model git, gh, docker en psql al uit zijn training kent. Voor het gereedschap dat iedereen gebruikt betaal je dus niets, en voor dat van jezelf de volle prijs. Een CLI die je vorige maand schreef staat er precies zo voor als een MCP-server: een ongedocumenteerde interface, die de agent tijdens het draaien moet ontdekken, en nu via een kanaal zonder schema, zodat hij de flags mis kan hebben en dat pas merkt aan een exitcode die niet nul is.

Dat is de ruil, eerlijk opgeschreven. MCP geeft je een exacte, machinaal gecontroleerde interface en rekent die af in je prompt, of in een extra round trip. Een CLI geeft je wat het model toch al wist en rekent alles af wat het nog niet wist.

Welke dan ​

De bruikbare vraag is wat een tool kost als de agent hem negeert, en wat hij kost als de agent ernaar grijpt.

• Het model kent de interface al. Neem de CLI. gh, git, kubectl, psql. Die in een MCP-server verpakken levert je een schema op voor iets wat geen schema nodig had.
• Je hebt authenticatie, een remote service of een audit trail nodig. Neem MCP. OAuth, een permissiebeleid per tool en een server waar je een grens omheen kunt leggen krijg je niet van een shell-commando, en met tokens heeft dat allemaal niets te maken.
• Je gebruikt hem elke sessie. Zet alwaysLoad op die ene server en neem de wachttijd bij het opstarten voor lief. De rest blijft uitgesteld.
• Je staat op het punt er zelf een te bouwen. De test is niet veranderd: moet dit ding bestaan. Uitstel maakt een overbodige server goedkoop om te houden, en goedkoop is nog geen reden om hem te houden. Hij draait nog steeds, hij heeft nog steeds een supply chain, en je moet hem nog steeds controleren, of zijn schema vandaag wel of niet in je prompt staat.

En meet je eigen installatie, want jouw servers zijn de mijne niet. Vraag elke server om tools/list, tel de tekens en kijk naar de spreiding per tool in plaats van naar het aantal tools.

Het protocol komt pas nu in beweging ​

Elke oplossing hierboven zit in de client. Het protocol levert nog altijd het volledige schema van alles: toen ik die vier servers om hun tool-lijst vroeg, kreeg ik 72.612 tekens, want dat is het enige wat tools/list teruggeeft.

Dat gat is bekend en er wordt al een tijd over gesteggeld. Issue #2808 werd op 28 mei 2026 ingediend en een dag later door een maintainer omgezet in een discussie. Discussie #1923, "Progressive Tool Discovery for Token Efficiency", staat sinds 3 december 2025 open en kreeg een week voordat deze post verscheen nog reacties. SEP-2636, "Progressive Tool Disclosure", staat sinds 23 april 2026 open en werd voor het laatst bijgewerkt op 3 september, de dag voordat ik dit publiceerde. De spec staat nog op revisie 2026-07-28, en daar staat niets van dit alles in.

Wat wel veranderde, is de intentie. De roadmap van 22 augustus tilt het uit het discussiedraadje en zet het op de agenda: een Core Primitives-werkgroep rond progressive discovery, zodat "clients learn a server's tools and resources as they need them instead of ingesting the full catalog up front". Dat is precies de truc uit deze post, nu opgeschreven als iets wat het protocol zelf hoort te doen.

De besparing waar je vandaag van profiteert komt dus van je client. Je kunt hem kwijtraken door van client te wisselen, door een server vast te pinnen, of door een update die een drempelwaarde bijstelt waarvan je niet wist dat hij bestond, en over een release of twee is hij misschien niet eens meer van jou, omdat het protocol hem overneemt. Handig om te weten voordat je een werkende MCP-server herschrijft als CLI op gezag van een factor die iemand anders mat, op een andere client, in een andere maand, en in zijn eigen voordeel afrondde.

De tools zijn goedkoper dan de benchmarks beweren. Ze zijn ook minder blijvend dan ze lijken, en de context waarin ze staan blijft het budget waar al het andere in moet passen.