API’s voor AI Agents: van MCP tot eigen endpoints

Toen LLM’s functies leerden aanroepen

In het GPT-3-tijdperk betekende interactie met een LLM dat je een prompt invoerde en tekst terugkreeg. De kennis van het model was groot, maar statisch, bevroren op basis van wat de trainingsdata bevatte. Je kon het vragen om quantumcomputing uit te leggen of een e-mail op te stellen, en het produceerde aannemelijke tekst. Maar het kon het weer van vandaag niet controleren, geen database bevragen en geen actie in de echte wereld uitvoeren.

De functie die dit veranderde, krijgt opvallend weinig erkenning. Deze gaf het model een keuze tussen tekst genereren en een functie aanroepen. In plaats van altijd het volgende token te produceren, kon het model nu een gestructureerd JSON-object uitvoeren met een functienaam en bijbehorende argumenten. De runtime zou die functie uitvoeren, het resultaat teruggeven aan het model, waarna het model vanaf daar verderging. De ReAct-paper (Yao et al., 2022) formaliseerde dit als de Thought-Action-Observation-loop. Het model redeneert over wat het moet doen, voert een actie uit (roept een tool aan), observeert het resultaat en herhaalt dit. Elke serieuze AI Agent in 2026 draait op een variant van dit patroon.

De loop

Claude Code, OpenClaw, Codex, Devin en tientallen andere agentische systemen werken allemaal op dezelfde manier. Roep een tool aan, observeer het resultaat, bepaal wat de volgende stap is, herhaal. Simon Willison verwoordde het goed: “An LLM agent runs tools in a loop to achieve a goal.”

Claude Code gebruikt bijvoorbeeld een single-threaded master loop zonder multi-agentzwerm of complexe orkestratiegrafiek: while(tool_call) -> execute -> feed results -> repeat.

Anthropic’s onderzoek naar agentautonomie laat zien dat turn durations in Claude Code in drie maanden bijna zijn verdubbeld, van 25 naar meer dan 45 minuten. Gebruikers vertrouwen er steeds vaker op dat de loop zelfstandig draait. De data laat zien dat ervaren gebruikers vaker onderbreken (een verschuiving van goedkeuring per actie naar strategische monitoring), terwijl de agent zelf meer dan twee keer zo vaak om verduidelijking vraagt als gebruikers hem onderbreken.

Dit looppatroon zie je overal terug, in coding agents, klantenservicebots en roboticacontrollers.

Wat telt als een tool?

LLM’s geven ons veel vrijheid bij het bepalen op welk abstractieniveau een tool moet werken. Aan het ene uiteinde heb je zeer specifieke API-endpoints: “maak een HubSpot-contact aan met deze 12 velden.” Aan het andere uiteinde heb je tools zoals “voer dit bash-commando uit” of “voer deze Python-code uit,” wat in feite neerkomt op “doe wat je wilt.”

Devin werkt met drie tools: shell, code editor, browser. De primaire tool van Claude Code is ook een shell. OpenClaw gebruikt een dynamisch skills-plugin-systeem. De trend in agentische coding tools gaat richting minder, algemenere tools in plaats van veel specifieke tools.

Simon Willison merkte op dat MCP voor coding agents “aanvankelijk explodeerde, maar daarna minder centraal voelde”, omdat bash de universele tool is. Bestanden en scripts zijn een primitive met minder overhead dan volledige MCP-serverimplementaties. Als de agent code kan schrijven en uitvoeren, kan hij bijna alles doen zonder een specifieke tooldefinitie nodig te hebben.

Maar general-purpose tools werken voor general-purpose agents. Voor domeinspecifieke AI Agents (klantenservice, sales, interne operaties) heb je domeinspecifieke tools nodig. Je supportagent zou geen Python moeten schrijven om een orderstatus te controleren. Hij moet een goed gedefinieerd API-endpoint aanroepen met duidelijke parameters en voorspelbare antwoorden. Het ontwerp van je toolset wordt een productbeslissing.

Wat een API-endpoint nu betekent

Voor AI Agents functioneert een API-endpoint als een capaciteitsverklaring. Door er een te publiceren, geef je aan dat jij (of je AI Agent) nu iets kunt doen wat eerder niet mogelijk was.

Dit werkt in beide richtingen. Een softwareleverancier publiceert een API zodat anderen met het product kunnen integreren. Maar een AI Agent kan ook zelf endpoints ontdekken door documentatie te doorzoeken, OpenAPI-specificaties te lezen of letterlijk te googelen hoe een taak moet worden uitgevoerd.

Een MCP-server is een samengestelde bundel API-endpoints met een vooraf gevormd idee over hoe ze gebruikt moeten worden. De maker van de MCP heeft al beslissingen genomen over welke endpoints worden blootgesteld, hoe ze heten, welke parameters zichtbaar zijn en impliciet welke workflows worden ondersteund. Die curatie is zowel de kracht (gemak, standaardisatie) als de zwakte (starheid, sturende scope). De server van Notion is een concreet voorbeeld: deze publiceert 28 tools, en een helpcenteragent heeft er vier nodig, verdeeld over twee verbindingen.

MCP’s ruilen controle in voor gebruiksgemak. In 2026 schrijft AI het grootste deel van de integratiecode. Als een agent API-documentatie kan lezen en zelf de integratie kan schrijven, wordt het argument voor MCP op basis van “gebruiksgemak” zwakker. De MCP-laag is mogelijk het belangrijkst tijdens de overgangsperiode, zolang tooling nog niet is bijgewerkt naar de capaciteit van het model. Anthropic’s gids over ontwerppatronen voor toolgebruik is een praktische referentie voor het structureren van toolschema’s, ongeacht of je MCP of afzonderlijke endpoints gebruikt.

Een verwante ontwikkeling: llms.txt is een voorgestelde standaard waarbij websites een /llms.txt-bestand publiceren om AI-modellen naar waardevolle resources te sturen. Anthropic, Cloudflare, Docker en Stripe hebben het overgenomen. MCP standaardiseert toolaanroepen, llms.txt standaardiseert documentatieontdekking. Beide proberen het web beter leesbaar te maken voor machines, vanuit verschillende hoeken.

Wat is een API-endpoint in de context van AI Agents?

Een API-endpoint is een specifieke URL die gestructureerde input accepteert en gestructureerde output retourneert. Voor AI Agents vertegenwoordigt elk endpoint een afzonderlijke capaciteit, iets wat de agent in de echte wereld kan doen. De beschrijving van het endpoint, parameterdefinities en foutresponses dienen als de handleiding van de agent. Hoe beter het endpoint is gedocumenteerd, hoe betrouwbaarder een agent het kan gebruiken.

Anders dan menselijke ontwikkelaars, die tutorials kunnen lezen en iteratief kunnen debuggen, vertrouwt een agent op het schema en de beschrijving van het endpoint om één correcte call te maken. Daarom is API-documentatie die is ontworpen voor AI-consumptie belangrijker dan ooit. Slechts 24% van de ontwikkelaars ontwerpt momenteel API’s met AI Agents in gedachten, ondanks dat 89% AI in hun workflow gebruikt.

Wat is MCP (Model Context Protocol)?

MCP is een open protocol geïntroduceerd door Anthropic dat standaardiseert hoe AI Agents verbinding maken met externe tools en databronnen. Zie het als USB-C voor AI. Eén connector die elke toolprovider kan implementeren en elke AI Agent kan gebruiken. Een MCP-server stelt een set tools beschikbaar (in essentie API-endpoints) met gestandaardiseerde schema’s, en een MCP-client (de agent) kan deze ontdekken en aanroepen zonder aangepaste integratiecode. Zie voor een diepere technische uitleg onze post MCP Explained. Zie voor een praktisch verslag van MCP in productie onze analyse van praktische uitdagingen bij bouwen op Shopify’s MCP.

Het controlespectrum in Quickchat AI

Quickchat AI geeft je drie manieren om een AI Agent uit te rusten met externe tools. Ze liggen op een spectrum van meest geautomatiseerd tot meest gecontroleerd. Elke aanpak maakt een andere afweging tussen snelheid van configuratie en nauwkeurigheid van gedrag.

Remote MCP: aansluiten en starten

Remote MCP is de snelste manier om een AI Agent te verbinden met externe functionaliteit. Je geeft een MCP-server-URL op, Quickchat AI maakt verbinding, ontdekt alle beschikbare tools en laat je selecteren welke je agent moet gebruiken.

Zo stel je het in:

1. Ga naar AI Actions in het Quickchat AI-dashboard
2. Klik op “Add Remote MCP”
3. Plak je MCP-server-URL (bijvoorbeeld https://mcp.example.com/sse)
4. Voeg eventueel een authenticatietoken of custom headers toe (de twee sluiten elkaar uit)
5. Klik op “Connect.” Quickchat AI ontdekt alle beschikbare tools en toont hun namen
6. Schakel afzonderlijke tools in of uit om te bepalen welke je agent kan gebruiken
7. Stel de vlag “default tool is active” in om te bepalen of nieuw ontdekte tools automatisch worden ingeschakeld of uitgeschakeld

Wat er onder de motorkap gebeurt:

Wanneer je op Connect klikt, detecteert Quickchat AI automatisch het transportprotocol uit de URL. Als de URL sse bevat, wordt SSE-transport gebruikt, anders is streamable_http de standaard. Wanneer je een auth token opgeeft, wordt dit als Bearer-token verzonden in de Authorization-header.

Toolfiltering werkt via een systeem met drie lagen. Elke tool van de MCP-server wordt gecontroleerd aan de hand van twee sets: expliciet ingeschakelde tools worden altijd opgenomen, expliciet uitgeschakelde tools worden altijd uitgesloten, en elke tool die in geen van beide sets staat, valt terug op de door jou gekozen instelling “default tool is active”. Dit betekent dat wanneer een MCP-server nieuwe tools toevoegt, jij bepaalt of ze automatisch beschikbaar zijn voor je agent of expliciete activering vereisen.

Tijdens runtime worden alle actieve Remote MCP-verbindingen voor de agent geladen wanneer een gesprek start. Tools worden opgehaald en gefilterd volgens de configuratie van elke verbinding, en de uniciteit van toolnamen wordt gecontroleerd over alle bronnen heen (met een waarschuwing als duplicaten worden gevonden).

De afweging: je krijgt onmiddellijk toegang tot alles wat de MCP beschikbaar stelt, maar je hebt beperkte controle over toolbeschrijvingen, parameterdefinities of hoe de agent besluit ze te gebruiken. Zoals we ontdekten bij het bouwen van een AI Agent op Shopify’s MCP, vereist de stap van demo naar productie zorgvuldige afstemming die door de gebundelde aanpak van MCP lastig kan worden.

Zie ook: verbind je agent met een remote MCP-server, How to Launch Your Quickchat AI MCP, beveiligingsoverwegingen voor MCP, Quickchat AI docs: MCP channel.

AI Actions (HTTP Request): één endpoint, volledige controle

Een AI Action in Quickchat AI is één HTTP API-endpoint dat je afzonderlijk configureert voor je AI Agent. Waar MCP in één keer een bundel tools importeert, geeft elke AI Action je volledige controle over één specifieke capaciteit. Voor een volledig uitgewerkt voorbeeld, vier actions die contacten aanmaken en verrijken, deals loggen en tickets openen in een CRM, zie de HubSpot AI Actions-tutorial.

Een AI Action configureren:

1. Name (maximaal 64 tekens): dit wordt de toolnaam die de LLM ziet. Deze wordt genormaliseerd naar een geldige identifier (bijvoorbeeld “Check Order Status” wordt Check_Order_Status)
2. Description (maximaal 1.000 tekens): dit is het belangrijkste veld. De beschrijving vertelt de LLM wanneer deze tool moet worden gebruikt. Goede beschrijvingen specificeren onder welke gespreksomstandigheden de tool moet worden aangeroepen, welke informatie eerst bij de gebruiker moet worden verzameld en hoe resultaten moeten worden teruggekoppeld
3. HTTP method: GET, POST, PATCH, DELETE of PUT
4. URL (maximaal 10.000 tekens): kan {{parameter_name}}-placeholders bevatten voor dynamische waarden
5. Headers: key-value-paren voor authenticatie en contenttype
6. Body items / Body JSON: request body met parameterinjectie
7. Query parameters: waarden voor de querystring van de URL
8. Parameters (maximaal 10): elk met een naam, beschrijving (maximaal 500 tekens), type (str, int, float, bool of custom), een verplichte-vlag en een optionele standaardwaarde

De {{parameter_name}}-placeholders zijn het kernmechanisme. Wanneer de LLM de tool aanroept, levert hij waarden voor elke parameter op basis van de gesprekscontext. Quickchat AI injecteert die waarden vervolgens in de URL-, header-, body- en querystringtemplates voordat de HTTP-request wordt uitgevoerd. Er zijn ook vier ingebouwde variabelen die op deze manier kunnen worden geïnjecteerd: scenario_id, conversation_id, conversation_channel en conversation_url.

Een AI Action die is geconfigureerd om de orderstatus te controleren, met een URL-template met parameterplaceholder, headers en parameterdefinities.

Onder de motorkap: Quickchat AI bouwt dynamisch een typed schema op basis van je parameterdefinities voor elke AI Action. De vijf ondersteunde types (str, int, float, bool, custom) worden gemapt naar hun native equivalenten, en dit schema wordt gebruikt om de input van de LLM te valideren voordat de HTTP-request wordt uitgevoerd.

Een voorbeeld van een AI Action om de orderstatus te controleren:

{
  "name": "check_order_status",
  "description": "Wanneer de gebruiker vraagt naar de status van zijn of haar bestelling en een ordernummer heeft opgegeven, roep je dit endpoint aan om de huidige status op te halen. Geef de status, geschatte bezorgdatum en trackingnummer (indien beschikbaar) terug aan de gebruiker.",
  "method": "GET",
  "url": "https://api.example.com/orders/{{order_id}}",
  "headers": [
    { "name": "Authorization", "value": "Bearer YOUR_API_KEY" },
    { "name": "Content-Type", "value": "application/json" }
  ],
  "parameters": [
    {
      "name": "order_id",
      "description": "De order-ID die door de gebruiker is opgegeven (bijvoorbeeld ORD-12345)",
      "type": "str",
      "is_required": true
    }
  ]
}

Testen: Het dashboard heeft een “Test”-knop waarmee je voorbeeldparameterwaarden kunt opgeven en de daadwerkelijke HTTP-request (inclusief een gegenereerd curl-commando) en response kunt bekijken voordat je live gaat.

Tips voor het schrijven van effectieve AI Action-beschrijvingen:

• Wees specifiek over wanneer de agent de tool moet aanroepen: “Wanneer de gebruiker vraagt naar de status van zijn of haar bestelling en een ordernummer opgeeft, roep je dit endpoint aan”
• Noem welke informatie eerst moet worden verzameld: “Controleer voordat je de tool aanroept of je het e-mailadres en de order-ID van de gebruiker hebt”
• Beschrijf hoe de response moet worden afgehandeld: “Als de status ‘shipped’ is, geef je de gebruiker het trackingnummer uit de response”
• Beschrijf voor workflows met meerdere stappen de volgorde in de hoofd-systeemprompt van de agent in plaats van in afzonderlijke action-beschrijvingen, en gebruik Save to memory plus een run-condition om een waarde tussen actions mee te nemen en de write erop te blokkeren

Een uitgewerkt voorbeeld: voor een stapsgewijze AI Action die leads, onbeantwoorde vragen en demo-aanvragen rechtstreeks in een spreadsheet logt, zie hoe je een AI Agent met Google Sheets verbindt.

Generate from Text: laat AI het uitzoeken

De derde optie is voor gebruikers die weten wat ze hun agent willen laten doen, maar niet weten welk API-endpoint (of zelfs welke service) ze moeten gebruiken.

Zo werkt het:

1. Je typt een beschrijving in natuurlijke taal van wat je wilt, bijvoorbeeld: “Ik wil dat mijn AI Agent de Tesla van een gebruiker kan starten wanneer die daarom vraagt”
2. Quickchat AI stuurt dit naar een LLM met de web_search-tool ingeschakeld
3. Het model onderzoekt het web om de juiste API te vinden, leest officiële documentatie en genereert een volledige AI Action-specificatie met URL, methode, headers, parameters en authenticatievereisten
4. Het resultaat komt terug met de volledige action-configuratie, citaties naar de gebruikte documentatie en een toelichtend bericht met aannames en hiaten
5. Je controleert het resultaat, vult je credentials in en activeert

Een beschrijving in natuurlijke taal invoeren van de gewenste capaciteit.

De gegenereerde AI Action-configuratie met citaties naar de gebruikte API-documentatie.

Geautomatiseerde AI Action-generatie is opgebouwd rond drie prioriteiten:

• Prioriteit 1: Begrijp de intentie. Identificeer de exacte capaciteit die de ontwikkelaar wil en het specifieke API-endpoint dat deze levert
• Prioriteit 2: Baseer je op documentatie. Gebruik web search om officiële documentatie van de leverancier te vinden, geen aannames
• Prioriteit 3: Ontwerp semantics vanuit het gesprek. De gegenereerde naam en beschrijving moeten gaan over wanneer in een gesprek deze tool wordt gebruikt, niet alleen over wat de API technisch doet

De prompt gebruikt twee placeholderconventies. {{param}} markeert runtimeparameters die de LLM invult op basis van de gesprekscontext. [[secret_name]] (dubbele vierkante haken) markeert ontwikkelaarsconstanten zoals API-sleutels en account-ID’s die vóór activering handmatig moeten worden geconfigureerd. Elke parameternaam moet ergens in de requestdefinitie voorkomen als een {{that_exact_name}}-placeholder, en losse placeholders zijn niet toegestaan.

Het systeem gebruikt een fail-closed-beleid. Als het model een kritisch stuk informatie niet kan bevestigen vanuit de documentatie (de HTTP-methode, URL, het authenticatieschema of de vereiste payloadstructuur), wordt er geen action aangemaakt. In plaats daarvan retourneert het systeem een beknopte uitleg van wat ontbreekt, in plaats van te gokken.

Hier komt het filosofische punt over AI Agents die API’s ontdekken samen met een concrete productfunctie. De Generate from Text-functie is letterlijk een AI Agent (een LLM met web search) die een tooldefinitie bouwt voor een andere AI Agent (de Quickchat AI-agent die deze in gesprekken zal gebruiken).

Een uitgewerkt voorbeeld: voor de volledige tutorial die twee getypte zinnen omzet in twee live, geteste actions (een weeropvraag zonder sleutel en een NASA-action met sleutel, inclusief de fail-closed-weigering), zie hoe je je AI Agent met elke API verbindt in gewoon Engels.

Tijdens runtime worden al deze tooltypen samengevoegd. Quickchat AI verzamelt HTTP request AI Action-tools, Shopify MCP-tools, knowledge base-tools, remote MCP-tools, Discord-tools en andere custom tools in een collectie die aan de LLM wordt gepresenteerd. Het model ziet geen onderscheid tussen deze tools. Een Remote MCP-tool en een handmatig geconfigureerde AI Action zien er identiek uit zodra ze in de toollijst staan.

Open API’s als de nieuwe SEO

Als AI Agents API’s autonoom gaan ontdekken en gebruiken, wordt een goed gedocumenteerde, eenvoudig te gebruiken API een distributieasset. Gartner voorspelt dat meer dan 30% van de groei in API-vraag tegen 2026 afkomstig zal zijn van AI Agents.

Bedrijven met open API’s en minimale credentialbarrières kunnen merken dat hun API’s hun beste acquisitiekanaal worden. In plaats van Google-zoekimpressies zijn de “impressies” AI Agents die ervoor kiezen jouw service te gebruiken in plaats van die van een concurrent.

Dezelfde logica geldt één niveau hoger. Een AI Agent die antwoordt op basis van je documentatie kan zelf worden blootgesteld als een MCP-server die ChatGPT, Claude en Cursor als tool aanroepen, waardoor je kennis, niet alleen je API, vindbaar wordt voor het agentische web.

De kwaliteit van je API-documentatie bepaalt of een AI Agent in één poging succesvol met je kan integreren. Parameterbeschrijvingen, foutmeldingen en voorbeeldresponses vervullen dezelfde functie als metadescriptions en structured data in traditionele SEO. Een verwarrende foutresponse of een ongedocumenteerd verplicht veld betekent dat een agent faalt, en er is geen mens aan de andere kant om het te debuggen.

Bedrijven waarvan de API’s ongedocumenteerd zijn of achter zware credentialvereisten zitten, kunnen onzichtbaar worden voor het agentische web, op dezelfde manier als bedrijven zonder websites in de jaren 2000 onzichtbaar werden voor Google.

Computergebruik versus API’s

Er wordt aanzienlijk geïnvesteerd in het leren van “computer use” aan AI-modellen (op knoppen klikken, formulieren invullen, UI’s navigeren). Anthropic, OpenAI (Operator) en opensourceprojecten zoals Browser Use bieden hier allemaal versies van.

Maar browsergebruik is een workaround voor een ontbrekende API. Een POST /orders-call duurt milliseconden en retourneert gestructureerde data. Een browseragent die door een checkoutflow navigeert, duurt minuten en kan breken wanneer een knop drie pixels naar links verschuift. API’s zijn sneller, deterministischer en goedkoper om uit te voeren.

Het tegenargument is reëel: API’s bestaan niet voor alles. Legacysystemen, enterprise software zonder API-oppervlak, fysieke apparaten die via GUI’s worden bestuurd. Computergebruik vult in zulke gevallen een echte leemte.

De betere langetermijnreactie op “we hebben hiervoor geen API” is waarschijnlijk het bouwen van de API, in plaats van AI te leren de GUI te gebruiken. Naarmate meer software door AI Agents voor AI Agents wordt geschreven, dalen de kosten voor het bouwen en onderhouden van API’s. De economische afweging die het goedkoper maakte om een UI te scrapen dan een API te bouwen, verschuift.

Er is ook een beveiligingsaspect. Simon Willisons “lethal trifecta” beschrijft de gevaarlijke combinatie van toegang tot privédata + blootstelling aan niet-vertrouwde content + externe communicatie. Dit geldt voor beide benaderingen, maar API-gebaseerde tools zijn eenvoudiger te auditen en te beperken. Je kunt elke API-call loggen, elke parameter valideren en elk endpoint rate-limiten. Het equivalent doen voor een browseragent die overal op kan klikken, is veel moeilijker.

Tools voor de fysieke wereld

Alles wat tot nu toe is besproken, gaat over software. Hetzelfde patroon verschijnt in de fysieke wereld.

Google DeepMind’s RT-2 en Gemini Robotics gebruiken dezelfde architectuur, behalve dat de tools dispatchen naar actuatoren in plaats van API’s. Het SPCA-framework (Sense-Plan-Code-Act) formaliseert dit voor robotica: scan de omgeving, plan de aanpak, genereer uitvoerbare code, voer deze uit, observeer de resultaten.

Er is geen API voor “verplaats de plant op mijn bureau naar rechts.” Maar een robot met een camera zou move_object(object_id="plant_01", direction="right", distance_cm=15) on the fly als tool kunnen definiëren en vervolgens aanroepen. De tooldefinitie dient als interface tussen de redeneerlaag en de fysieke uitvoeringslaag, dezelfde rol die API-endpoints in software spelen.

De LLM + tools + loop-architectuur is general-purpose. Vandaag is deze toevallig het gemakkelijkst te implementeren in software, maar robotica haalt de achterstand in.

API’s geschreven door AI, voor AI

In ongeveer twee jaar (2024 tot 2026) zijn we gegaan van code die grotendeels door mensen werd geschreven naar code die grotendeels door AI wordt geschreven. Dit is een goed moment om opnieuw te bekijken wat een API-endpoint is. Steeds vaker is een endpoint een capaciteitsverklaring die is ontworpen om door machines te worden ontdekt en uitgevoerd, niet een technische interface waar menselijke ontwikkelaars documentatie over lezen en vervolgens handmatig mee integreren.

MCP’s zijn een nuttige standaardisatielaag, maar ze zijn ook een curatielaag die bias introduceert. De maker van de MCP bepaalt welke tools worden blootgesteld en hoe ze worden geframed. Voor AI Agents in productie komt dat frame mogelijk niet overeen met wat je daadwerkelijk nodig hebt. (We schreven hierover uitgebreid in onze analyse van de uitdagingen met Shopify’s MCP.)

Het spectrum dat we hebben doorlopen in Quickchat AI Agents weerspiegelt een breder punt. Het juiste controleniveau hangt af van je use case. Remote MCP werkt goed voor snelle prototyping. Afzonderlijke AI Actions geven je fijnmazige controle voor klantgerichte agents in productie. Generate from Text laat AI de API onderzoeken en de tooldefinitie voor je bouwen wanneer je nog aan het verkennen bent.

En op elk niveau is het onderliggende patroon hetzelfde. Een LLM, een set tools, een loop. Of de tools nu bash-commando’s, API-endpoints, MCP-servers of robotactuatoren zijn, onder elke laag zitten weer tools.