Function calling is de manier waarop een model vraagt om een tool te gebruiken. MCP (Model Context Protocol) is een standaardmanier om tools bij de app te krijgen waarin het model draait. Het zijn geen concurrenten. In een gewone MCP-opstelling doet het model nog steeds een function call, en de app geeft die aanroep door aan een MCP-server.
De nuttige vraag is dus niet “MCP of function calling?”, maar: moet deze tool buiten mijn app staan?
Wat is function calling?
Function calling is een mogelijkheid in de API van een model (de programmeerinterface waarmee je app met het model praat). OpenAI noemt het ook tool calling, Anthropic noemt het tool use. Je stuurt het model een vraag en een korte lijst tools mee. Elke tool heeft een naam, een beschrijving en een schema: een strikte omschrijving van de invoer die de tool accepteert.
Besluit het model dat het een tool nodig heeft, dan antwoordt het niet in gewone tekst. Het stuurt een gestructureerd verzoek terug, bijvoorbeeld: roep get_order_status aan met order_id: "A-1043".
Het model voert zelf nooit iets uit. In de gids van OpenAI is de derde van vijf stappen dat de applicatie de code uitvoert met de invoer uit de toolaanroep. Anthropic schrijft dat Claude een gestructureerde aanroep teruggeeft die jouw applicatie uitvoert. Jouw code doet het werk en stuurt het resultaat terug, waarna het model het eindantwoord schrijft.
Wat is MCP?
MCP is een open protocol dat Anthropic op 25 november 2024 als open source uitbracht, om AI-apps te koppelen aan tools en data van buiten. Er zijn drie rollen:
- De host is de AI-app die je gebruikt, zoals een chat-app op je computer of een code-editor.
- De server is een apart programma dat tools (handelingen), resources (data om te lezen) en prompts (sjablonen) aanbiedt.
- De client is een kleine connector in de host. De host draait één client per server.
Een client vraagt met het verzoek tools/list wat een server aanbiedt, en voert een tool uit met tools/call. De berichten lopen via stdio, waarbij de server als lokaal programma op dezelfde machine draait, of over HTTP, waarbij de server ergens op een netwerk staat. MCP-betekenis is het volledige woordenboekartikel.
Hoe passen ze in elkaar? Eén aanroep gevolgd
Neem een fictieve fietsenwinkel die wil dat zijn assistent de vraag “waar blijft mijn bestelling?” kan beantwoorden.
Met gewone function calling schrijft de ontwikkelaar een functie get_order_status in de app van de winkel en beschrijft die in het API-verzoek. Het model antwoordt met een toolaanroep. De app voert de functie uit op de bestellingendatabase en stuurt het resultaat terug. Alles zit in één codebase, en één team is eigenaar.
Met MCP verhuist dezelfde functie naar een kleine MCP-server. Bij het opstarten stuurt de client van de assistent tools/list en krijgt de naam, de beschrijving en het invoerschema van de tool terug. De host geeft die lijst aan het model als gewone tooldefinities. Het model antwoordt met dezelfde toolaanroep als eerst. De client maakt daar een tools/call-verzoek van, de server zoekt de bestelling op en het resultaat gaat terug.
Dat is geen vereenvoudiging voor deze pagina. De officiële MCP-handleiding voor het bouwen van een client doet precies dit: ze zet de toollijst van de server om naar het toolformaat van Claude en stuurt elke toolaanroep van het model door naar de server.
| Vraag | Gewone function calling | Met MCP |
|---|---|---|
| Waar staat de code van de tool? | In je eigen app | In een aparte MCP-server |
| Wie schrijft de toolbeschrijving? | Je app | De server |
| Wie kan de tool gebruiken? | Alleen die ene app | Elke app met MCP-ondersteuning die verbinding maakt |
| Wat levert het model op? | Een gestructureerde toolaanroep | Dezelfde gestructureerde toolaanroep |
| Wie voert de tool uit? | Je app | De server, zodra de host de aanroep doorstuurt |
| Hoe reist de aanroep? | Als functieaanroep in je code | Via stdio (lokaal) of HTTP (op afstand) |
| Wie bepaalt wat de tool mag? | Jij | Nog steeds jij |
De zin om te onthouden: function calling is het verzoek van het model; MCP is de aanvoerroute van de tool.
Sommige platforms doen inmiddels een deel van het aansluitwerk voor je. OpenAI rekent toegang tot een MCP-server tot zijn ingebouwde tools, en Anthropic biedt een MCP-connector die vanuit de API servers op afstand bereikt, zonder aparte client. Het model vraagt nog op dezelfde manier om een tool. Het platform doet het werk van de client.
Wanneer is gewone function calling genoeg?
Als één app zijn eigen tools gebruikt. Roept je product drie interne functies aan, geschreven en uitgerold door hetzelfde team, dan kost een aparte server je een extra proces dat moet draaien, een verbinding die je moet beveiligen en een versie die je moet bijhouden. Je krijgt er niets voor terug.
Een snelle toets: zou iemand deze tool ooit in een andere AI-app willen gebruiken? Is het eerlijke antwoord nee, houd het dan bij een functie.
Wanneer verdient MCP zijn plek?
Als dezelfde tool op meer dan één plek moet werken. Stel dat de fietsenwinkel het opzoeken van bestellingen wil gebruiken in de klantchat, in de code-editor van de ontwikkelaars en in de desktopassistent van de supportleider. Eén MCP-server vervangt dan drie losse koppelingen. Volgens de specificatie haalt MCP een deel van zijn inspiratie uit het Language Server Protocol, dat hetzelfde deed voor programmeertalen in code-editors.
MCP verdient ook zijn plek als iemand anders de tool bouwt. Er bestaan kant-en-klare servers voor gangbare systemen (bij de aankondiging in 2024 deelde Anthropic er al voor Google Drive, Slack, GitHub en Postgres), en een host kan er een aansluiten zonder nieuwe code aan jouw kant. Kant-en-klaar is niet hetzelfde als gecontroleerd; daarover gaat het volgende deel.
Het artikel over MCP-koppelingen laat zien hoe dat aansluiten per app werkt.
Wat verandert MCP niet?
Mythe: MCP maakt toolaanroepen veilig. Feit: de specificatie zegt zonder omwegen dat MCP deze beveiligingsprincipes zelf niet op protocolniveau kan afdwingen. Ze eist dat hosts de gebruiker om toestemming vragen voordat ze een tool aanroepen, en verplicht servers om invoer te controleren, toegangscontrole in te bouwen en te begrenzen hoe vaak tools worden aangeroepen. Een tool die je hele klantendatabase kan lezen, kan dat via MCP net zo goed als in de vorm van een functie.
Mythe: MCP vervangt function calling. Feit: in de aanroep die we hierboven volgden, doet het model nog steeds de function call. MCP heeft de tool verplaatst, niet het verzoek.
Mythe: toolbeschrijvingen zijn onschuldige etiketten. Feit: het model leest ze als instructies die het kan opvolgen, en volgens de specificatie gelden beschrijvingen van toolgedrag als onbetrouwbaar, tenzij ze van een vertrouwde server komen. Een server die je niet zelf schreef, legt andermans tekst aan je model voor. MCP uitgelegd voor ondernemers laat zien hoe je zo’n server beoordeelt.
Wat hoe dan ook telt: een contract per tool
Welke route je ook kiest, het risico zit in wat de tool kan, niet in hoe het verzoek reist. De agentische codebase, een van de boeken van Len (nu verkrijgbaar), gaat over het inrichten van coderepository’s waarin mensen en AI-agents samenwerken. Het hoofdstuk over MCP maakt het punt waarop deze pagina rust: een functie vertelt je alleen dat de agent haar kan aanroepen, een contract vertelt je dat dat veilig kan en wat er gebeurt als het misgaat.
Je hebt het boek niet nodig om de checklist te gebruiken. Schrijf per tool op:
- Reikwijdte (scope). Wat de tool mag lezen en wijzigen, en wat hij nooit mag aanraken. Staat een recht op beide lijsten, dan wint de verbodslijst.
- Invoer en uitvoer. Met vaste types en grenzen, zodat “alle transacties” wordt: “de laatste 50, met een manier om meer op te vragen”.
- Authenticatie. Wiens inloggegevens de tool gebruikt. Voor een server op afstand: een token dat alleen voor die server werkt.
- Time-out. Hoe lang je wacht, en wat er gebeurt als de tijd om is.
- Idempotentie, voor alles wat data wijzigt: een unieke sleutel per handeling, zodat een nieuwe poging na een netwerkfout een klant niet twee keer terugbetaalt.
- Benoemde foutsituaties. “Niet gevonden: geef niets terug, verzin nooit een record.” “Te veel verzoeken: wacht en meld het.”
- Eigenaar. Eén persoon, bij naam.
Toegepast op de fietsenwinkel: get_order_status mag één bestelling lezen op basis van het bestelnummer, en verder niets. De tool geeft alleen status en leverdatum terug, geeft het na een paar seconden op en kan niets wegschrijven, dus een idempotentiesleutel is niet nodig. Hij zegt “niet gevonden” in plaats van te gokken, en de ontwikkelaar die hem schreef is de eigenaar.
Dat past in een kort tekstbestand naast de code. Het blijft hetzelfde bestand, of de functie nu in de app blijft of naar een MCP-server verhuist.
Probeer dit vandaag (15 minuten)
Kies één tool die jouw AI-opstelling kan aanroepen.
- Schrijf op waar hij staat: in de code van je app, of in een MCP-server.
- Stel de hergebruikvraag. Heeft een andere AI-app deze tool nodig? Zo niet, en draait hij als MCP-server die je zelf hebt gebouwd, dan onderhoud je misschien een server voor niets. Hebben meerdere apps hem nodig en heb je hem in elke app gekopieerd, dan is dat precies het argument voor MCP.
- Vul de zeven contractregels hierboven in. Elke regel die je niet kunt invullen, los je eerst op, voordat je nog een tool toevoegt, via welk protocol dan ook.
Citeer deze pagina:MCP versus function calling: twee lagen van dezelfde toolaanroep.Len P. van der Hof. https://lenvanderhof.com/nl/blog/mcp-versus-function-calling/ ·