Ontwikkelaars die lokale large-language models (LLM's) gebruiken, ontdekken dat een enkele Multi-Channel-Protocol (MCP) server het volledige contextvenster kan opslokken nog voordat een gebruiker een prompt typt. Ze moeten kiezen tussen beperkte toolbeschrijvingen of een verstoorde conversatiestroom.

Waarom token-bloat belangrijk is voor lokale LLM's

MCP stelt een LLM in staat om externe tools aan te roepen — API's, scripts of bestandssysteemhulpprogramma's — door het model een beschrijving van elke tool te voeren. In de cloud gehoste modellen met vensters van 128k tokens kunnen veel tool-definities absorberen en hebben nog steeds ruimte over voor de dialoog met de gebruiker. Een model met 7 miljard parameters dat lokaal draait met een venster van 8k tokens, raakt de ruimte kwijt na het laden van slechts een paar tools. De afweging is groot: korte, goedkope beschrijvingen leiden tot verkeerde aanroepen; lange, gedetailleerde beschrijvingen verbruiken het budget dat nodig is voor de chat.

De keten van gebeurtenissen die hiertoe heeft geleid

MCP is ontwikkeld om aangepaste integratiecode te vervangen door een enkele, modelgestuurde interface voor vele gegevensbronnen. De meeste MCP-servers fungeren als dunne wrappers rond REST-endpoints die bedoeld zijn voor menselijke operators, niet voor machines. Wanneer deze wrappers in een lokale LLM-sessie worden gebruikt, moet het model de naam, parameters en gebruiksaanwijzingen van elke tool lezen voordat het kan beslissen welke hij moet aanroepen. Kleine contextvensters veranderen deze "beschrijvingsoverhead" in een structurele flessenhals.

Wie wint, wie verliest

  • Ontwikkelaars die on-device assistenten bouwen verliezen flexibiliteit. Ze snoeien ofwel in de tool-catalogi, met het risico op frequente fouten, of ze accepteren een opgeblazen prompt die de invoer van de gebruiker afkapt.
  • Eindgebruikers ervaren onbetrouwbaar gedrag wanneer de assistent de verkeerde tool selecteert of weigert actie te ondernemen omdat de context vol is.
  • Tool-providers krijgen een uniform toegangspunt.

De prijs is niet alleen een slechtere ervaring; het roept ook beveiligingszorgen op. Wanneer een MCP-agent elk lokaal bestand kan lezen, stort het machtigingsmodel in tot "alles-of-niets". Zonder sandbox kan een verkeerd geconfigureerde tool het hele bestandssysteem blootstellen.

Wat ontwikkelaars eraan doen

Drie oplossingen domineren de community:

  • Beschrijvingen inkorten – Verwijder tool-metadata tot het absolute minimum. Dit maakt tokens vrij, maar vergroot de kans dat het model het verkeerde endpoint kiest, wat leidt tot fouten die ontwikkelaars moeten opvangen en opnieuw moeten proberen.
  • Dynamisch laden – Laad alleen de subset van tools die relevant is voor de huidige conversatie. Een lichtgewicht dispatcher beslist op basis van de intentie van de gebruiker welke set tools moet worden geïnjecteerd. Dit vermindert het onnodige tokenverbruik, maar voegt latentie en codecomplexiteit toe.
  • Actieve servers beperken – Beperk het aantal MCP-servers per sessie, waardoor ontwikkelaars gedwongen worden de meest essentiële integraties prioriteit te geven. Dit houdt de grootte van de prompt beheersbaar, maar offert de breedte van de mogelijkheden op.

Geen van deze oplossingen is een wondermiddel. Het inkorten van beschrijvingen schaadt de betrouwbaarheid; dynamisch laden voegt een beslissingslaag toe die reacties vertraagt; het beperken van servers dwingt tot moeilijke keuzes over welke gegevensbronnen worden ondersteund.

Beveiligingsrisico's die voortvloeien uit het token-probleem

Lokale agenten draaien vaak met onbeperkte toegang tot het bestandssysteem. Het MCP-protocol biedt geen granulariteit tussen "lees deze map" en "lees alles". Sommige teams hebben gateway-lagen gebouwd om het probleem van volledige toegang op te lossen, wat meer complexiteit toevoegt. Deze gateways verzachten het "volledige controle"-probleem, maar vergroten ook de codebase.

Tools ontwerpen voor kleine modellen

Grote cloudmodellen kunnen omgaan met slechte beschrijvingen, waardoor ontwikkelaars soms de noodzaak van nauwkeurige tool-definities over het hoofd zien. Volg voor lokale modellen deze principes:

  • Beperkte functionaliteit – Elke tool moet één ding doen. Een "zoek"-tool die ook bestanden schrijft, zal een model in verwarring brengen dat geen overlappende verantwoordelijkheden kan bijhouden.
  • Eenduidige naamgeving – Vermijd generieke namen zoals "process" of "handle". Namen moeten de exacte operatie overbrengen, wat de mentale belasting van het model vermindert.
  • Duidelijke, beknopte beschrijvingen – Neem alleen de parameters op die het model echt nodig heeft om een beslissing te nemen. Gebruik een consistent formaat zodat het model patronen snel kan herkennen.

Tegenargument: het protocol heeft nog steeds waarde

Ondanks de wrijving blijft MCP aantrekkelijk omdat het boilerplate-code abstraheert. Een enkele, modelgestuurde interface kan verbinding maken met tientallen services zonder voor elk een aangepaste adapter te schrijven. Teams die cloud-schaal modellen kunnen betalen, zien token-bloat als een niet-bestaand probleem, en het gemak weegt zwaarder dan de overhead. De uitdaging is om dat gemak te vertalen naar de beperkte wereld van on-device LLM's.

Kernpunt

Als je een on-device assistent bouwt, behandel MCP-toolbeschrijvingen dan als een schaarse hulpbron. Trim ze, laad ze dynamisch en ontwerp tools met een beperkte scope om het contextvenster vrij te houden voor het eigenlijke gesprek. Zorg tegelijkertijd voor bescherming tegen het impliciete "full-access" beveiligingsmodel door een permissielaag in te voegen, zelfs als dat een paar extra tokens kost. De balans die je vindt, zal bepalen of je lokale LLM aanvoelt als een behulpzame metgezel of een defecte chatbot.