Tool Calling

Wat is Tool Calling?

Tool calling is het vermogen van een taalmodel om externe functies aan te roepen, zoals een commando draaien, een API bevragen, of een bestand lezen, in plaats van alleen tekst te genereren. Het model geeft een gestructureerd verzoek af dat een tool en zijn argumenten noemt, de hostapplicatie voert het uit, en het resultaat voedt terug in de volgende stap van het model.

De belangrijkste punten

• Het model voert nooit zelf iets uit. Het produceert een gestructureerde intentie, typisch JSON dat een functie en argumenten noemt, en de omringende applicatie voert de daadwerkelijke aanroep uit.
• Tool calling is het mechanisme dat een taalmodel in een agent verandert. De lus van aanroepen, resultaat observeren, volgende actie beslissen is de motor onder elk agentic systeem. Adoptie weerspiegelt die verschuiving: LangChains LangSmith-platformdata toonde 21,9% van LLM-traces met tool-aanroepen in 2024, tegenover een gemiddelde van 0,5% in 2023 [1].
• Tools worden gedefinieerd door schema's plus beschrijvingen, en de beschrijvingen worden door het model gelezen, dus is ze schrijven net zoveel prompt engineering als API-ontwerp.
• Elke tool is aanvalsoppervlak. Wat een tool ook kan doen, een gemanipuleerd model kan het doen, en daarom staan rechten en sandboxing naast tool calling in productiesystemen.

Hoe het werkt

De applicatie declareert beschikbare tools in het verzoek, elk met een naam, een natuurlijke-taal-beschrijving, en een parameterschema, meestal JSON Schema. Tijdens generatie kan het model ervoor kiezen te antwoorden met een tool-aanroep in plaats van proza: een gestructureerd blok dat de tool noemt en argumenten levert die bij het schema passen. Aanbieders trainen modellen specifiek hiervoor, dus is goed gevormde aanroepen afgeven een native capaciteit van elke grote modellijn in 2026, onder de verwisselbare namen tool use en function calling. De vaardigheid wordt op zichzelf benchmarkt: UC Berkeleys Function Calling Leaderboard evalueert modellen op 2.000 vraag-functie-antwoord-paren over Python, Java, SQL, REST-API's, en JavaScript over negen categorieën [2].

Uitvoering hoort bij de host. De applicatie ontvangt de aanroep, draait de echte functie, en voegt het resultaat toe aan het gesprek als een toolresultaatbericht. Het model leest het en gaat verder: de gebruiker antwoorden, een andere tool aanroepen, of verschillende aanroepen in sequentie ketenen. Moderne modellen behandelen parallelle aanroepen, meerdere onafhankelijke tools tegelijk verzoeken, en meerstaps-sequenties waar elke aanroep afhangt van het vorige resultaat. Die lus, redeneer dan handel dan observeer, is het patroon geformaliseerd door ReAct-achtige agents en geërfd door elke coding-agent sindsdien.

Twee lagen zitten er meestal bovenop. Model Context Protocol standaardiseert waar tooldefinities vandaan komen, en laat servers van derden tools op runtime leveren in plaats van ze hard te coderen in de applicatie. En omdat argumentgeneratie gewoon beperkte tekstgeneratie is, ondersteunen aanbieders het steeds meer met strikte schemahandhaving, dezelfde machinerie achter structured outputs, zodat aanroepen betrouwbaar parsen in plaats van te falen op misvormde JSON.

Voorbeeld

Een gebruiker vraagt een engineeringassistent: "waarom piekte checkout-latentie om 14u?" De applicatie heeft het model drie tools gegeven: query_metrics, search_logs, en list_deploys. Het model roept eerst list_deploys aan met de servicenaam en een tijdsbereik, ziet een deploy om 13:52, roept dan query_metrics aan om te bevestigen dat de piek minuten later begon, en roept dan search_logs aan gefilterd op de nieuwe release en vindt connection-pool-uitputtingsfouten. Pas na drie aanroep-en-observeer-rondes produceert het proza: de deploy verkleinde de poolgrootte, hier is de schuldige configuratiewijziging. Geen enkele completion had dat kunnen beantwoorden; de toollus deed het.

Veelvoorkomende misvattingen

De hardnekkige misvatting is dat het model de tools draait, wat mensen ertoe brengt ofwel het risico van het model zelf te overschatten ofwel de verantwoordelijkheid van de applicatie te onderschatten. Het model geeft alleen ooit een verzoek af. Jouw code beslist of het uitgevoerd wordt, met welke credentials, in welke omgeving, en met welke menselijke goedkeuring. Die grens is precies waar AI-agentbeveiliging wordt afgedwongen: validatie van argumenten, least-privilege-credentials, en bevestigingspoorten voor destructieve acties leven allemaal in de dunne laag tussen het verzoek van het model en de echte functie.

FAQ

Is function calling hetzelfde als tool calling? Ja. Function calling was OpenAI's originele naam voor de functie in 2023, en tool calling werd de bredere industrieterm naarmate capaciteiten uitbreidden voorbij simpele functies. Documentatie gebruikt de termen door elkaar.

Wat is de relatie tussen LLM-toolgebruik en MCP? Toolgebruik is de modelniveau-capaciteit; het Model Context Protocol is een distributiestandaard voor tools. MCP-servers adverteren toolschema's aan de applicatie, die ze doorgeeft aan het model als elke andere tooldefinitie. Het model kan het verschil niet zien tussen een ingebouwde tool en een MCP-geleverde.

Hoeveel tools kan een model aan? Er is geen harde limiet, maar selectienauwkeurigheid verslechtert naarmate toolaantallen groeien, want elke definitie verbruikt context en vergelijkbare tools vervagen samen. Productiesystemen cureren kleine, goed beschreven toolsets per taak, of doorzoeken een grotere catalogus en laden alleen relevante definities op aanvraag.

Bronnen

1. LangChain. "State of AI 2024-rapport, aandeel LLM-traces met tool-aanroepen op LangSmith." https://www.langchain.com/blog/langchain-state-of-ai-2024. Geraadpleegd augustus 2026.
2. Berkeley Gorilla-team, UC Berkeley. "Samenstelling en evaluatiecategorieën van de dataset van het Berkeley Function Calling Leaderboard." https://gorilla.cs.berkeley.edu/blogs/8_berkeley_function_calling_leaderboard.html. Geraadpleegd augustus 2026.