AI-agentkosten verlagen: zo filter je MCP-tools vóór de prompt

Sophie Jansen · 2026-08-13

AI-agenten zijn krachtig, maar ze hebben een verborgen prijskaartje. Elke keer dat een agent een model aanroept, stuurt het niet alleen de vraag mee, maar ook een complete lijst van alle beschikbare tools. Die lijst bevat schema's, namen, beschrijvingen en parameters – ook van tools die de agent nooit zal gebruiken. Okta noemt dit de 'tool tax': tokens die worden verbruikt terwijl het model overweegt welke tools het zou kunnen inzetten. Het probleem is dat deze kosten al vóór de daadwerkelijke toolaanroep ontstaan. Een controle die een ongeautoriseerde aanvraag later afwijst, kan die verbruikte tokens niet meer terugverdienen. De oplossing van Okta? Tools filteren vóórdat ze het model bereiken, op basis van de rechten van de agent en de gekoppelde gebruiker. ## Waarom MCP-toolschema's elke beurt duurder maken MCP-servers (Model Context Protocol) zijn inmiddels een standaardroute om AI-agenten te verbinden met tools en data. Denk aan koppelingen met Google Workspace, Slack of interne bedrijfssystemen. Een MCP-server kan tientallen of zelfs honderden tools blootleggen. En het model ontvangt bij elke beurt een representatie van elke beschikbare tool in zijn prompt. Die representatie omvat dus: - Het toolschema met alle parameters - De naam van de tool - Een beschrijving van wat de tool doet - De parameters die de tool verwacht De kosten stapelen zich op wanneer een veelgebruikte MCP-server veel tools exposeert. Elke actieve gebruiker betaalt deze overhead bij elke modelaanroep. Het is dus zowel een tool-probleem als een gebruikers-probleem. Hoe meer tools, hoe meer gebruikers, hoe hoger de rekening. En er zit nog een access-control-dimensie aan vast. Een agent die tools ziet buiten zijn autorisatie, kan proberen ze te gebruiken. Een runtime-controle kan de uitvoering blokkeren, maar het model heeft de tooldefinitie al ontvangen en tokens verbruikt om die te verwerken. ## Okta filtert tools vóór de prompt wordt opgebouwd Okta plaatst deze functionaliteit binnen zijn 'blueprint voor de secure agentic enterprise'. Die blueprint vraagt organisaties om drie dingen in kaart te brengen: welke agenten ze hebben, welke verbindingen zijn toegestaan, en welke acties geautoriseerd zijn. De aanpak van Okta versmalt de verbindingsvraag van 'toegang tot een hele MCP-server' naar 'toegang tot individuele tools op die server'. Een beheerder configureert in het Okta-dashboard welke tools een bepaalde identiteit mag gebruiken. Vervolgens retourneert Okta alleen de gescoopte toolset, niet de volledige catalogus van de server. De agent ontvangt deze kortere lijst bij elke beurt in zijn prompt. Daarnaast controleert Okta de scope opnieuw bij runtime, vóórdat een toolaanroep wordt uitgevoerd. Dit ontwerp past het principe van least-privilege toe op toolniveau. Het uitgangspunt is simpel: een agent zou geen weet moeten hebben van resources, databases of tools waarvoor hij geen expliciete autorisatie heeft. Door niet-beschikbare tools uit de prompt te verwijderen, verdwijnen ook de bijbehorende schemakosten uit de modelaanroep. ## Wat de interne modellering laat zien Okta beschrijft in de blogpost geen live klantimplementatie. Het bewijs voor de kostenreductie komt uit interne modellering, gebaseerd op Okta-productdata en publieke vendordocumentatie. Klantdata is niet gebruikt. Het model simuleerde een enkele MCP-client met toegang tot een catalogus van enterprise-tools. Okta vergeleek het aantal zichtbare tools vóór en na identity-based scoping. Om de gescoopte blootstelling te schatten, koppelde het bedrijf Okta MCP Server-tools aan de OAuth-scopes die ze ontgrendelen. Daarna definieerde Okta representatieve gebruikerssegmenten, waaronder: - Helpdesk-gebruikers met alleen-lezen rechten - Helpdesk-operators - Applicatiebeheerders - Merk- en e-mailbeheerders - Superbeheerders Elk segment kreeg een gewicht op basis van een aangenomen aandeel in het maandelijkse verkeer. De toolcount-reductie berekende Okta als één minus de verhouding tussen gescoopte en niet-gescoopte tools. In sommige scenario's verdween meer dan 90% van de tools uit de prompt. De implicatie is duidelijk: door identiteitsgebaseerde filtering toe te passen, kunnen organisaties de tokenkosten van hun AI-agenten aanzienlijk verlagen. De tool-schemakosten daalden volgens Okta ongeveer in dezelfde verhouding, al gaf het bedrijf geen absolute cijfers in tokens of euro's. Voor organisaties die met AI-agenten werken, is dit een belangrijke overweging. Het gaat niet alleen om beveiliging, maar ook om kostenbeheersing. Door tools te scopen op basis van identiteit, bespaar je op twee fronten tegelijk.