Twaalf apps bruikbaar gemaakt voor agents: zes lessen voor je eigen WebMCP-tools
Het Duitse softwarebedrijf Mindoo maakte twaalf apps bruikbaar voor AI-agents met WebMCP, van takenlijst tot CRM en mail. Hun lessen: bouw tools voor taken, niet voor klikken. Toon niet alle tools tegelijk. Laat de app rekenen. Schrijf beschrijvingen voor agents, niet voor kopers. Test met een model dat je code niet kent. En maak elke stap ongedaan te maken, met alleen de gegevens die de taak nodig heeft.
Een agent die je takenlijst bedient, hoeft niet te weten welk vinkje in welke rij staat. Hij moet weten dat hij een taak kan afronden. Dat klinkt vanzelfsprekend, maar het is een van de zes lessen die Mindoo leerde door twaalf eigen apps aan agents te koppelen. Wij zetten ze op een rij en vertalen ze naar een gewone bedrijfswebsite.
Wat Mindoo heeft gebouwd
Mindoo maakt Haven, een werkruimte waarin kleine apps naast elkaar draaien: van een takenlijst en mindmap tot CRM, mail en websitebeheer. Op 27 oktober 2026 beschreef medeoprichter Karsten Lehmann wat ze leerden toen ze twaalf van die apps bruikbaar maakten voor AI-agents. Elke app meldt zijn tools aan met document.modelContext.registerTool(), de API uit de WebMCP-draft. Een open-source Chrome-extensie geeft die tools door aan agents op de computer van de gebruiker, zoals goose en Claude Code.
Dat is de combinatie uit onze vergelijking van WebMCP en MCP. De tools staan in de pagina en werken met de sessie van de gebruiker; een brug maakt ze bereikbaar voor MCP-clients.
Les 1: bouw tools voor taken, niet voor klikken
Mindoo heeft een tool todo_tasks_complete die een taak afrondt. Er is geen tool die nadoet dat iemand op het vinkje in rij drie klikt. Een tool doet wat een gebruiker in gewone taal zou vragen, en werkt nooit rechtstreeks op de opslag eronder. Ook een algemene tool om een eigen script uit te voeren kregen agents niet. Zo'n script kan gegevens wijzigen buiten de regels van de app om, en de gebruiker ziet daarna niet wat er is gebeurd.
Voor je eigen site: noem een tool naar de taak van je klant, zoals vraag_offerte_aan of verzet_afspraak, en niet naar het formulier of de knop. Welke taken dat zijn, werk je uit met het praktische besliskader.
Les 2: toon niet alle tools tegelijk
Haven begint met een paar algemene tools. Een agent vraagt eerst waar de gebruiker is en welke apps er zijn. Pas als hij een app opent, verschijnen de tools van die app. Grote apps zijn nog verder opgedeeld. In de lesplanner voor docenten verschijnen de tools voor cijfers pas als de agent dat onderdeel opent, en ze verdwijnen na tien minuten zonder gebruik. Uitgebreide uitleg, zoals veldtabellen en voorbeelden, staat in een aparte tool die de agent alleen opvraagt als hij die nodig heeft.
Zo blijft de lijst klein genoeg voor lokale modellen, schrijft Mindoo, en volgt hij wat de gebruiker op het scherm ziet. Op een website werkt het net zo: meld op de productpagina de producttools aan en in de checkout de checkouttools. Een agent moet een lijst die verandert wel opnieuw ophalen. Hoe je dat test, staat in ons testartikel.
Les 3: laat de app rekenen en het model kiezen
‘De app rekent, het model beslist’, vat Lehmann het samen. Wie twintig taken wil aanmaken, doet dat in één aanroep met een lijst. Een tool geeft terug wat er veranderd is, niet alleen ‘ok’. Lange resultaten worden ingekort, en de tool zegt erbij dat ze zijn ingekort. Elke tool die een id nodig heeft, noemt de tool die dat id oplevert, zodat een agent geen id verzint. En personen slaat een app op als vermelding uit het adresboek, zodat ‘wijs het toe aan Anna’ altijd dezelfde Anna is.
Voor je eigen site: laat een tool de prijs inclusief btw, de levertijd of de beschikbaarheid zelf berekenen en teruggeven. Laat de agent dat niet uit losse gegevens afleiden. Meer daarover in beschikbaarheid en foutpaden.
Les 4: schrijf beschrijvingen voor agents, niet voor kopers
Hier ging het bij Mindoo drie keer mis. De eerste lijst met apps gebruikte de tekst uit de appwinkel: zo'n 6 kB verkooptekst per app, zonder één toolnaam. Een korte, neutrale samenvatting werkte beter. Een uitleg noemde tools die de app niet had, wat pas opviel toen een model ze probeerde aan te roepen. En één app werd op twee plekken verschillend beschreven. De oplossing: één bron per app, en een test die faalt als een beschrijving een tool noemt die niet bestaat.
Voor je eigen site: schrijf toolbeschrijvingen niet in de toon van je homepage. Zeg wat de tool doet, wat hij nodig heeft en wat hij teruggeeft.
Les 5: test met een model dat je code niet kent
Mindoo liet per app een Sonnet-model van Anthropic een gewone taak uitvoeren, zoals ‘maak van deze notulen taken met eigenaren’. Het model zag alleen wat een agent ziet: de toollijst, de beschrijvingen en de resultaten. Aarzelde het, gokte het een id of riep het tools in een vreemde volgorde aan, dan pasten ze de tools aan. Daarnaast draait elk voorbeeld uit de uitleg als unit-test mee.
Een technische test bewijst dat een tool het juiste antwoord geeft. Een blinde test laat zien of een agent de tool begrijpt. Chrome noemt dat taakevaluaties. Wij meten het met Agent Tool Evals: dezelfde taken, herhaald met de agents en modellen die je kiest.
Les 6: maak elke stap ongedaan te maken, met alleen de gegevens die nodig zijn
Elke schrijfactie van een agent is in Haven precies één stap die je ongedaan kunt maken, gemarkeerd als gedaan door een agent. Heeft de gebruiker hetzelfde document intussen zelf aangepast, dan weigert het ongedaan maken. Daaronder bewaart de database elke wijziging; niets wordt overschreven. Een fout die je ziet en kunt terugdraaien is vervelend, schrijft Lehmann. Een fout die je niet ziet, is een risico.
Ook bepaalt de gebruiker hoeveel een agent mag zien. In de lesplanner kiest een docent uit drie niveaus: alleen lessen en rooster, ook de namen van leerlingen, of ook cijfers. De app filtert de gegevens voordat een tool iets teruggeeft. Onder het tweede niveau verschijnen leerlingen zonder naam, hoe het model ook vraagt. Zet de docent een les op het grote scherm in de klas, dan valt de app vanzelf terug naar het eerste niveau.
Voor je eigen site: beslis per tool welke gegevens de taak nodig heeft, en laat de rest weg voordat de tool antwoordt, niet erna. Hoe dat bij formuliervelden werkt, lees je in maskeren of uitsluiten.
Waar je op let
Mindoo bouwt zijn eigen apps en bepaalt zelf de hele keten, tot en met de brug naar de agent. Een gewone website heeft te maken met agents die hij niet zelf kiest, en met browsers die WebMCP nog niet allemaal ondersteunen; die stand houden we bij op browsersupport. Lokale modellen verschillen volgens Mindoo nog sterk in hoe goed ze tools aanroepen. In hun tests werkten de grotere varianten van Qwen en gpt-oss het best.
Het zijn de ervaringen van één bedrijf, geen meting die je kunt doortrekken naar elke agent. Ze laten wel zien waar het in de praktijk misgaat: niet bij het aanmelden van tools, maar bij het ontwerp ervan.
Wat je nu doet
Neem de tool die je al hebt, of de eerste die je wilt bouwen, en loop de zes lessen langs.
| Les | Vraag bij je eigen tool |
|---|---|
| Taken, geen klikken | Beschrijft de naam wat de klant wil, of welke knop er wordt ingedrukt? |
| Niet alles tegelijk | Ziet de agent alleen de tools die bij deze pagina of stap horen? |
| De app rekent | Geeft de tool het eindantwoord, zoals een prijs inclusief btw, of moet de agent dat zelf afleiden? |
| Beschrijving voor agents | Is de tekst neutraal, en bestaan alle toolnamen die erin staan? |
| Blind testen | Heeft een model zonder kennis van je code een echte taak met de tool uitgevoerd? |
| Terugdraaien en weglaten | Kan de klant de stap ongedaan maken, en krijgt de agent alleen de gegevens die nodig zijn? |
Bronnen
Lees ook
Meer context bij dit onderwerp: Wat is WebMCP? De complete uitleg. Benieuwd hoe jouw site ervoor staat? Doe de gratis AI-Ready Websitescan.