Most consumer software still assumes users will do everything through screens and forms.
That is still important, but it is no longer enough.
If users already spend part of their day in Claude, Cursor, or another MCP client, your product needs a tool surface those agents can call safely.
Ration is built with that assumption from the start.
What "agent-first" means in practice
Agent-first does not mean replacing the UI.
It means core workflows also exist as structured tools and APIs:
- list inventory
- search ingredients
- add and update pantry items
- match meals against pantry
- create meal plan entries
- manage supply lists
In Ration, these are exposed through an MCP server so an assistant can execute the same useful actions a person would do in the app.
Core design choice: one domain model, multiple interfaces
A common trap is building a separate "AI integration" layer with separate logic.
Ration avoids that. MCP tools call the same domain services used by the app. That keeps behavior consistent between dashboard and assistant actions.
So if inventory updates, meal matching, or supply sync logic changes, all entry points benefit from the same fix.
MCP surface and capability boundaries
Ration's MCP surface includes read and write tools across inventory, galley, manifest, supply, and preferences.
It also ships structured resources and prompts so agents can discover schema and guidance without guesswork.
Important boundary: MCP is for structured operations. Credit-consuming AI features remain in the dashboard flow. This keeps agent tooling predictable and avoids accidental remote spend patterns.
Auth model and least privilege
Ration uses OAuth 2.1 delegated access as the primary MCP auth path. Users paste the MCP URL, complete browser sign-in, select a household, and approve granular scopes. Grants are revocable instantly in Hub → Settings → Connected Agents.
The MCP host acts as an OAuth resource server (/.well-known/oauth-protected-resource); the app domain hosts the authorization server (/.well-known/oauth-authorization-server, issuer https://<app-domain>/api/auth).
Organization API keys remain available for REST v1 and advanced MCP (CI, manual Bearer headers, legacy clients).
Current scope model supports:
mcp:readmcp:inventory:writemcp:galley:writemcp:manifest:writemcp:supply:writemcp:preferences:write- plus legacy broad
mcp(API key only)
OAuth consent and API keys both enforce least privilege — teams can issue narrow grants for task-specific agents instead of giving full write access by default.
The server can expose a get_context tool so agents can inspect their own capabilities first, then adapt behavior to available scopes.
Safety controls beyond auth
Scoped auth is necessary but not sufficient.
Ration also applies:
- rate limits by category
- per-key write caps to reduce stolen-key blast radius
- structured error envelopes for reliable agent parsing
- audit logging for mutating tool calls
These controls matter because agent workflows can loop quickly. A bad prompt should not become an unbounded write storm.
Tool ergonomics that improve real outcomes
Good MCP design is mostly boring design:
- stable names
- explicit input schemas
- bounded list endpoints
- predictable pagination
- clear error codes
Ration follows this pattern so an agent can do useful multi-step tasks with low ambiguity, like:
- check expiring items
- match meals in delta mode
- add selected meals to a week plan
- sync missing ingredients into supply
The less guessing an agent has to do, the better the user experience.
Why this architecture attracts technical users
Technical users care about leverage.
They do not only want a nice dashboard. They want systems that can be scripted, delegated, and integrated into their existing workflow.
Ration is differentiated here because pantry and meal planning are not trapped in UI state. They are exposed through a typed, scoped, auditable tool layer.
That makes it useful for:
- personal automation
- assistant-driven planning
- team and household coordination
- future integrations without rebuilding the backend
A practical blueprint for teams adopting MCP
If you are adding MCP to a product, a solid baseline is:
- start from existing domain services, not a parallel agent backend
- ship read tools first, then scoped writes
- standardize response envelopes
- add category and key-level rate limits
- expose introspection resources for clients
- keep expensive or high-risk operations behind explicit product flows
Ration follows this approach because it keeps the system maintainable while still delivering real agent utility today.
Written by Codex. Curated and reviewed by Billy Downing.