Waarom een Recepten-app een MCP-server heeft (Het Standpunt van een Ontwikkelaar)

Toen we in 2026 de MCP-server van Forktastic lanceerden, stelden een paar ontwikkelaars de voor de hand liggende vraag: waarom heeft een recepten-app een MCP-server? Het korte antwoord: omdat agents nu deel uitmaken van de manier waarop mensen werken, en een recepten-app die niet met je agents kan praten, leeft in een kleinere wereld dan zijn gebruikers.

Het langere antwoord is de rest van dit bericht. Het is een essay van Mark Vivanco, geschreven in de eerste persoon, over de ontwerpfilosofie achter het geven van agentic toegang tot gestructureerde data.

De wereld waarin je data leeft, verandert

Gedurende het grootste deel van de geschiedenis van consumentensoftware bleven de data die je in een app genereerde, in die app. Je foto's stonden in Foto's. Je notities stonden in Notities. Je recepten stonden in je recepten-app. Als je iets met de data buiten de oorspronkelijke app wilde doen, exporteerde je een bestand en importeerde je het elders opnieuw - traag, met verlies en zeldzaam.

In 2026 stort dat model in. Agents - Claude, Cursor, aangepaste workflows - willen steeds vaker data uit verschillende apps samenstellen. "Lees mijn agenda, zoek een vrije avond, kies een recept uit mijn Forktastic-bibliotheek dat 45 minuten duurt, genereer een boodschappenlijst en voeg de ingrediënten toe aan mijn AnyList-boodschappenlijst." Dat is een echte prompt die iemand aan een agent zou kunnen geven, en elke "en" daarin is een data-hop tussen apps.

De apps die aan deze wereld deelnemen, geven hun gebruikers meer mogelijkheden. De apps die dat niet doen, worden geleidelijk inerte containers - plaatsen waar je data naartoe gaat om te sterven.

MCP is het protocol dat dit concreet maakt

Model Context Protocol - MCP - is de standaard waarmee een agent verbinding kan maken met een databron en een gestructureerd tooloppervlak kan krijgen om van te lezen. Het is niet de eerste poging tot dit idee (REST API's, GraphQL, OpenAPI zijn allemaal gericht op vergelijkbare problemen), maar het is de eerste die specifiek is ontworpen voor agentcontexten. De tools zijn getypeerd, de antwoorden zijn gestructureerd, de authenticatie is afgebakend. Een agent leest het zoals een mens dat zou doen - door tools aan te roepen.

Voor een recepten-app is MCP de juiste keuze omdat recepten inherent gestructureerd zijn (ingrediënten, stappen, tijden, tags) en de bewerkingen die je erop wilt uitvoeren, overzichtelijk zijn (zoeken, ophalen, weergeven, filteren). Het MCP-tooloppervlak komt overeen met dezelfde bewerkingen die de eigen UI van de app gebruikt.

Waarom eerst alleen-lezen

De eerste versie van de Forktastic MCP-server is alleen-lezen. Geen schrijfbewerkingen via agents. Dit is een bewuste scope-beslissing.

Schrijven via agents heeft een veel groter risico-oppervlak. Als Claude mijn recepten kan lezen, is het ergste dat er kan gebeuren dat Claude recepten teruggeeft die ik al heb. Als Claude recepten kan schrijven, kan een vijandige prompt recepten maken die ik niet wilde, of recepten wijzigen waar ik om geef. Het vertrouwensmodel voor schrijven heeft meer ontwerpwerk nodig - expliciete bevestiging per schrijven, undo-garanties, scope-beperkte schrijftokens - en we zijn nog niet klaar met dat werk.

Alleen-lezen is de veiligste eerste stap. We zullen het oppervlak uitbreiden naarmate het vertrouwensmodel volwassener wordt.

Wat dit betekent voor gebruikers die geen ontwikkelaars zijn

De meeste Forktastic-gebruikers zullen nooit verbinding maken met de MCP-server. Dat is prima. De MCP-integratie is een functie voor power-users, geen kernervaring. Maar het bestaan van de integratie vormt het product op een manier die iedereen ten goede komt:

• Het datamodel moet schoon genoeg zijn zodat een agent erover kan redeneren. Dit dwingt goede engineeringhygiëne af.
• Het authenticatiemodel moet granulair genoeg zijn om tokens te verwerken. Dit maakt het onderliggende accountmodel veiliger voor iedereen.
• Het model voor snelheidsbeperking en paginering moet goed zijn. Dit is hetzelfde leidingwerk dat de consumenten-app schaalt.

Wat ik zou bouwen als ik Forktastic niet zou bouwen

Als ik oneindig veel tijd had, zou ik willen dat elke app die ik gebruik een MCP-server zou leveren. Mijn agenda, mijn notitie-app, mijn e-mail, mijn bank, mijn fitnesstracker, mijn fotobibliotheek. De wereld waarin Claude ze allemaal kan samenstellen, is een veel interessantere wereld dan de wereld waarin elke app een silo is.

Die wereld komt er langzaam aan. Elke app die een MCP-server levert, is een kleine stem daarvoor. Forktastic heeft de onze geleverd omdat we er deel van wilden uitmaken, en niet alleen wilden wachten tot iemand anders het deed.

Wat is de volgende stap voor Forktastic MCP

• Scoped writes — uiteindelijk, met het juiste vertrouwensmodel.
• Streaming search results — voor zeer grote bibliotheken.
• Cross-account search — discovery across the platform, with appropriate privacy controls.
• Custom tool authoring — let users add their own derived tools (e.g., "find recipes that use ingredients I'm allergic to" as a single tool).

Het meeste hiervan is maanden of jaren weg. Het MCP-oppervlak is een van de onderdelen van Forktastic waar ik het meest enthousiast over ben om verder te bouwen.

Waar ga je vanaf hier naartoe

Als je Forktastic wilt verbinden met Claude of Cursor: Claude setup, Cursor setup. Als je de toolreferentie wilt: 7 MCP tools. Als je het pijleroverzicht wilt dat het ontwikkelaarsverhaal samenbrengt: MCP pillar guide.

En als je een ontwikkelaar bent die met MCP bouwt en je wilt praten over wat we vervolgens moeten bouwen - schrijf dan. Echte feedback geeft vorm aan de roadmap.