Op Google I/O dit jaar schreef iedereen over Gemini Spark, de cloudgebaseerde agent die op de achtergrond blijft doorwerken terwijl je laptop dicht is. Spark is interessant, maar het echt grote verhaal ging schuil in een slide die de meeste blogs over het hoofd zagen. MCP Apps komen naar Gemini. Daarmee voegt Google zich bij de partijen die op dezelfde standaard uitkomen, naast de ChatGPT-connectors van OpenAI en de native MCP-integratie in Claude van Anthropic. De drie grootste agent-leveranciers bewegen daarmee duidelijk richting dezelfde open standaard voor de koppeling met externe tools.
Als je een product aanbiedt, verandert die convergentie de discovery-vraag. Twintig jaar lang bepaalden zoekmachines, SEO, paid ads, app stores, marketplaces en social feeds welke producten gebruikt werden. Elke laag is een manier waarop een mens jouw product kan vinden voordat hij besluit het te gebruiken. Dat blijft allemaal bestaan. Er komt alleen een extra laag bij, en die wordt de komende jaren steeds belangrijker. De gebruiker kiest niet altijd meer zelf de tool. Steeds vaker kiest een agent de tool namens de gebruiker, en die agent kiest uit een register van diensten die MCP spreken. De vindbaarheid van jouw product binnen dat register wordt een steeds groter deel van de discovery-vraag.
Eerst even nuchter: waar staat Nederland?
Voordat je dit leest als "SEO is voorbij": dat is het niet, en in Nederland al helemaal niet. De adoptie van ChatGPT, Claude en Gemini ligt in Silicon Valley een stuk hoger dan hier. Nederlandse consumenten zoeken nog steeds massaal via Google naar webshops, lokale bedrijven, zorg, verzekeringen, overheidszaken en B2B-leveranciers. Voor de komende drie tot vijf jaar is het realistische beeld dat Google Search, AI Overviews, ChatGPT, Gemini en Claude naast elkaar bestaan, met Google Search voorlopig als grootste kanaal. SEO blijft dus je belangrijkste discovery-investering. Dit artikel gaat over de laag die daar bijkomt, niet over de laag die het vervangt.
De eerste impact van AI op je vindbaarheid merk je bovendien niet via MCP. Die merk je doordat AI Overviews, ChatGPT Search en Perplexity je website steeds vaker samenvatten zonder dat de gebruiker doorklikt. Antwoorden zonder kliks, dat is de fase waar Nederlandse bedrijven nu middenin zitten. MCP is de stap daarna: de agent geeft niet alleen antwoord over jouw product, maar voert er acties in uit. Voor marketeers wordt de verschuiving daarmee heel concreet: minder klikken, meer AI-antwoorden, meer API-calls, meer agent-acties, en minder traditionele sessies in GA4. Wie alleen op sessies en CTR stuurt, ziet deze verschuiving pas als het te laat is om er rustig op te reageren.
Waarom dit een standaardenverhaal is, geen leveranciersverhaal
Ik heb heel wat AI-aankondigingen zien voorbijkomen die uiteindelijk leveranciersspecifieke moats bleken te zijn. Dit is er geen van. Anthropic publiceerde MCP eind 2024, OpenAI voegde ChatGPT-ondersteuning toe in maart 2025, en nu sluit Google zich als derde grote lab aan bij het protocol. Het protocol zelf is niet glamoureus: in essentie is het JSON-RPC over stdio of HTTP, met een tool manifest, getypeerde schemas, beschrijvingen geschreven zodat een LLM ze kan lezen, en een standaard authenticatievorm. Maar precies dat gebrek aan glamour is waar het om draait. Standaarden winnen wanneer niemand een sterke reden heeft om af te wijken, en op dit moment heeft niemand die reden.
In de praktijk betekent dit dat één MCP-server die je vandaag bouwt, Claude, ChatGPT en Gemini tegelijk kan bereiken. De integratiekosten verschuiven van N-maal-M (elk product naar elke agent) naar N-plus-M (elk product spreekt MCP, elke agent spreekt MCP). Als je team ooit de pijn heeft gevoeld van op maat gemaakte Zapier-, Make- en HubSpot-connectors voor hetzelfde product, weet je precies hoe bevrijdend dit is. Eén kanttekening hoort erbij: de drie platformen zitten nog niet op exact dezelfde featureset en het ecosysteem ontwikkelt zich snel. De richting is alleen onmiskenbaar, en dat is voor een standaard het enige wat telt.
Gemini Spark verhoogt de druk
De aankondiging van Spark is belangrijk omdat het background agents normaliseert. De agents waarmee ik de afgelopen 18 maanden heb geïntegreerd, waren bijna allemaal foreground: een gebruiker geeft een prompt aan Claude of ChatGPT, de agent roept een tool aan en de gebruiker ziet het antwoord. Spark, ChatGPT Tasks en de scheduled actions van Claude verplaatsen allemaal het zwaartepunt naar agents die blijven doorwerken terwijl niemand kijkt. Ze verwerken 's nachts de inbox, stellen een ochtendbrief samen, voeren om 09:00 een terugkerende deal-check uit in het CRM en vragen alleen om goedkeuring bij acties boven een risicodrempel.
Voor producten verandert dit wat discovery daadwerkelijk betekent. Een foreground agent stelt zich, in het bijzijn van een gebruiker, één keer de vraag "welke tool moet ik nu gebruiken". Een background agent maakt diezelfde keuze stilzwijgend, tientallen keren per dag, bij honderden gebruikers, en de gebruiker ziet de alternatieven nooit. Als jouw product niet in het register staat dat de background agent raadpleegt, zit het niet in de keuzeset. Dan kun je niet concurreren op UX of prijs, want niemand opent nog een vergelijkingspagina.
Wat "agent-discoverable" daadwerkelijk vereist
Ik heb dit jaar zelf twee MCP-servers in productie gebouwd (één voor een intern CRM en één voor een marketingplatform) en in klantwerk nog een tiental meer gebruikt. Het patroon dat bepaalt of een agent naar een product grijpt of het nooit kiest, komt neer op vier eigenschappen.
Vindbaar. De agent moet weten dat jouw product bestaat. Dat betekent dat de MCP-server vermeld moet staan in een register dat de agent raadpleegt. Vandaag zijn dat het register van Anthropic, Smithery en Glama, en steeds vaker ook de Gemini MCP Apps directory zodra die uitkomt. Vindbaar is voor agents wat indexeerbaar is voor zoekmachines, en dezelfde discipline geldt hier. Een duidelijke naam. Een duidelijke categorie. Een one-liner beschrijving die een LLM kan gebruiken om te beslissen of het jou moet aanroepen voor een bepaalde taak. Een publiek installatiepad dat geen salesgesprek vereist.
Aanroepbaar. Zodra de agent besluit je te proberen, moet hij je ook daadwerkelijk kunnen aanroepen. Dit gaat vaker mis dan zou moeten. Tool schemas moeten getypeerd zijn (zowel input als output JSON Schema), beschrijvingen moeten voor een LLM geschreven zijn in plaats van voor een mens, want de LLM is degene die de runtime leest, en jouw authenticatie moet headless werken. Een OAuth-flow waarbij je een browsertab moet openen en door drie toestemmingsschermen moet klikken, is prima voor een foreground agent die de gebruiker in de gaten houdt. Maar die faalt stilzwijgend zodra een background agent je probeert te gebruiken. Scoped API keys, machine-to-machine OAuth of vooraf geautoriseerde sessies zijn de patronen die het wél redden.
Bruikbaar in workflows. De agent moet je willen aanroepen, wat betekent dat jouw product moet passen in een workflow die een agent al uitvoert. De valkuil die ik het vaakst zie: producten die één god-method leveren die vijf dingen tegelijk doet, omdat dat makkelijker te bouwen was. Een agent wil geen god-method. Hij wil composeerbare tools, één taak per tool, snel, met gestructureerde data als resultaat die de volgende tool kan verwerken. De marketing-analytics MCP die één groot PDF-rapport teruggeeft, is bij voorbaat kansloos. De MCP die "get_campaign_performance", "get_keyword_quality_scores" en "suggest_bid_adjustments" als drie kleine tools aanbiedt, wordt gebruikt in tientallen workflows waar je niet eens voor ontworpen hebt.
Gestandaardiseerd. Spreek MCP, niet een op maat gemaakte integratie per leverancier. Dit is de eigenschap die zich opstapelt. Een team dat een MCP-server uitlevert, bereikt drie runtimes voor de prijs van één. Een team dat drie leveranciersspecifieke SDK's uitlevert, moet drie licht verschillende API's voor altijd onderhouden. De situatie waarin ik deze afweging zelf het duidelijkst heb gevoeld, was bij een CRM-project waar dezelfde set mogelijkheden beschikbaar moest zijn voor interne gebruikers in drie verschillende LLM-omgevingen. De MCP-server kostte twee dagen. De eerste leveranciersspecifieke integratie had er drie gekost.
De parallel met de beginjaren van SEO maakt dit tastbaar. Het register is de nieuwe sitemap, en die vergelijking loopt verder door dan je zou denken:
| 2010 | 2026 |
|---|---|
| robots.txt | MCP-manifest |
| sitemap.xml | registry-vermelding |
| structured data | JSON Schema |
| backlinks | agent trust |
| CTR | tool selection rate |
Wie in 2010 begreep dat je voor crawlers moest bouwen in plaats van alleen voor bezoekers, won het volgende decennium. Dezelfde beweging herhaalt zich nu, alleen leest de crawler dit keer je tool-beschrijvingen in plaats van je title tags.
Wanneer is MCP interessant, en wanneer nog niet?
Een mkb-directeur denkt niet "moeten we een MCP-server bouwen". Die denkt "wat levert dit op". Terecht, dus laten we het daar even scherp over hebben. MCP is nu al interessant als je software levert waar andere systemen of agents iets in moeten doen: SaaS-platformen, CRM- en marketingsoftware, ERP en boekhouding, productinformatie, analytics en planningstools. Voorlopig niet interessant is het voor de lokale bakker, de fysiotherapeut, de loodgieter, de kleine webshop en de horeca. Die bedrijven hebben veel meer aan goede vindbaarheid in Google en in AI-antwoorden dan aan een eigen MCP-server.
En er is een eerlijke tussenstap die vaak wordt overgeslagen. Veel Nederlandse softwarebedrijven hebben nog geen goede publieke API, geen webhooks, geen server-side tracking en geen documentatie waar een buitenstaander mee uit de voeten kan. Voor die bedrijven is MCP niet de eerste stap. Een degelijke API, een werkende OAuth-flow en duidelijke documentatie zijn belangrijkere voorwaarden, en tegelijk is dat precies het voorbereidende werk waar een MCP-server later bijna gratis op meelift. Wie nu zijn API-huis op orde brengt, staat er straks binnen een week op.
Hoe een strategie voor agent discovery er in de praktijk uitziet
Als ik dit kwartaal een productteam zou leiden en nog niet had nagedacht over agent discovery, valt het werk uiteen in vier concrete punten.
- Lever een MCP-server op, ook al is die nog minimaal. De eerste versie hoeft niet elke mogelijkheid van je product bloot te leggen. Daarvoor volstaan de drie meest voorkomende workflow-relevante mogelijkheden, met duidelijke namen, getypeerde schemas en beschrijvingen geschreven voor een LLM. Verkoop je analytics? Leg dan "list_recent_reports", "fetch_report_data" en "create_alert" bloot. Verkoop je een projecttool? Leg dan "list_tasks", "create_task" en "update_status" bloot. Drie is meestal genoeg om in agent-workflows terecht te komen.
- Zorg dat agents het kunnen vinden. Meld je aan bij het register van Anthropic, Smithery en Glama. Naarmate Gemini MCP Apps en de ChatGPT connectors van OpenAI volwassener worden, meld je daar ook aan. Het register is de nieuwe sitemap.
- Instrumenteer de calls. Zoals elke SaaS-PM vandaag zijn conversiefunnel van zoekopdracht tot aanmelding kent, kent de volgende generatie straks de funnel van agent discovery naar agent-call naar gebruikersconversie. Log elke MCP-toolcall, de agent die hem aanriep, de gebruiker aan wie hij toebehoorde, de latency en het slagingspercentage. Je hebt deze data over zes maanden nodig, en het is veel goedkoper om ze vanaf het begin te verzamelen dan achteraf terug te vullen.
- Schrijf de system prompt van je eigen product. Als je product zelf agents gebruikt (voor onboarding, support, in-app workflows), zit je nu in de positie dat je moet kiezen welke MCP-tools je aan die agents blootlegt. Die keuze is een productbeslissing, geen technische kwestie. De tools die je opneemt worden de impliciete positionering van je product.
Het deel dat nog niet is uitgedacht
Twee dingen in dit verhaal hebben nog geen sluitend antwoord. Doen alsof dat wel zo is, is precies de valkuil die ik probeer te vermijden.
Het eerste is prijsstelling. Wanneer een gebruiker jouw tool aanroept via een agent die zelf een betaald product is, wie is dan de klant? De agent-leverancier? De eindgebruiker? Beide? Prijsmodellen in het MCP-ecosysteem zijn nog grotendeels "gratis zolang de registers zich vullen", en die situatie houdt geen stand. De teams die de prijsstelling voor agent-gemedieerd gebruik in de komende 18 maanden uitkristalliseren, bepalen de vorm van deze markt voor het komende decennium. Het patroon dat momenteel de overhand heeft, lijkt op per-call pricing met een gratis tier voor de eerste duizend calls per maand, vergelijkbaar met hoe API-geprijsde SaaS zich tien jaar geleden ontwikkelde.
Het tweede is vertrouwen. Als een agent moet kiezen tussen drie tools die allemaal beweren hetzelfde te doen, waarop baseert hij die keuze? Vandaag vooral op de LLM-leesbare beschrijving en de reputatie van de tool in het register. Morgen moet die basis steviger zijn: audit trails, benchmarks van derden, certificeringen. Niets van die infrastructuur bestaat nog. De productteams die daar nu al aan meebouwen, hebben een structureel voordeel zodra het volwassen wordt.
Waar ik op uitkom
De vraag die elk product-, marketing- en growth-team dit kwartaal moet meenemen naar de kwartaalreview, is kort en ongemakkelijk. Wat is onze strategie voor agent discovery? Als het antwoord is "daar hebben we niet over nagedacht", dan is dat de leemte die je dit kwartaal moet opvullen, voordat de agent-registers vollopen met de producten die dat wel deden.
Mijn inschatting, zonder grote woorden: MCP wordt waarschijnlijk de standaard voor hoe AI-agents met software communiceren. Net zoals websites ooit een sitemap nodig kregen om goed geïndexeerd te worden, zullen softwareproducten steeds vaker een MCP-interface nodig hebben om door agents gebruikt te worden. Dat betekent niet dat SEO, advertenties of app stores verdwijnen. Er komt een distributielaag bij, en de producten die daar vroeg in verschijnen, bouwen hetzelfde cumulatieve voordeel op als de sites die er in 2010 als eerste voor crawlers stonden. Een MCP-server bouwen kost in 2026 een lang weekend werk. De kosten van afwezigheid in de agent-registers in 2028 zullen een stuk groter zijn.
Heb je een product dat nog niet is voorzien van MCP en wil je daar een tweede paar ogen op laten kijken? Stuur me een bericht. Mail info@jermayads.nl of gebruik jermayads.nl/contact.