Why a Recipe App Has an MCP Server (A Developer's Take)
An essay on why Forktastic ships an MCP server — agents are how people work now, and a recipe app that can't talk to your agents lives in a smaller world.
When we shipped Forktastic's MCP server in 2026, a few developers asked the obvious question — why does a recipe app have an MCP server? The short answer: because agents are now part of how people work, and a recipe app that can't talk to your agents is a recipe app that lives in a smaller world than its users do.
The longer answer is the rest of this post. It's a Mark Vivanco essay, written in first person, about the design philosophy behind giving structured data agentic access.
The world your data lives in is changing
For most of the history of consumer software, the data you generated inside an app stayed in that app. Your photos lived in Photos. Your notes lived in Notes. Your recipes lived in your recipe app. If you wanted to do something with the data outside the originating app, you exported a file and re-imported it elsewhere — slow, lossy, and rare.
In 2026, that model is breaking down. Agents — Claude, Cursor, custom workflows — increasingly want to compose data across apps. "Read my calendar, find a free evening, pick a recipe from my Forktastic library that takes 45 minutes, generate a shopping list, and add the ingredients to my AnyList grocery list." That's a real prompt someone might give an agent, and every "and" in it is a cross-app data hop.
The apps that participate in this world give their users more leverage. The apps that don't, gradually become inert containers — places your data goes to die.
MCP is the protocol that makes this concrete
Model Context Protocol — MCP — is the standard that lets an agent connect to a data source and get a structured tool surface to read from. It's not the first attempt at this idea (REST APIs, GraphQL, OpenAPI all aim at similar problems) but it's the first one designed specifically for agent contexts. The tools are typed, the responses are structured, the auth is scoped. An agent reads it the way a human would — by calling tools.
For a recipe app, MCP is the right fit because recipes are inherently structured (ingredients, steps, times, tags) and the operations you'd want against them are clean (search, get, list, filter). The MCP tool surface maps to the same operations the app's own UI uses.
Why read-only first
The first version of the Forktastic MCP server is read-only. No write operations through agents. This is a deliberate scope decision.
Writes through agents have a much higher risk surface. If Claude can read my recipes, the worst that happens is Claude returns recipes I already own. If Claude can write recipes, an adversarial prompt could create recipes I didn't want, or modify ones I care about. The trust model for writes needs more design work — explicit per-write confirmation, undo guarantees, scope-limited write tokens — and we're not done with that work yet.
Read-only is the safest first step. We'll expand the surface as the trust model matures.
What this means for users who aren't developers
Most Forktastic users will never connect to the MCP server. That's fine. The MCP integration is a power-user feature, not a core experience. But the existence of the integration shapes the product in a way that benefits everyone:
- The data model has to be clean enough that an agent can reason about it. This forces good engineering hygiene.
- The auth model has to be granular enough to handle tokens. This makes the underlying account model more secure for everyone.
- The rate-limit and pagination model has to be sound. This is the same plumbing that scales the consumer app.
What I'd build if I weren't building Forktastic
If I had infinite time, I'd want every app I use to ship an MCP server. My calendar, my notes app, my email, my bank, my fitness tracker, my photo library. The world where Claude can compose across all of them is a much more interesting world than the one where each app is a silo.
That world is coming, slowly. Each app that ships an MCP server is a small vote for it. Forktastic shipped ours because we wanted to be part of building it, not just waiting for someone else to.
What's next for Forktastic MCP
- Scoped writes — eventually, with the right trust model.
- Streaming search results — for very large libraries.
- 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).
Most of this is months or years out. The MCP surface is one of the parts of Forktastic I'm most excited to keep building on.
Where to go from here
If you want to connect Forktastic to Claude or Cursor: Claude setup, Cursor setup. If you want the tool reference: 7 MCP tools. If you want the pillar overview that brings the developer story together: MCP pillar guide.
And if you're a developer who builds with MCP and you want to talk about what we should build next — write in. Genuine feedback shapes the roadmap.