WebMCP, MCP of llms.txt: kies op basis van de taak

Door E. Clein · Laatst bijgewerkt 6 september 2026 · 3 min lezen

De namen lijken op elkaar, maar lossen niet hetzelfde probleem op. Begin daarom niet met de vraag welke standaard je moet toevoegen. Vraag eerst of je lezer informatie zoekt, een achtergrondsysteem wil gebruiken of een agent functionaliteit van je webpagina nodig heeft.

Drie ingangen, drie ontwerpvragen

llms.txt is een voorstel voor een tekstbestand dat bruikbare informatie en documentatie aanwijst. MCP beschrijft hoe een AI-applicatie via clients met servers communiceert die onder meer tools, resources en prompts aanbieden. WebMCP richt zich op tools die websites beschikbaar maken in een browsercontext.

De tabel is een keuzehulp, geen exclusieve verdeling. Een MCP-server kan bijvoorbeeld ook browserfuncties aanbieden. Andersom kan een WebMCP-tool via jouw bestaande backend werken. Het verschil zit in de integratie en context, niet in een verbod op bepaalde soorten taken.

Een browsercontext hoeft niet zichtbaar te zijn: de op 4 september 2026 gemergede WebMCP-verduidelijking over headless gebruik neemt ook browsers zonder zichtbaar venster expliciet mee. De pagina blijft dan onderdeel van de uitvoering. ‘Achtergrondtaak’ betekent dus niet automatisch MCP en ‘WebMCP’ betekent niet automatisch dat iemand meekijkt. De API-vergelijking werkt deze keuze uit. Dit is een verduidelijking van het ontwerp, geen bewijs van ondersteuning door iedere browser of agent.

Voorbeeld 1: een documentatiesite

Een ontwikkelaar wil weten hoe hij een webhook valideert. De eerste verbetering is een duidelijke handleiding met een werkend voorbeeld en versie-informatie. Een llms.txt-bestand kan de relevante documentatie als extra ingang aanwijzen.

Daarvoor hoef je geen tool te bouwen die de tekst nog eens teruggeeft. Voeg een handelingsinterface pas toe als de gebruiker iets moet kunnen dóén, zoals een testevent maken in een eigen sandbox. De aanwezigheid van llms.txt garandeert ondertussen niet dat zoekdiensten of assistenten je pagina gebruiken.

Voorbeeld 2: een interne achtergrondtaak

Een medewerker wil vanuit een bestaande AI-app rapportages uit een administratiesysteem ophalen. Een MCP-integratie kan daarbij passen als die app het protocol ondersteunt en de organisatie de benodigde toegang goed kan regelen.

Volgens de MCP-architectuur kunnen servers lokaal via stdio of op afstand via HTTP worden verbonden. MCP betekent dus niet uitsluitend ‘een openbare server met een API-sleutel’. Authenticatie, rechten, beheer en het bereik van beschikbare data blijven concrete ontwerpkeuzes.

Voorbeeld 3: samen een configuratie afronden

Een klant heeft een productconfigurator open en vraagt een agent een passende uitvoering samen te stellen. WebMCP kan de site functies laten aanbieden die aansluiten op die sessie, bijvoorbeeld opties valideren of een concept opslaan.

Dat is een redactioneel, fictief scenario, geen gemeten klantcase. Onderzoek of de betreffende agentclient de gebruikte toolvorm ondersteunt. Houd definitief bestellen apart van het voorbereiden en laat de backend dezelfde prijzen, rechten en validatie afdwingen als voor de gewone interface.

Combineer alleen als er twee echte gebruikersvragen zijn

Een platform kan documentatie, achtergrondintegraties en een interactieve site hebben. Dan zijn meerdere ingangen verdedigbaar. Maar drie logo’s in je architectuur zijn geen doel op zichzelf: iedere extra ingang vraagt onderhoud, tests en duidelijke verantwoordelijkheden.

Schrijf vóór de keuze één acceptatiecriterium op. Bijvoorbeeld: ‘De medewerker kan binnen de AI-app de toegestane rapportage ophalen zonder een websitesessie.’ Of: ‘De klant kan in de geopende configurator een correct concept bewaren.’

Als je niet kunt uitleggen waarom de gekozen interface die taak beter ondersteunt, stel de integratie uit. Een goede gewone API of een heldere webpagina kan al voldoende zijn. Meer protocollen maken een onduidelijk productdoel niet duidelijker.