Op Google I/O dit jaar ging het meeste schrijfwerk naar Gemini Spark, de agent die in de cloud blijft doorwerken terwijl je laptop dicht is. Onder die aankondiging zat een tweede die minder aandacht kreeg en op termijn meer uitmaakt: Gemini spreekt nu zelf MCP. Het protocol zit in de Gemini API en SDK, en Spark bereikt externe diensten via MCP-koppelingen. Daarmee komt Google uit op dezelfde standaard als de connectors van ChatGPT en de MCP-ondersteuning in Claude. De drie grootste agent-leveranciers gebruiken hetzelfde koppelvlak voor 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. AI-assistenten worden hier volop gebruikt, maar ze hebben de zoekmachine niet vervangen. 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 daarbij komt.
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. Nederlandse bedrijven zitten nu middenin die fase: antwoorden zonder kliks. MCP is de stap daarna, waarin de agent niet alleen antwoord geeft over jouw product maar er ook acties in uitvoert. Voor marketeers wordt dat concreet zichtbaar als minder sessies in GA4 bij gelijkblijvende vraag, terwijl een groeiend deel van het contact via API-calls en agent-acties loopt. Wie alleen op sessies en CTR stuurt, ziet die verschuiving pas als het te laat is om er rustig op te reageren.
Waarom dit een standaardenverhaal is
Ik heb heel wat AI-aankondigingen zien voorbijkomen die uiteindelijk een gesloten voorsprong voor één leverancier bleken. Deze niet. Anthropic publiceerde MCP eind 2024. OpenAI kondigde in maart 2025 ondersteuning aan, eerst in de Agents SDK en daarna in ChatGPT via connectors. Google is nu de derde grote partij die het protocol in zijn eigen SDK opneemt. Het protocol zelf is bewust saai: JSON-RPC over stdio of HTTP, met een tool manifest, getypeerde schemas, beschrijvingen die geschreven zijn om door een LLM gelezen te worden, en een standaardvorm voor authenticatie. Die saaiheid is precies waarom het werkt. 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 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 hoe bevrijdend dat is. Eén kanttekening hoort erbij: de drie platformen zitten nog niet op dezelfde featureset. In ChatGPT loopt de koppeling via connectors en de Apps SDK, in Claude via directe MCP-ondersteuning, bij Google via de Gemini SDK en de lijst met diensten die Spark mag aanroepen. Wat waar is toegestaan, verschilt per platform en verandert per kwartaal. De richting is wel onmiskenbaar, en dat is voor een standaard het enige wat telt.
Gemini Spark verhoogt de druk
De aankondiging van Spark is belangrijk omdat het achtergrondagents 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 routines en geplande taken in Claude verplaatsen 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. Spark zelf begon bij testers en Amerikaanse Ultra-abonnees, dus in je eigen cijfers zie je hier voorlopig weinig van. Het gedrag dat het normaliseert, is wat telt.
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. Staat jouw product niet in het register dat de background agent raadpleegt, dan zit het niet in de keuzeset. Concurreren op UX of prijs kan dan niet meer, 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 je MCP-server vermeld staat in een register dat de agent raadpleegt. Dat zijn vandaag de officiële MCP Registry, die Anthropic samen met onder meer GitHub, Microsoft en PulseMCP onderhoudt, en de directories die daarbovenop draaien, zoals Smithery en Glama. De officiële registry is bewust kaal, zonder zoekfunctie of categorieën; de directories zijn de plek waar mensen en agents rondkijken. Voor agents is zo'n vermelding wat indexeerbaarheid voor zoekmachines is, en dezelfde discipline geldt: een duidelijke naam, een duidelijke categorie en een beschrijving van één regel waarmee een LLM kan beslissen of hij jou moet aanroepen voor een bepaalde taak. Plus 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 horen getypeerd te zijn, zowel de input als de output in JSON Schema. Beschrijvingen schrijf je voor een LLM en niet voor een mens, want de LLM is degene die ze in de runtime leest. En je 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. Zodra een background agent je probeert te gebruiken, faalt diezelfde flow stilzwijgend. 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, en dat betekent dat jouw product past 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 heeft daar weinig aan. Hij wil kleine, combineerbare 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 in plaats van 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, onderhoudt drie licht verschillende API's voor altijd. Ik voelde die afweging het duidelijkst 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, 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 ook voor crawlers moest bouwen en niet alleen voor bezoekers, won het volgende decennium. Die 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 begint het niet bij MCP. Een degelijke API, een werkende OAuth-flow en duidelijke documentatie zijn de voorwaarden, en dat is 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. Publiceer je server in de officiële MCP Registry en claim je vermelding bij Smithery, Glama en PulseMCP. Naarmate Google en OpenAI hun eigen lijsten met toegestane diensten uitbreiden, meld je je daar ook aan. Het register is de nieuwe sitemap.
- Meet de calls. Zoals een productmanager vandaag de weg van zoekopdracht naar aanmelding kent, kent de volgende generatie straks de weg 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 ze vanaf het begin verzamelen is veel goedkoper dan ze achteraf terugvullen.
- 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. Dat is een productbeslissing. 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, zou de valkuil zijn 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? Een gevestigd patroon is er nog niet. De meeste servers rekenen vandaag niets voor de MCP-laag zelf en verdienen aan het onderliggende abonnement of aan API-verbruik, wat werkt zolang de registers zich nog aan het vullen zijn. Die situatie houdt geen stand. De teams die de prijsstelling voor agent-gemedieerd gebruik in de komende 18 maanden uitwerken, bepalen hoe deze markt eruit komt te zien.
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. Die infrastructuur bestaat nog niet. De productteams die er 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? Is het antwoord "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: MCP wordt waarschijnlijk de standaard voor hoe AI-agents met software communiceren. 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. SEO, advertenties en app stores verdwijnen daarmee niet. 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.