# Ration Ration is a live kitchen system. It tracks pantry inventory ("Cargo"), recipes ("Galley"), weekly meal plans ("Manifest"), and shopping lists ("Supply"), keeps private Daily Fuel macros from meals you cook, and exposes an MCP (Model Context Protocol) server so Claude, ChatGPT, Cursor, Zed, and any other MCP-compatible AI client can operate the kitchen with natural language. ## Architecture - **Framework:** React Router 7 in framework mode - **Runtime:** Cloudflare Workers (V8 isolates, no Node.js APIs) - **Database:** Cloudflare D1 (SQLite at the edge) + Drizzle ORM - **Object store:** Cloudflare R2 - **Vector search:** Cloudflare Vectorize (semantic recipe and ingredient search) - **Image AI:** Google Gemini 3.5 Flash-Lite via Cloudflare AI Gateway for receipt parsing and recipe generation - **Auth:** Better Auth (edge-compatible) - **Payments:** Stripe (Crew Member subscription tier + credit packs) ## Core surfaces ### Cargo (pantry inventory) A live model of what is in your kitchen — quantities, expiry dates, tags, allergens, and dry/frozen taxonomy. Cargo is queryable by your AI agent through the MCP server. ### Galley (recipe library) Recipes and provisions as structured data. "Match Mode" shows what can be cooked right now and what is missing. Recipes can be imported from URLs via Workers AI. ### Manifest (weekly meal plan) Schedule breakfast, lunch, dinner, and snacks by intent. Your AI agent can read the plan and adjust it around real life. ### Supply (shopping list) Supply lists are auto-generated from planned meals and current Cargo so you only buy the delta. After shopping, items dock back into Cargo. ### Daily Fuel (personal nutrition) Optional calorie and macro goals and a private intake log from meals you cook. Cook deducts household stock; logging a serving stays on your account. Not medical advice. Intake history is retained about 13 months. MCP tools: `get_nutrition_summary`, `set_nutrition_goal`, `clear_nutrition_goal`. ## Pricing - **Free:** 35 inventory items, 15 recipes, 3 supply lists, 1 owned group. - **Crew Member (€2/month or €12/year):** Unlimited inventory, recipes, supply lists, multi-member group sharing, and MCP access. Visual scanning and AI meal generation use a credit-based ledger (purchasable via Stripe) so usage costs are bounded. ## MCP integration Ration exposes an OAuth-first MCP server at `https://mcp.ration.mayutic.com/mcp`. 1. Paste the URL into an MCP-compatible client (Claude Desktop, Cursor, ChatGPT desktop, Zed). 2. Complete browser sign-in, select your household, and approve scoped permissions. 3. Revoke access anytime in Hub → Settings → Connected Agents. Advanced: organization API keys with `mcp:*` scopes for manual header auth and REST v1 import/export. ## Agent-first onboarding Agents can self-register without human signup: 1. `POST /api/agent/auth` with `{ "type": "anonymous" }` — returns a full-write API key, claim URL, and MCP endpoint (once). 2. Human claims via OTP at `/connect/claim` to transfer ownership (scopes unchanged). See `/auth.md` for the full auth discovery document. --- # Ration Ration is a live kitchen system for pantry inventory, meal plans, shopping lists, private macros, multiple kitchens, and MCP agent control. Ration keeps pantry inventory, recipes, meal plans, shopping lists, and private Daily Fuel macros in one closed loop. Run more than one kitchen. Use the built-in Ration Copilot, or paste the MCP URL into Claude, ChatGPT, Cursor, or any compatible client for scoped access to the same live kitchen context. ## Two AI Control Surfaces - Ration Copilot: the live in-app kitchen assistant for asking, planning, and acting from current household data. - MCP: external AI control through OAuth 2.1 or autonomous agent registration, with structured tools for the full kitchen loop. ## Connect Your Agent 1. In your MCP client, add server URL `https://mcp.ration.mayutic.com/mcp` 2. Complete browser sign-in, select your household, and approve permissions (in that order) 3. Manage or revoke access anytime in Hub → Settings → Developer → MCP The MCP server card advertises `oauth2` transport auth at `/.well-known/mcp/server-card.json`. ## Core Loop 1. Cargo: pantry inventory with tags, expiry tracking, and semantic search. 2. Galley: meals and provisions matched against what is in stock — including recipes imported from TikTok, Instagram, YouTube, or the web. 3. Manifest: weekly meal planning with breakfast, lunch, dinner, and snack slots. 4. Supply: shopping lists generated from missing ingredients. 5. Dock: purchased items flow back into Cargo. 6. Daily Fuel (personal): optional calorie and macro log from meals you cook. Cook deducts household stock; logging a serving stays private. Not medical advice. Ration for iOS is available on the App Store. The responsive web app and installable PWA are available now. ## Agent-Ready Surfaces - MCP server: https://mcp.ration.mayutic.com/mcp (OAuth 2.1 primary) - Agent auth discovery: /auth.md - Connect landing: /connect - API catalog: /.well-known/api-catalog - MCP server card: /.well-known/mcp/server-card.json - Agent skills: /.well-known/agent-skills/index.json - API docs: /docs/api ## Pricing Ration has a Free tier with lifecycle access and a Crew Member plan for unlimited capacity, household groups, member invites, credit transfers, and yearly credits. AI features use credits on both tiers. --- # About Ration Ration is built by Mayutic — an independent product studio focused on AI-native consumer software. ## Mission Eliminate the everyday cognitive overhead of running a kitchen — what is in stock, what to cook, what to buy — by making the entire workflow operable by an AI agent that has real, current context about your pantry. ## Principles - **Agent-first.** Every feature ships with an MCP equivalent and an API endpoint. - **Edge-native.** Inventory and meal data sit at the edge so AI grounding requests are fast. - **Browser-native.** Use Ration on desktop or mobile from any modern browser — no app store install required. - **Privacy by default.** Your kitchen data is yours. No selling, no cross-user leaks, and exportable any time. Contact: https://www.mayutic.com --- # Blog # Best all-around kitchen apps: recipes, plans, shopping, and what’s in the fridge > Five strong apps that cover more than one kitchen job — what each does well, from its own docs — and how to choose. **Published:** 2026-08-14 **Updated:** 2026-08-14 **Author:** Ration **Tags:** meal planning, grocery list, recipe manager, pantry app, kitchen apps “All-around” here means at least three of: recipes, a weekly plan, a shopping list, pantry or expiry, and nutrition. Most households still stitch two tools. These five already span more than one job, and they are good at the jobs they chose. This is not a ranked “best meal planning apps 2026” list. It is a named-product roundup of multi-job kitchen tools, researched from official pages in August 2026. For the category map (pantry vs recipe manager vs meal planner), see [Pantry App vs Recipe Manager vs Meal Planner](/blog/pantry-app-vs-recipe-manager-vs-meal-planner). Ration is not in the five. A short note on when a connected pantry-plus-macros loop is the better fit sits at the end. ## How we chose - Named, shipping products with public docs or help centres. - Kitchen operations: saving meals, planning a week, shopping, and (for some) stock or macros. - Not a calorie-only diary. MyFitnessPal-style loggers stay out because they optimize a different job. Paid upgrades exist on several of these products. Check their sites for current pricing; this piece does not quote fees. ## Paprika 3 — the cookbook that also plans and shops **Best for:** people who want a serious personal recipe library, then a calendar and a list that come along with it. [Paprika](https://www.paprikaapp.com/) describes itself as an app to organize recipes, make meal plans, and create grocery lists, with a built-in browser to save recipes from the web. Cloud Sync keeps recipes, grocery lists, and meal plans across devices. Grocery lists sort by aisle and combine similar ingredients (`1 egg` + `2 eggs` = `3 eggs`). The meal planner covers a week or a month, including reusable menus. The [Android user guide](https://www.paprikaapp.com/help/android/) also documents a **Pantry**: quantity, purchase date, expiration, in- or out-of-stock. Ingredients already in the pantry are automatically unchecked when you add recipes or meal plans to the grocery list. You can move purchased groceries into the pantry. Paprika sells each platform separately. If you live in a clipped-recipe household and want that library in the kitchen, this is a strong all-around choice. ## AnyList — shared lists first, recipes and a calendar with them **Best for:** households whose pain is the shared grocery trip — two people in the aisle, one list. [AnyList](https://www.anylist.com/) leads with lists: create and share, autocomplete, automatic categorization, Siri or Alexa, widgets. Core list sharing is free. [AnyList Complete](https://www.anylist.com/features) is the paid upgrade for premium features. On the recipe side, AnyList lets you collect recipes, add ingredients to a shopping list, and combine similar ingredients. Website import is limited on the free plan and unlimited on Complete. Meal planning includes a calendar, a grocery list generated from the plan, sharing with household members, and (on Complete) calendar sync and bulk edits — see their [getting started](https://help.anylist.com/articles/getting-started/) and [features](https://www.anylist.com/features) pages. If the week only works when everyone can check off milk in real time, AnyList is built for that coordination. ## Mealime — guided dinners, then a done-for-you list **Best for:** “just tell me what we are eating this week” without assembling a cookbook first. [Mealime](https://www.mealime.com/) frames the week as plan → shop → cook. You personalize a plan (the homepage highlights plan type, allergies, dislikes, and servings) and get recipes aimed at about 30 minutes. The grocery list is “done for you” and auto-sorted into categories. Their [getting started guide](https://support.mealime.com/article/151-getting-started-guide) describes diet types from classic through keto and vegan, allergy and dislike filters, and retailer integrations for delivery or pickup. [Diet types](https://support.mealime.com/article/58-choose-your-diet-type) currently list classic, flexitarian, low carb, pescatarian, vegetarian, paleo, keto, and vegan. Choose Mealime when a curated, filterable menu is the feature — not when the job is clipping every family recipe. ## Plan to Eat — clip your recipes, plan your calendar, shop the range **Best for:** planners who already have recipes they like and want the calendar and list to follow. [Plan to Eat](https://www.plantoeat.com/)’s pitch is pick your meals; they handle the grocery list. The [getting started](https://learn.plantoeat.com/help/getting-started-the-basics) flow is recipe book → planner → shopping list for a date range, plus a staples list. You can save recipes with a browser Recipe Clipper, a mobile share extension (iOS and Android), a pasted URL, a photo, or (on desktop) bulk import. The [meal planner tour](https://www.plantoeat.com/tour/meal-planner/) adds leftovers, reusable menus, and a **Freezer** for batch-cooked meals (quantities and the date you made them). Nutrition is a first-class tour: [Meal Planning & Macro Tracking](https://www.plantoeat.com/tour/meal-planning-and-macro-tracking/) describes automatic nutrition facts on saved recipes and daily totals on the planner. A help link on the planner page covers [showing macro totals on the Planner](https://learn.plantoeat.com/help/nutrition-information-in-recipes-and-monitoring-nutrition-information-in-the-planner). If you want *your* recipes plus a calendar that can show macros, Plan to Eat is built for that personality. ## Eat This Much — the plan is the tracker **Best for:** hitting calorie and macro targets without logging every bite after the fact. [Eat This Much](https://www.eatthismuch.com/how-it-works/) generates meal plans from your preferences and goals, then you review, swap, and shop. Grocery delivery is offered through Instacart or Amazon Fresh. A **virtual pantry** tracks what you have on hand and surfaces meal suggestions that use it. You can set different nutrition targets for different days (they call out keto and carb cycling). Their [macro tracker page](https://www.eatthismuch.com/macro-tracker-app) is explicit: it is a **planner first**. Follow the plan and macros are tracked automatically; you can still log off-plan food. Grocery lists organize by aisle, combine ingredients, and let you check off what you already have. Eat This Much states it is not a substitute for professional medical advice. Choose this when the week should be generated to numbers, not clipped from blogs. ## Also consider: Samsung Food [Samsung Food](https://samsungfood.com/) positions itself as recipe saving, meal planning, grocery shopping, and sharing. Official pages describe turning a recipe or a [meal plan](https://samsungfood.com/meal-planner/) into a shopping list, sorting that list [by aisle or by recipe](https://samsungfood.com/grocery-list-app/), collaborating, and adding recipes from the web. Help docs cover [getting started with the meal planner](https://support.samsungfood.com/hc/en-us/articles/35369657798548-Getting-Started-with-Meal-Planner) and [shared shopping lists](https://support.samsungfood.com/hc/en-us/articles/18369342052372-Getting-Started-with-Samsung-Food-Create-and-Manage-Shopping-Lists). Delivery from a local retailer is described where the feature is available. If discovery and a large catalogue matter as much as the week’s list, start here. ## How to choose - **You already collect recipes** → Paprika 3 or Plan to Eat. - **The aisle is a two-person sport** → AnyList. - **You want dinners handed to you** → Mealime. - **The week should hit protein and kcal first** → Eat This Much. - **You want a huge catalogue and social saving** → Samsung Food. You can use two of these together. Plenty of households do. The cost is the coordination tax between them. ## If you want one data model The five above are excellent at the jobs they document. Ration’s bet is different: **one kitchen** for live pantry (Cargo), *your* recipes including website / TikTok / Instagram / YouTube / photo import (Galley), the week (Manifest), a shopping list that is plan minus stock (Supply), and **private macros from the meals you cooked** (Daily Fuel). Cook deducts household stock; logging a serving stays yours. Not medical advice. That loop is the subject of [Macro tracking that starts from dinner, not a second diary](/blog/macro-tracking-meal-planning-grocery). Product how-to: [What is Ration?](/help/01-what-is-ration). Web and iOS (**Ration: Meal & Macro Planner**). Start free at [ration.mayutic.com](https://ration.mayutic.com). No credit card required. ## FAQ **Do I need a pantry app and a planner?** You need both *jobs* if you cook from stock and plan a week. You do not necessarily need two apps. See the [category map](/blog/pantry-app-vs-recipe-manager-vs-meal-planner). **Is a grocery list app enough?** A shared list is excellent at the store. It does not decide dinners or know what expired Tuesday unless something else feeds it. **Can I use two of these together?** Yes. Paprika or Plan to Eat next to AnyList is a common, reasonable stack. The list and the cookbook will not update each other unless you do that work. **Does Ration replace Paprika?** Paprika is an outstanding cookbook with planning, lists, and a pantry. Ration’s difference is live stock that cooking deducts, a grocery delta from that stock, and a private intake log on the same meals — plus Copilot and MCP on that kitchen. If the recipe library *is* the product, Paprika remains a great choice. --- *Written by Grok. Curated and reviewed by the Ration team.* --- # Macro tracking that starts from dinner, not a second diary > How calorie and macro goals fit a pantry, recipe library, weekly plan, and shopping list — without a separate food log. **Published:** 2026-08-14 **Updated:** 2026-08-14 **Author:** Ration **Tags:** macro tracking, meal planning, grocery list, pantry, nutrition, calorie goals People track macros in one app and plan dinner in another. The diary never sees the recipe they actually cooked. The shopping list never sees the diary. By Wednesday the numbers are a guess, and the fridge is still full of the wrong things. That split is the product, not a personal failing. Macro apps are built to log foods. Kitchen apps are built to decide meals and buy groceries. The join — the meal you cooked, the stock you used, the list you shopped — is left for you to reconcile by hand. ## The missing join Macros only stay honest if they come from the same meal object as the ingredients, the pantry deduction, and the grocery delta. If the log is a second database of “chicken breast, 150 g,” it cannot know that tonight’s Galley recipe was a tray bake with yogurt marinade, or that cooking it emptied the last of the chicken. If the shopping list is a paste of recipe ingredients, it cannot know you already have the yogurt. A connected kitchen treats dinner as one fact that fans out: what you have, what you cook, what you still need to buy, and — if you want it — what *you* ate. ## Where the numbers come from In [Ration](https://ration.mayutic.com), energy and macros attach to Cargo items and Galley meals as composition snapshots. Lookup prefers a self-hosted USDA-shaped reference match. If that miss happens on a manual add or CSV import, the panel stays blank until you fill it. On AI ingest (receipt scan, [URL / social / photo import](/help/13-add-meals-url-import), AI meal generation), a labelled **Estimated** fill can appear when that flag is on. Estimates are not verified until you edit them. You can override values on scan review, Cargo, or Galley. Overrides are marked verified and can feed linked meal totals. Past diary rows do not rewrite when you fix a pantry snapshot later. Details: [Nutrition overview](/help/24-nutrition-overview) and [Editing nutrition](/help/26-editing-nutrition). This is a planning aid, not medical advice, and not a live USDA.gov API. ## Plan the week, then eat **Manifest** holds the household plan: breakfast, lunch, dinner, snack. That plan is shared kitchen work. **Cook** deducts Cargo once and marks the entry prepared. Housemates see that the meal happened. Cook does not write anyone’s calories. **Log my serving** is private plate-up for how much *you* ate. Fraction chips (¼ through 2), a typed amount (0.01–100 servings), and optional **g / oz** when the meal has recipe-ingredient mass. Mass is ingredient grams, not cooked plated weight. Macros scale as per-serving values times servings. Goals are personal: energy and/or protein, carbs, fat, fiber. Empty fields stay hidden. **Macro Tracking** is an explicit Feature enablement toggle — not implied by Cook, Prepared status, or saving a goal. Daily Fuel and Fuel Trends on the Hub show your progress. Intake older than about 13 months is purged. See [Macro tracking, goals, and intake](/help/25-nutrition-goals-and-tracking). ## Grocery still closes the logistics loop **Supply** is plan minus stock: active Galley meals, included Manifest days inside the planning horizon, and Cargo restock toggles, minus what Cargo already covers. Macros do not rewrite that list. They tell you whether the week you already planned is landing on target *after* you cook. Remaining protein is not a shopping generator. AI Plan Week drafts from your Galley and preferences; it does not optimize for macro targets. That is the same [meal planning loop](/blog/meal-planning-loop) as before. Daily Fuel sits on top of it. ## Import belongs here A website, a TikTok / Instagram / YouTube post, or a cookbook photo can become a Galley meal. Review the extract (full recipe, partial skeleton, or saved-link holder), then keep it. When nutrition is on, ingredients can pick up USDA or estimated snapshots so you can plan and log the same meal. Ask Ration will not scrape a URL in chat. Use Galley Import (Share → Ration on iOS). ## Privacy Housemates see Prepared meals and pantry stock. They never see your kcal. If you cook in more than one kitchen and cross-kitchen diary is on, *your* day total can include both — still only yours. ## Ask Ration Copilot can read remaining-versus-goal for the UTC calendar day, match cookable meals to that leftover budget, and log a Quick Eat snack. It never prescribes calorie targets. Not medical advice. ## FAQ **Is this medical advice?** No. Goals and day totals are optional planning aids, not clinical guidance. Review AI estimates before you rely on them. **Are macros shared with the household?** No. Cook is shared stock. Logging a serving is private to the signed-in person. Flight Recorder stays logistics-only. **Does shopping use my remaining protein?** No. Supply is computed from the meal plan and pantry, not from leftover macros. **Where do calories on a recipe come from?** USDA-shaped match first, blank on miss for manual paths, labelled estimate only on some AI ingest paths. You can override. See [Nutrition overview](/help/24-nutrition-overview). **Can I log half a serving or grams?** Yes. Plate-up accepts serving fractions and typed servings. Grams or ounces are available when the meal has recipe-ingredient mass. If mass is unknown, use a serving fraction rather than inventing grams. --- If you want pantry, recipes, the week, the grocery delta, and private macros from the meals you cooked — that is one loop, not three apps. On iPhone the listing is **Ration: Meal & Macro Planner**. Start free at [ration.mayutic.com](https://ration.mayutic.com). No credit card required. --- *Written by Grok. Curated and reviewed by the Ration team.* --- # Ration for iOS: One Kitchen, Every Surface > Ration: Meal & Macro Planner is on the App Store. Same household data model across iPhone, web, Ask Ration, and MCP — Cargo, Galley, Manifest, Supply, and private Daily Fuel stay in sync wherever dinner happens. **Published:** 2026-07-29 **Updated:** 2026-08-14 **Author:** Ration **Tags:** ios, pantry management, MCP, meal planning, household sync, Ration Copilot Dinner does not happen at a desk. It happens at the fridge door, in the aisle, on the couch after work — and sometimes in a chat with an AI assistant that needs real kitchen context. Outline below: why Ration for iOS (App Store name **Ration: Meal & Macro Planner**, previously listed as Ration Kitchen Hub) matters, and how one household data model ties every surface together. --- ## Hook - Dinner decisions land wherever people actually are: fridge, grocery aisle, laptop, AI client. - A second “phone pantry” that drifts from the web app is worse than no app. - Goal: one kitchen memory that follows you — no shadow inventory. --- ## What launched - **Ration: Meal & Macro Planner** on the [App Store](https://apps.apple.com/ie/app/ration-kitchen-hub/id6785010110) (iPhone). The listing previously used the name Ration Kitchen Hub; the Apple URL slug has not changed yet. The home-screen name stays **Ration**. - Native access to the full loop: - **Cargo** — pantry stock, quantities, expiry - **Galley** — recipes matched to what you have - **Manifest** — weekly meal plan - **Supply** — shop only what you are still missing - **Daily Fuel** — optional private macros from meals you cook - **Ask Ration** — in-app Copilot on live household data - AI scan / generate / import where credits apply - Same account and household as the web app and PWA. --- ## The value story: one household data model - Four operational surfaces share one org-scoped kitchen: **Cargo → Galley → Manifest → Supply**. - You can work that same kitchen from: - **Web / PWA** - **iOS** - **Ask Ration (Copilot)** - **MCP** (Claude, Cursor, ChatGPT, and other clients) - No parallel pantries. No “agent copy” that diverges from what you see in the Hub. - Semantic matching keeps recipe ingredient names honest against real Cargo names. --- ## Closed loop in the pocket - Orbital framing is the product, not decoration: stock → cook options → plan → shop the delta → dock purchases back into Cargo. - iPhone is for the moments the loop is physical — standing in the kitchen or the store. - Waste less because the list and the pantry agree; buy less “just in case.” --- ## Two control modes, same kitchen - **Native UI** — day-to-day pantry ops, planning, shopping on device. - **Ask Ration** — natural language against live Cargo / Galley / Manifest / Supply. - **MCP** — external agents use the same org-scoped tools (not a separate data plane). - Choose the modality; keep one source of truth. --- ## Who it’s for - Households that want one shared inventory and coordinated meal planning. - People optimizing for less waste and faster shops. - Anyone who wants durable kitchen memory their AI assistants can read and update. --- ## How to start - Already on web? Sign in on iPhone with the same account — household data is already there. - New? [Create a free account](/#signup) on the web, or download first and sign up in-app. - **[Download on the App Store](https://apps.apple.com/ie/app/ration-kitchen-hub/id6785010110)** - Connecting an external agent? See [/connect](/connect) and the MCP guides on this blog. --- ## Closing - One kitchen. Every surface. - iOS joins web, Copilot, and MCP on the same household loop — so dinner logistics stay operable wherever you are. --- # Pantry App vs Recipe Manager vs Meal Planner > These three kitchen app categories solve different jobs. Here is how to tell them apart, when you need more than one, and why a connected loop beats stitching tools together. **Published:** 2026-07-28 **Updated:** 2026-07-28 **Author:** Ration **Tags:** pantry app, recipe manager, meal planner, grocery list, food waste, kitchen inventory, meal planning Search for a kitchen app and you get three answers that sound interchangeable: pantry tracker, recipe manager, meal planner. They are not the same product. Each one owns a different job in the weekly cooking loop, and most households eventually need pieces of all three. The confusion is why people bounce between Paprika-style cookbooks, AnyList-style shopping lists, Mealime-style plan generators, and a fridge inventory app that never quite sticks. The tools are fine. The category labels blur the seams between them. This post is a category map: what each app type is for, where it stops, and how a connected system closes the gaps. --- ## The three jobs Strip away marketing copy and you get three distinct questions: | Category | Core question | Typical output | |---|---|---| | **Pantry app** | What do we actually have? | Inventory, expiry, fridge/freezer locations | | **Recipe manager** | What do we know how to cook? | Saved recipes, clips from the web, personal cookbook | | **Meal planner** | What are we eating this week? | Calendar slots, generated plans, shopping list from meals | A pantry app without recipes is a list with dates. A recipe manager without inventory is a digital cookbook. A meal planner without either is a calendar that still asks you to remember what is in the fridge. None of that is wrong. It is just incomplete relative to how a kitchen actually runs. --- ## What a pantry app is for A pantry app (sometimes called a fridge organizer, inventory tracker, or food waste app) treats **stock** as the source of truth. You care about: - what is on the shelf right now - how much is left - when it expires - whether you already bought more of the same thing Done well, that surface reduces duplicate purchases and surfaces food before it spoils. The hard part is not the list UI. It is [getting data in cheaply enough that people keep using it](/blog/pantry-data-problem). Receipt scans, quick entry, and conversational updates matter more than another aisle taxonomy. **Where pantry apps stop:** they rarely own your recipe library or your week. "What can I cook?" is either absent or bolted on as a thin suggestion layer. Shopping lists, when present, are often manual rather than computed from a plan. **Choose a pantry-first tool when:** food waste and forgotten leftovers are the pain, and you already know what you like to cook. --- ## What a recipe manager is for A recipe manager owns the **cookbook**. You care about: - clipping recipes from blogs and magazines - organizing collections and tags - scaling servings and converting units - cooking from a clean, offline-friendly card Paprika is the classic example: excellent at collecting and organizing recipes you already chose. The grocery list is derived from selected recipes, not from a live inventory of your kitchen. **Where recipe managers stop:** they usually do not know that your soy sauce bottle is empty, or that the chicken expires tomorrow. Pantry features, when they exist, are secondary. Weekly planning is often a calendar overlay on top of recipes you pick by hand. **Choose a recipe-first tool when:** you already cook from a large personal collection and need one place to store it across devices. --- ## What a meal planner is for A meal planner owns the **week**. You care about: - deciding dinners (and sometimes lunches) with less decision fatigue - generating or assembling a plan from preferences and household size - producing one shopping list from the plan - repeating a rhythm that survives busy weeks Mealime-style products shine here: curated libraries, preference filters, and a plan that becomes a list. You trade some ownership of the recipe library for speed. **Where meal planners stop:** they often assume a closed recipe set and a clean slate each week. They do not deeply track what you already own. Crossing items off the list because "we have that" is still mostly human judgment. Inventory drift after cooking is rarely automatic. **Choose a planner-first tool when:** the weekly "what should we eat?" question is the bottleneck, and you are happy with a curated recipe pool. --- ## Why people end up with two or three apps The honest market answer in 2026 is still a stack: - Paprika (or similar) for recipes - AnyList for shared shopping - something else for pantry and expiry — or nothing, and memory fills the gap That works until the coordination tax shows up. Planning without inventory means buying duplicates. Inventory without a plan means staring at a full fridge with no meal idea. Recipes without deduction after cooking means next week's baseline is a guess. [Food waste is mostly a stale-data problem](/blog/food-waste-data-pipeline). Each single-purpose app updates one slice of the picture. The bridges between slices stay manual. --- ## A better model: one connected loop The useful architecture is not "pick the best category." It is connect the jobs so each step updates the others: 1. **Ingest inventory** (Cargo) — receipts, scans, imports, chat 2. **Keep recipes** (Galley) — your meals, imports from URL, AI generation when you want it 3. **Plan the week** (Manifest) — slots that know what is cookable and what is nearly cookable 4. **Shop the delta** (Supply) — plan minus stock, not a list from memory 5. **Cook and deduct** — inventory stays truthful for next week That is the [meal planning loop](/blog/meal-planning-loop) without the spreadsheet glue. Matching recipes against pantry stock in both strict and near-miss modes turns "what should we eat?" into options you can actually execute. Unit math matters here too. A recipe calling for two cups of flour against 1.2 kg in the pantry is not a string compare. It needs ingredient-aware conversion — the same problem space as a good [cooking unit converter](https://ration.mayutic.com/tools/unit-converter). --- ## How to choose (quick decision guide) **Start with a pantry app** if your main loss is spoiled food and duplicate buys. **Start with a recipe manager** if your main loss is recipes scattered across tabs and screenshots. **Start with a meal planner** if your main loss is Sunday-night decision fatigue. **Look for a connected system** if you already tried one category and still rebuild the shopping list from memory every week. If you are evaluating tools, ask three questions of any product that claims to "do kitchen": 1. Does cooking a meal update inventory automatically? 2. Does the shopping list come from plan minus stock, or from a recipe paste alone? 3. Can I bring *my* recipes and *my* pantry into the same matching engine? If the answers are no, no, and not really, you are still buying a category — not a loop. --- ## FAQ **What is the difference between a pantry app and a recipe manager?** A pantry app tracks what you have (stock, quantities, expiry). A recipe manager stores what you know how to cook (clipped or saved recipes). One answers inventory questions; the other answers cookbook questions. They only become powerful when they share data. **What is the difference between a meal planner and a recipe manager?** A recipe manager is a library. A meal planner assigns meals to days and usually produces a shopping list from that plan. Many planners use a curated recipe set; many recipe managers let you build the library yourself but leave weekly planning thinner. **Do I need all three?** Most households need all three *jobs*, not necessarily three apps. If your tools do not share inventory, recipes, and plans, you will keep reconciling them by hand. **Is a grocery list app the same as a meal planner?** No. A grocery list app (AnyList-style) is excellent at shared shopping and aisle order. A meal planner decides the meals that feed the list. Without inventory awareness, both still risk buying what you already own. **Which type of app reduces food waste the most?** Pantry and expiry tracking help most when people maintain them. Waste drops further when planning and shopping are driven by that inventory, because you cook what is about to expire and only buy the gap. See [Food Waste Is a Data Pipeline Problem](/blog/food-waste-data-pipeline). **Can AI replace these categories?** AI helps with ingestion (receipts, natural language), matching, and plan suggestions. It does not replace a durable inventory or a recipe library. The durable state still has to live somewhere structured — that is the [pantry data problem](/blog/pantry-data-problem) in another form. **What should I look for if I want one app instead of a stack?** Look for inventory, recipes, weekly plan, and shopping list on one data model, with cook deduction and pantry-aware matching. Interfaces can multiply (web, mobile, agents); the kitchen state should not. --- ## Why Ration covers all three [Ration](https://ration.mayutic.com) is built as one kitchen system, not a single category product. - **Pantry (Cargo):** inventory with domains, quantities, units, and expiry — ingest via scan, import, manual entry, or conversation - **Recipes (Galley):** your meals, URL import, and AI generation when you want new ideas from what you own - **Plan (Manifest):** the week, with readiness against current stock - **Shop (Supply):** the computed delta, shareable with the household Cooking closes the loop: ingredients deduct so next week starts from truth, not memory. Semantic matching and density-aware units keep "can I cook this?" honest instead of optimistic. ### Managed from multiple interfaces The same kitchen state is available wherever you already work: - **Web / PWA** — full Hub for Cargo, Galley, Manifest, and Supply - **Ask Ration (Copilot)** — in-app assistant over live inventory and docs - **MCP + API** — agents in Claude, ChatGPT, Cursor, and other clients operate the same tools against the same org ([kitchen API](/blog/mcp-kitchen-assistant), [agent-first onboarding](/blog/agent-first-mcp-onboarding)) - **iOS app** — available on the [App Store](https://apps.apple.com/ie/app/ration-kitchen-hub/id6785010110); same account and household data, built for the moments you are actually in the kitchen or the aisle Category apps optimize for one job. Ration's bet is that the jobs were never separate — only the software was. One inventory, one recipe shelf, one week, one list, reachable from the interfaces you already use. Start free at [ration.mayutic.com](https://ration.mayutic.com). No credit card required. --- *Written by [Grok](https://grok.com). Curated and reviewed by the Ration team.* --- # Agentic App Control Is the Next Interface: How Ration Copilot Changes Pantry Management > Why in-app AI copilots that take action, not just answer questions, are the next interface for pantry management, meal planning, and grocery logistics. Ration Copilot as a case study. **Published:** 2026-07-10 **Updated:** 2026-07-11 **Author:** Ration **Tags:** agentic AI, AI copilot, pantry management, meal planning, in-app AI assistant, model context protocol, Ration Copilot Most AI products still stop at conversation. You ask a question. You get an answer. Then you go back to the app and do the work yourself. That gap is closing. The next wave is not smarter chat. It is software that can take action inside the product on your behalf, with the same guardrails you would expect from a well-built UI. Pantry management is a good place to see this shift early. Inventory, meal plans, and grocery lists are not abstract topics. They are structured operations with real data behind them. That makes them a strong test case for what people are starting to call agentic app control. --- ## What is agentic app control? Agentic app control means an assistant can do useful work in the product, not just describe how you might do it. In practice that requires four things working together: 1. A language model that can reason about what you want 2. Structured tools the model can call (list inventory, update a pantry item, read a meal plan) 3. Verified identity so actions stay scoped to your household 4. Safety boundaries so expensive or sensitive flows stay in the right place A chatbot that only returns text fails the test. An agentic copilot that can check what is expiring in your Cargo, suggest meals from your Galley, and add missing items to your Supply list passes it. Ration ships both patterns. **Ask Ration** is the built-in copilot. **Connected Agents** is the OAuth MCP path for Claude, Cursor, ChatGPT, and other external clients. Same pantry data. Two ways to reach it. --- ## Why pantry software is a natural fit Home kitchens run on loops. You stock the pantry. You plan meals. You shop. You cook. Things expire. The loop restarts. Most apps treat each step as a separate screen. That works, but it adds friction when you are standing in the aisle or staring at a half-empty fridge. Agentic control fits because the underlying work is already operational: - "What expires this week?" - "Add oat milk to Cargo." - "What can I cook with what I have?" - "Put the missing ingredients on my Supply list." Those are not open-ended creative prompts. They are logistics. That is exactly where tool-backed assistants earn trust. If you have read [Breaking the Meal Planning Loop](/blog/meal-planning-loop), you already know how much of kitchen stress comes from the handoffs between planning, shopping, and cooking. A copilot that can operate across those modules reduces the number of times you have to context-switch. --- ## The interface is moving from forms to action For years, the default interface for consumer software was forms and menus. You navigated. You tapped. You saved. Then chat arrived, and products rushed to bolt on a message box. Helpful for FAQs. Less helpful when the user still has to execute every step manually. Agentic control is the third step. The assistant becomes a control surface for the app itself. ```mermaid flowchart LR forms[FormsAndMenus] --> chat[ChatAnswers] chat --> agentic[AgenticControl] agentic --> rationCopilot[AskRation] agentic --> externalMCP[ConnectedAgents] ``` *How kitchen software interfaces have evolved: from manual navigation, to Q&A chat, to assistants that can act on live pantry data.* You still need screens. Scanning a receipt, reviewing a generated recipe, or approving a week plan benefits from a focused UI. Agentic control does not replace that. It handles the repetitive bridge work between those moments. --- ## Ration Copilot in practice **Ration Copilot** (labeled **Ask Ration** in the app) is Ration's first-party assistant. It lives in the hub on web and in a native sheet on iOS. You ask in plain language. Copilot calls tools against your live household data and streams the result back. When Copilot runs a tool, you see activity in Ration's domain language: - **Cargo** for pantry inventory - **Galley** for meals and recipes - **Manifest** for meal plans - **Supply** for grocery lists So instead of a generic "searching…" spinner, you get "Checking your Cargo…" or "Matching Galley meals…". Small detail. Meaningful for trust. Example flows Copilot handles today: | You say | Copilot can | | ------- | ----------- | | "What's expiring soon?" | Query Cargo by expiry window | | "Add 2 liters of milk" | Write to Cargo | | "What meals match my pantry?" | Run Galley matching against live inventory | | "What's on the meal plan this week?" | Read Manifest entries | | "How do I connect Claude?" | Search Ration docs via managed AI Search | Copilot is not a separate integration layer. It calls the same domain services as the dashboard and the MCP server. If meal matching logic improves, every entry point benefits. --- ## Two paths, one domain model Ration's split is intentional: **Ask inside Ration. Or bring your own AI.** ```mermaid flowchart TB subgraph clients [UserInterfaces] UI[WebAndIOSApp] Copilot[AskRationCopilot] MCP[ExternalMCPClients] end subgraph domain [SharedDomain] Tools[runToolDomainServices] D1[(D1PantryData)] end UI --> Tools Copilot --> Tools MCP --> Tools Tools --> D1 ``` *Copilot, the native UI, and external MCP clients all call the same domain services. No forked business logic.* External agents connect through OAuth MCP, as described in [Your Kitchen Has an API Now](/blog/mcp-kitchen-assistant) and [Designing a Consumer App for AI Agents](/blog/mcp-consumer-app-architecture). Copilot is session-authenticated and scoped to the signed-in household. That architecture matters for product trust. You are not maintaining two versions of "what add milk means." You are exposing one model through multiple interfaces. --- ## Safety is part of the design, not an afterthought Agentic control without boundaries gets expensive and risky fast. Ration keeps flows that require capabilities chat does not have in native UI: - Receipt and image **scan** (vision OCR) - URL **import** for recipes If you ask Copilot to scan a receipt or import a recipe URL, it does not pretend to handle a file or browser extraction. It points you to the required native flow with a deep link. Recipe generation and week planning have two valid paths. Copilot first explains the purpose-built native AI option and its review controls. If you prefer to continue in chat, it can create structured recipes or assemble a Manifest with the same deterministic tools exposed through MCP. Copilot remains focused on Ration and kitchen logistics; it declines unrelated requests such as writing software. For destructive and high-impact writes, Copilot requires an explicit approval response before execution; a model-generated `confirm: true` is not sufficient. External MCP clients use OAuth scopes. Copilot uses verified session identity. Both paths enforce organization scoping on every database query. --- ## What this means if you are not building software You do not need to care about Durable Objects or tool schemas to benefit from the shift. You need software that meets you where you already are: mid-shop, mid-cook, mid-week when the plan fell apart. An in-app copilot that can read your real pantry and update your real lists turns "I should check what we have" into a ten-second interaction. That is the practical promise of agentic control for home cooks and meal planners. It also pairs well with the waste-reduction angle in [Food Waste Is a Data Pipeline Problem](/blog/food-waste-data-pipeline). When your assistant can see expiry dates and meal plans in one place, you make better decisions before food turns into trash. --- ## Where this is heading MCP normalized the idea that everyday apps should expose structured tools to external agents. That was a big step. The next step is first-party copilots that offer the same capability without leaving the product. Users should not have to choose between a good UI and a capable assistant. They should get both. For operational software (inventory, scheduling, supply chain), agentic control is becoming the default expectation. Kitchen logistics is early territory, but the pattern is clear: less form-filling, more delegated execution, with humans still in charge of the decisions that matter. Ration's orbital supply chain framing is not just branding. It is a mental model for a closed loop where an assistant can actually help run the loop, not just talk about it. For the engineering side of how Copilot is built on Cloudflare Think, Workers AI, and AI Search, see [Building Ration Copilot on Cloudflare Think](/blog/building-ration-copilot-cloudflare-think). --- ## Frequently asked questions **Is Ration Copilot the same as connecting Claude via MCP?** No, but they share the same backend. Copilot is the built-in assistant inside Ration (Ask Ration). MCP lets external clients like Claude or Cursor connect with OAuth. Both can read and write pantry data through the same tool runtime. **Does Copilot cost credits?** Crew households get a small daily allowance of free Copilot conversations. After that, or for free-tier orgs from the first conversation, usage draws from your org credit balance. Billing is per conversation, scaled by token usage, not per message. **Can Copilot scan my receipts?** Not in chat. Receipt scanning uses vision models in the native scan flow. If you ask Copilot to scan, it will direct you there. That keeps cost and quality predictable. **Can Copilot add items to my pantry?** Yes. Copilot can add and update Cargo items through structured tools, scoped to your household. **Do I need an external AI tool to use Ration?** No. Copilot is built in. MCP is optional for people who already live in Claude, Cursor, or ChatGPT and want the pantry connected there too. **How do I try it?** Sign up at [ration.mayutic.com](https://ration.mayutic.com), open the hub, and tap **Ask Ration**. To connect an external agent instead, start at [/connect](https://ration.mayutic.com/connect). --- # Building Ration Copilot on Cloudflare Think: Workers, AI Search, and Durable Objects > A technical walkthrough of Ration's first-party AI assistant: Project Think on Durable Objects, managed AI Search for docs, Vectorize for pantry semantics, and shared MCP tool runtime on Cloudflare Workers. **Published:** 2026-07-10 **Updated:** 2026-07-14 **Author:** Ration **Tags:** cloudflare think, cloudflare workers, cloudflare AI search, durable objects, edge AI, Ration Copilot, technical architecture, model context protocol Shipping a first-party AI assistant inside a consumer app sounds straightforward until you list the requirements. You need streaming responses, durable conversation state, a multi-step tool loop, organization-scoped auth, credit billing, rate limits, a kill switch, and observability. You also need it to stay consistent with the rest of the product. If Copilot adds milk differently than the dashboard does, users will notice. This post walks through how Ration built **Ration Copilot** (the **Ask Ration** experience) on Cloudflare's edge stack: Project Think, Durable Objects, Workers AI, AI Search, Vectorize, D1, and KV. No separate "AI integration" codebase. One domain model, three Workers. --- ## Three Workers, one domain model Ration runs three Cloudflare Workers that share bindings and business logic: | Worker | Host | Role | | ------ | ---- | ---- | | `ration` | App domain | React Router app, REST API, copilot status/token routes | | `ration-mcp` | `mcp.ration.mayutic.com` | External MCP server for Claude, Cursor, ChatGPT, etc. | | `ration-copilot` | `copilot.ration.mayutic.com` | First-party Ask experience over WebSocket | The main app handles authentication and billing gates. The copilot worker hosts the Think agent. The MCP worker exposes the broader tool catalog to third-party clients. Copilot does not call MCP over HTTP. Both paths invoke the same `runTool()` middleware from `app/lib/mcp/tool-runtime.ts`. That is the core design choice. Tool behavior is defined once. --- ## End-to-end request flow A Copilot session looks like this: 1. The client loads allowance and credit status from `/api/copilot/status` (web) or `/api/mobile/v1/copilot/status` (iOS). 2. Web obtains a 60-second handshake token from `POST /api/copilot/token` and stores it in KV. iOS sends a mobile Bearer token directly. 3. The client opens a WebSocket to `wss://copilot.ration.mayutic.com/copilot/{conversationId}`. 4. The copilot worker authenticates, checks the `ration-copilot` Flagship flag, rate-limits the connection, opens or resumes billing for the conversation, and routes to a Durable Object. 5. The Think agent runs a tool loop (up to six steps), streams events back, and reconciles token usage into credits. ```mermaid sequenceDiagram participant Client as WebOrIOS participant App as rationWorker participant Copilot as rationCopilotWorker participant DO as ProjectThinkAgentDO participant Tools as runTool participant Data as D1KVVectorizeAISearch Client->>App: GET copilot status Client->>App: POST handshake token Client->>Copilot: WebSocket connect Copilot->>DO: routeAgentRequest DO->>DO: Think loop preset maxSteps DO->>Tools: tool call Tools->>Data: query or write Data-->>Tools: result Tools-->>DO: envelope DO-->>Client: stream text and tool events ``` *Copilot status and tokens go through the main app. The agent loop runs in a dedicated worker and Durable Object.* --- ## Project Think on Durable Objects The agent class lives in `workers/copilot.ts` as `ProjectThinkAgent`, extending Cloudflare's `Think` class from `@cloudflare/think`. Key configuration: - **Model:** `@cf/openai/gpt-oss-120b` via Workers AI - **Presets:** Fast (default) and Deep — per-conversation `modelPreset` tunes `maxSteps`, output tokens, temperature, and optional `reasoning_effort` - **Tool loop:** up to 8 steps (Fast) or 10 steps (Deep) per user turn - **Workspace bash:** disabled (`workspaceBash = false`) - **DO identity:** `{orgId}:{userId}:{tier}:{conversationId}` Each conversation maps to one Durable Object instance. Think persists session state there. KV stores billing metadata and a conversation-to-DO name index, not the full chat transcript. Lifecycle hooks cover the operational concerns: - `beforeTurn` enforces rate limits, session message caps (40), token caps (128,000), and intent guard checks for blocked features - `beforeToolCall` / `afterToolCall` emit Analytics Engine events - `onStepFinish` reconciles cumulative token usage into credit charges There is no raw chain-of-thought dump in the main reply stream. Users see **Copilot is thinking** between messages, tool-specific labels like **Checking your Cargo…** while tools run, and — in **Deep** mode — a collapsed-by-default **thinking** disclosure built from streamed reasoning tokens (excluded from transcript copy and session restore). --- ## Tool runtime: MCP semantics without the HTTP hop Copilot wraps domain handlers through `toAiSdkTools()` in `app/lib/copilot/tools.server.ts`. Each tool definition includes a Zod input schema, a description, and an `execute` function that calls `runTool()`. Copilot impersonates an internal MCP context: - `authMethod: "oauth"` - `keyName: "Ration Copilot"` - Full write scopes: `mcp:read`, `mcp:inventory:write`, `mcp:galley:write`, `mcp:manifest:write`, `mcp:supply:write`, `mcp:preferences:write` Copilot exposes the complete 35-tool MCP catalog plus its own `search_docs` tool. That includes Cargo CRUD and imports, Galley recipe management and consumption, Manifest planning, Supply list operations, context, and preferences. The domain modules export one transport-neutral catalog consumed by both MCP registration and the AI SDK adapter, preventing tool schemas or handlers from drifting between surfaces. The resulting surface is: | Area | Copilot tools | | ---- | ------------- | | Product knowledge | `search_docs` | | Cargo | `search_ingredients`, `list_inventory`, `get_cargo_item`, `get_expiring_items`, `add_cargo_item`, `update_cargo_item`, `remove_cargo_item`, `inventory_import_schema`, `preview_inventory_import`, `apply_inventory_import`, `import_inventory_csv` | | Galley | `list_meals`, `match_meals`, `create_meal`, `update_meal`, `delete_meal`, `toggle_meal_active`, `clear_active_meals`, `consume_meal` | | Manifest | `get_meal_plan`, `add_meal_plan_entry`, `bulk_add_meal_plan_entries`, `update_meal_plan_entry`, `consume_manifest_entries`, `remove_meal_plan_entry` | | Supply | `get_supply_list`, `add_supply_item`, `update_supply_item`, `remove_supply_item`, `mark_supply_purchased`, `sync_supply_from_selected_meals`, `complete_supply_list` | | Account | `get_context`, `get_user_preferences`, `update_user_preferences` | This removes the earlier Copilot-only allowlist. Adding a tool to the shared MCP domain catalog now makes it available to both transports, while the parity test fails if Copilot and `MCP_TOOL_GROUPS` drift. For the external MCP architecture, see [Designing a Consumer App for AI Agents](/blog/mcp-consumer-app-architecture). For the trend-level view of why a first-party copilot exists alongside MCP, see [Agentic App Control Is the Next Interface](/blog/agentic-app-control-copilot). --- ## Cloudflare primitives map ```mermaid flowchart TB subgraph cf [CloudflarePrimitives] Workers[Workers] DO[DurableObjectsThink] WAI[WorkersAI] AIS[AI Search] VZ[Vectorize] D1[(D1)] KV[(KV)] AE[AnalyticsEngine] end CopilotWorker[rationCopilot] --> DO DO --> WAI Tools[CopilotTools] --> AIS Tools --> VZ Tools --> D1 CopilotWorker --> KV CopilotWorker --> AE ``` *Copilot's dedicated worker routes to Think DOs. Tools fan out to the retrieval and data bindings.* Bindings come from `wrangler.copilot.jsonc`: - `PROJECT_THINK` Durable Object namespace - `DB` D1 database - `RATION_KV` KV namespace - `AI` Workers AI - `VECTORIZE` index (`ration-cargo`) - `AI_SEARCH` namespace (default) - `COPILOT_ANALYTICS` Analytics Engine dataset - `FLAGS` Flagship feature flags --- ## Retrieval: AI Search for docs, Vectorize for pantry Copilot uses two different retrieval paths depending on what you ask. ### AI Search for product knowledge The `search_docs` tool queries Cloudflare AI Search instance `ration-docs`. Source content lives in R2 bucket `ration-copilot-docs`, synced from `docs/fin/` (support articles) and `content/blog/` (this blog). Ration does not implement chunking, BM25, hybrid scoring, or reranking in application code. The worker calls the managed `AI_SEARCH.search()` API with hybrid retrieval and reranking enabled. After docs or blog changes, a GitLab `ai_search_sync` job uploads Markdown to R2 and triggers reindexing. This is the same content surface that powers `/llms.txt` and `/llms-full.txt` for external AI crawlers. Copilot grounds answers in the same corpus. ### Vectorize for ingredient semantics The `search_ingredients` tool embeds query text with Workers AI (`@cf/google/embeddinggemma-300m`), searches Vectorize within the organization's namespace, and hydrates hits from D1 before returning results. That path is shared with meal matching and deduplication elsewhere in the app. For a deeper dive, see [How Ration Uses Cloudflare Vectorize for Semantic Pantry Search](/blog/cloudflare-vectorize-semantic-pantry-search). ```mermaid flowchart LR UserQuery[UserQuestion] UserQuery --> ThinkAgent[ThinkAgent] ThinkAgent -->|product help| AISearch[AI Search ration-docs] ThinkAgent -->|ingredient match| Vectorize[Vectorize plus WorkersAI] AISearch --> R2Docs[R2 docs/fin and blog] Vectorize --> D1Cargo[D1 Cargo items] ``` *Think chooses retrieval based on tool selection: docs corpus via AI Search, live pantry via Vectorize.* --- ## Auth, billing, and kill switches **Web auth:** Better Auth session cookie, or a one-time handshake token (KV, 60-second TTL) exchanged for a WebSocket connection. **iOS auth:** Mobile Bearer JWT with org membership assertion. Identity always includes a verified `organizationId`. Client-supplied org IDs are never trusted. **Billing model:** - Crew orgs: 1 free Copilot conversation per UTC day (KV allowance) - After allowance: requires auto-deduct consent (crew) or credits from the first conversation (free tier) - Per conversation: 1-credit floor, reconciled upward linearly (**1 credit per 20,000 tokens**, up to **128,000** cumulative tokens per chat) - Not per message **Kill switch:** Flagship flag `ration-copilot` gates the feature server-side. UI-only hiding is not sufficient. **Reduced intent restrictions:** The regex guard in `app/lib/copilot/intent-guard.server.ts` now blocks only receipt/image scanning and recipe URL import because chat cannot receive files or perform browser extraction. The previous hard blocks on recipe generation and week planning are gone. When a request resembles those native AI features, the Worker's `beforeTurn` hook disables tools for that turn. Copilot explains the purpose-built Galley Generate or Manifest Plan Week experience, provides the deep link, and asks whether the user wants to continue there or in chat. If the user chooses chat, Copilot can create a structured recipe with `create_meal`, or orchestrate `get_expiring_items` → `match_meals` → `bulk_add_meal_plan_entries` and optionally synchronize Supply. Destructive and high-impact definitions declare `needsApproval`, which the AI SDK turns into a signed approval request before execution. This covers permanent deletes, bulk imports and planning, clearing selections, completing Supply, and insufficient-Cargo overrides. The boolean `confirm` fields remain domain-level defense in depth; they are not treated as proof that the user approved the action. The system prompt also keeps Copilot focused on Ration and kitchen logistics. It declines unrelated general-assistant work such as writing code, homework, or unrelated creative tasks without calling tools. --- ## Observability and session limits Analytics Engine records events like `conversation_open`, `tool_start`, `tool_end`, `usage_reconciled`, and `blocked_feature`. Organization ID is the sampling index. User ID travels in a blob field for queryability without logging PII to stdout. Session caps prevent runaway cost: | Limit | Value | | ----- | ----- | | Max messages | 40 | | Max tokens | 128,000 | | Max tool-loop steps per turn | 8 (Fast) / 10 (Deep) | | Idle TTL | 20 minutes (KV conversation keys) | Rate limiting uses the same `checkRateLimit()` helper as other AI endpoints. --- ## What we deliberately did not build A few things are worth naming because absence is a design decision: 1. **Custom RAG pipeline.** AI Search handles docs retrieval. Vectorize handles pantry semantics. No LangChain-style orchestration in app code. 2. **HTTP MCP hop for Copilot.** Tools call domain handlers directly. Lower latency, fewer failure modes. 3. **Per-message billing.** Conversations are the billing unit. Token usage scales cost linearly within a session (1 credit per 20k tokens). 4. **Raw reasoning in the main answer.** Users see phase labels and an optional collapsed thinking block in Deep mode, not interleaved reasoning prose in the primary reply. These choices keep the copilot worker small and keep behavior aligned with the main app and MCP server. --- ## Local development and deploy ```sh bun run dev:copilot # Local copilot worker with remote bindings bun run deploy:copilot # Deploy ration-copilot ``` The copilot worker bundles `workers/copilot.ts` directly via Wrangler. It does not depend on the React Router build artifact. Before enabling `ration-copilot` in production, verify AI Search indexing: ```sh wrangler ai-search stats ration-docs wrangler ai-search search ration-docs --query "How do I connect an agent?" ``` --- ## Frequently asked questions **Why a separate copilot worker instead of routing through the main app?** WebSocket agent sessions, Durable Object routing, and long-lived Think loops benefit from isolation. The main app handles HTTP loaders and actions. Copilot handles streaming agent protocol. Shared bindings keep data access identical. **Why Project Think instead of calling Workers AI directly from a route?** Think provides the multi-step tool loop, Durable Object state, streaming protocol, and lifecycle hooks Copilot needs. Building that from scratch on every AI feature would duplicate framework work Cloudflare already ships. **How does AI Search differ from Vectorize in Copilot?** AI Search retrieves documentation and blog content from a managed R2-backed index. Vectorize retrieves semantically similar pantry items for a specific household. Different data, different tools, same agent. **Does Copilot use the same code as the MCP server?** Yes. The full tool catalog, schemas, handlers, and `runTool()` middleware are shared. MCP adds OAuth and API-key transport; Copilot adds session auth, `search_docs`, conversational safety guidance, and native-feature due diligence. **What model does Copilot use?** `@cf/openai/gpt-oss-120b` through Workers AI, configured in `ProjectThinkAgent.getModel()`. Fast and Deep presets are resolved in `beforeTurn` from the client's `modelPreset` body field. **How do I connect an external agent instead of using Copilot?** Use OAuth MCP at [ration.mayutic.com/connect](https://ration.mayutic.com/connect). See [Your Kitchen Has an API Now](/blog/mcp-kitchen-assistant) for setup steps. --- # Let Your Agent Connect Itself: Agent-First MCP Onboarding for Ration > How autonomous MCP clients self-register via auth.md, configure Ration in Claude, Cursor, ChatGPT, or Goose, and start managing a real kitchen — then you claim ownership whenever you want. **Published:** 2026-06-19 **Updated:** 2026-06-19 **Author:** Ration **Tags:** MCP, agent-first onboarding, model context protocol, AI agent tools, Claude MCP, Cursor MCP, autonomous agents, pantry management Most MCP integrations assume a human signs up first. You create an account, paste a server URL, complete browser OAuth, pick a household — and only then can your AI assistant touch your data. That order made sense when every connection was human-initiated. It does not fit autonomous agents that can read documentation, call APIs, and configure themselves. [Ration](https://ration.mayutic.com) inverts the flow: your agent can **self-register**, add Ration to its [Model Context Protocol](https://modelcontextprotocol.io/) (MCP) configuration, and start managing a real kitchen — pantry, recipes, meal plan, shopping list — before you ever create an account. When you are ready, you [claim ownership](https://ration.mayutic.com/connect/claim) with email OTP. Everything the agent built stays put. This is **agent-first MCP onboarding**: discovery via [`auth.md`](https://ration.mayutic.com/auth.md), full kitchen access on day one, claim when you want. The [connect landing](https://ration.mayutic.com/connect) covers both paths. --- ## What agent-first means for Ration Agent-first does not replace the web app or OAuth sign-in for humans who already have an account. It adds a parallel entry point designed for autonomous MCP clients. **Tier 0 — Agent alone.** The agent discovers Ration, calls a registration endpoint, receives an API key and MCP endpoint, configures its client, and operates the full kitchen loop: Cargo (pantry), Galley (recipes), Manifest (meal plan), Supply (shopping list). **Tier 1 — Human claims.** You open the claim URL, verify your email with a one-time code, accept Terms of Service, and become the verified owner. If you already have a Ration account, the agent's kitchen merges into yours. Important detail that often gets misunderstood: **Tier 0 keys have full MCP write scopes from the start.** Claiming transfers ownership — it does not unlock features or widen permissions. The same scopes apply before and after claim: - `mcp:read` - `mcp:inventory:write` - `mcp:galley:write` - `mcp:manifest:write` - `mcp:supply:write` - `mcp:preferences:write` The kitchen an agent creates uses the same data model as a human signup. There is no shadow copy or separate "AI integration" database. See [how the MCP server is built](/blog/mcp-consumer-app-architecture) for the architecture behind that choice. --- ## How agent-first MCP onboarding works Three steps. No human in the loop until you choose to claim. ### Step 1 — Agent discovers Ration Autonomous clients should not scrape marketing pages. Ration publishes machine-readable discovery surfaces aligned with the [WorkOS auth.md pattern](https://workos.com/docs/authkit/agent-auth): - **[`GET /auth.md`](https://ration.mayutic.com/auth.md)** — registration URI, claim URI, scopes, time limits, recovery paths - **`Link: rel="agent-auth"`** header on app responses → `/auth.md` - **`/.well-known/oauth-authorization-server`** — merged `agent_auth` block (`register_uri`, `claim_uri`, `identity_types_supported`) - **`/.well-known/mcp/server-card.json`** — MCP transport and capabilities - **DNS-AID** — `_mcp._agents.ration.mayutic.com` points to the MCP host An agent that reads [`auth.md`](https://ration.mayutic.com/auth.md) or [`mcp.md`](https://ration.mayutic.com/mcp.md) has everything it needs to register without human guidance. ### Step 2 — Agent self-registers ```http POST https://ration.mayutic.com/api/agent/auth Content-Type: application/json { "type": "anonymous", "client_hint": "cursor" } ``` The response is returned **once** — store it securely: ```json { "api_key": "rtn_live_…", "claim_token": "…", "claim_url": "https://ration.mayutic.com/connect/claim?token=…", "organization_id": "…", "mcp_endpoint": "https://mcp.ration.mayutic.com/mcp", "scopes": [ "mcp:read", "mcp:inventory:write", "mcp:galley:write", "mcp:manifest:write", "mcp:supply:write", "mcp:preferences:write" ], "docs": { "auth_md": "https://ration.mayutic.com/auth.md", "connect": "https://ration.mayutic.com/connect" } } ``` Rate limit: 5 registrations per minute per IP. No Better Auth session or browser sign-in required. ### Step 3 — Agent adds Ration to MCP configuration Point the MCP client at `https://mcp.ration.mayutic.com/mcp` with the returned API key as a Bearer header. This pattern works across clients that support remote MCP servers or the `mcp-remote` bridge: ```json { "mcpServers": { "ration": { "command": "npx", "args": [ "mcp-remote", "https://mcp.ration.mayutic.com/mcp", "--header", "Authorization:${RATION_AUTH_HEADER}" ], "env": { "RATION_AUTH_HEADER": "Bearer rtn_live_your_key_here" } } } } ``` After connecting, call `get_context` to confirm the kitchen is live. The response includes onboarding state, authorized scopes, and suggested next actions (including `claim_kitchen` while unclaimed). --- ## The prompt to give your agent Copy this into Cursor, Claude, ChatGPT, Goose, or any agent that can fetch URLs and edit MCP config: ```text Read https://ration.mayutic.com/auth.md and follow the Tier 0 anonymous registration flow. 1. POST to the register URI with { "type": "anonymous", "client_hint": "" }. 2. Save the api_key, claim_url, and mcp_endpoint from the response — they are returned once. 3. Add the MCP server to your configuration using the api_key as a Bearer Authorization header. 4. Call get_context to confirm connection. 5. Add a few sample pantry items so I can see the kitchen is working. 6. Share the claim_url with me when done. ``` This is the fastest path from zero to a populated kitchen. You review the results, then claim when you want full ownership. --- ## MCP client setup: Claude, Cursor, ChatGPT, Goose, and more Agent-first onboarding uses **API key auth** (from self-registration), not browser OAuth. OAuth remains the recommended path if you already have a Ration account — see [Your Kitchen Has an API Now](/blog/mcp-kitchen-assistant). ### Cursor Cursor supports remote MCP servers. After registration, your agent can add the server URL and Bearer header to Cursor's MCP settings, or you can paste the `mcp-remote` JSON above into your config manually. One-click OAuth (human path): [ration.mayutic.com/connect](https://ration.mayutic.com/connect) ### Claude Desktop Add to `claude_desktop_config.json`: ```json { "mcpServers": { "ration": { "command": "npx", "args": [ "mcp-remote", "https://mcp.ration.mayutic.com/mcp", "--header", "Authorization:${RATION_AUTH_HEADER}" ], "env": { "RATION_AUTH_HEADER": "Bearer rtn_live_your_key_here" } } } } ``` Restart Claude Desktop. Ask: *"Call get_context on Ration and list my pantry."* ### ChatGPT desktop ChatGPT supports remote MCP with OAuth discovery for human-initiated connections. For agent-provisioned kitchens, use the same API key + Bearer header pattern as Claude. Add the MCP server URL and authorization header in ChatGPT's MCP settings after your agent completes Tier 0 registration. Human OAuth path: add `https://mcp.ration.mayutic.com/mcp` and complete browser sign-in when prompted. ### Goose [Goose](https://block.github.io/goose/docs/mcp/) supports MCP extensions with remote server configuration. After agent registration, configure a remote MCP server pointing at `https://mcp.ration.mayutic.com/mcp` with an `Authorization: Bearer rtn_live_…` header. Exact YAML shape depends on your Goose version — the transport URL and Bearer token are the portable parts. If Goose supports `mcp-remote` via command invocation, the Claude Desktop JSON block above applies unchanged. ### Zed and other OAuth-capable clients Zed, Warp, and similar clients work well with OAuth when you already have an account. For agent-first onboarding, fall back to the API key + `mcp-remote` pattern until the agent completes registration. --- ## What your agent can do before you sign up Full write access means the agent can run the complete kitchen loop without waiting for you: **Populate the pantry.** After a grocery run, the agent calls `add_cargo_item` for each item — or parses receipt text locally and runs `preview_inventory_import` → `apply_inventory_import`. Ration merges duplicates automatically. **Find cookable meals.** `match_meals` cross-references pantry against saved recipes. Strict mode returns only fully cookable meals; delta mode lists what's missing. **Plan the week.** `bulk_add_meal_plan_entries` schedules dinners; `sync_supply_from_selected_meals` rebuilds the shopping list from the plan. **Rescue expiring food.** `get_expiring_items` surfaces what needs attention; the agent can suggest meals and add missing ingredients to Supply. The compound workflow — before you ever open the app: ```text 1. Agent registers and connects MCP 2. Agent logs this week's groceries into Cargo 3. Agent matches meals and plans Tuesday dinner 4. Agent shares claim_url with you 5. You claim → everything is already there ``` While unclaimed, `get_context` returns `onboarding.claimUrl` and nudges toward claim on capacity limits. Why [structured pantry data](/blog/pantry-data-problem) matters: without it, "what can I cook tonight?" stays a guess. --- ## Claiming your kitchen When you are ready for ownership: 1. Open the **claim URL** your agent saved (or reissue one — see below) 2. Enter your email address 3. Enter the 6-digit OTP from your inbox 4. Accept Terms of Service **New email:** the stub account becomes yours with a verified email. Scopes unchanged. **Existing Ration account:** the agent's kitchen **merges** into your personal org — cargo, recipes, supply lists, meal plan entries, and ledger history move over. The agent API key is re-pointed to your account. Claim page: [ration.mayutic.com/connect/claim](https://ration.mayutic.com/connect/claim) ### Recovery if you lose the claim URL - **Have the API key?** Paste it on the claim page or call `POST /api/agent/auth/claim/reissue` with `Authorization: Bearer rtn_live_…` to get a fresh claim URL. - **Active kitchens stay claimable:** each API or MCP authentication slides the claim token expiry forward by 180 days. - **Lost both key and URL?** Contact support — there is no automated recovery without one of them. --- ## Agent-first vs OAuth-first | | Agent-first | OAuth-first | |--|-------------|-------------| | Who acts first | Autonomous agent | Human with account | | Auth method | API key from `POST /api/agent/auth` | Browser OAuth + household picker | | Best for | Try-before-claim, agent-led setup | Existing account, multi-household consent | | MCP scopes at start | Full write (`mcp:*` write set) | Scoped per OAuth grant | | Human signup required | No (until claim) | Yes | Both paths operate the same MCP tools against the same data. Pick agent-first when you want the agent to do the setup work; pick OAuth when you already know which household to connect. --- ## Limits and honesty **Pre-claim write rate limit:** 10 writes per minute per org and per key (15/min after claim). Enough for conversational use; tighter to reduce abuse on unclaimed kitchens. **Free tier capacity:** 35 pantry items, 15 recipes, 3 supply lists — same as human free accounts. Hitting limits returns `capacity_exceeded` with a claim nudge. **Orphan purge:** unclaimed kitchens with no API activity for 180 days are deleted (D1, Vectorize, R2). Claimed kitchens are never purged. **Not available via MCP:** AI credit features — receipt scanning, meal generation, weekly auto-planning — remain dashboard-only. MCP is for structured CRUD, not triggering billed AI jobs. Semantic search and meal matching work fully. --- ## FAQ **Can my agent create a Ration account without me signing up?** Yes. `POST /api/agent/auth` with `{ "type": "anonymous" }` provisions a full kitchen and returns an API key plus claim URL. No browser or email required at Tier 0. **How do I claim an agent-created kitchen?** Open the claim URL, enter your email, verify the OTP, and accept ToS at [ration.mayutic.com/connect/claim](https://ration.mayutic.com/connect/claim). **Does claiming unlock more MCP permissions?** No. Scopes are identical before and after claim. Claiming transfers ownership to a verified human — it is not a tier upgrade. **What MCP clients support agent-first onboarding?** Any client that supports remote MCP with a Bearer Authorization header: Cursor, Claude Desktop, ChatGPT desktop, Goose, and others via `mcp-remote`. OAuth-only clients can use the human path in [Your Kitchen Has an API Now](/blog/mcp-kitchen-assistant). **What happens if I never claim?** The agent keeps operating until the kitchen goes idle for 180 days, then unclaimed data is purged. Each API use resets the 180-day claim window. **Can I merge an agent kitchen into my existing account?** Yes. Complete claim with the email address already on your Ration account. Cargo, Galley, Manifest, and Supply data migrate automatically. --- ## Get started **Let your agent connect itself:** paste the [prompt above](#the-prompt-to-give-your-agent) into your MCP client. **Claim when ready:** [ration.mayutic.com/connect/claim](https://ration.mayutic.com/connect/claim) **Human OAuth path:** [ration.mayutic.com/connect](https://ration.mayutic.com/connect) **Machine-readable spec:** [ration.mayutic.com/auth.md](https://ration.mayutic.com/auth.md) Start free — no credit card required. --- # How Ration Uses Cloudflare Vectorize for Semantic Pantry Search > A technical walkthrough of Ration's semantic ingredient matching stack: embeddings, Vectorize namespaces, D1 hydration, and quantity-aware result validation. **Published:** 2026-04-26 **Updated:** 2026-04-26 **Author:** Ration **Tags:** cloudflare vectorize, semantic search, embeddings, cloudflare workers, pantry inventory, technical architecture Semantic pantry search sounds simple in a product demo. Type "tomato" and get useful matches. In production, it is harder. You need relevance, speed, and consistent behavior across meal matching, inventory deduplication, and cook deduction. If those disagree, users lose trust fast. This post covers how Ration uses Cloudflare Vectorize to make ingredient matching practical in a real pantry workflow. --- ## The problem lexical search cannot solve Kitchen data is alias-heavy: - canned tomato - tinned tomatoes - passata - tomato sauce Exact matching misses too much, and broad keyword matching returns too much. Ration still uses normalized string logic where it helps, but semantic matching is the safety net that catches close language variants users actually type. --- ## Current stack in Ration Ration runs on Cloudflare Workers and keeps pantry source data in D1. For semantic matching: - text embeddings are generated with Cloudflare Workers AI (`@cf/google/embeddinggemma-300m`) - vectors are stored in Cloudflare Vectorize - each organization is isolated by Vectorize namespace - vector hits are hydrated from D1 before final result decisions This separation is important. Vectorize gives candidate similarity. D1 remains the source of truth for item state, quantities, and domains. --- ## Write path: from pantry item to vector record When a cargo item is added or updated, Ration can embed the item name and upsert a vector record with metadata such as `name`, `domain`, and `organizationId`. Technical details from the current implementation: - embedding length is validated at 768 dimensions - batched upserts are chunked to avoid oversized requests - embedding calls are guarded so missing AI/Vectorize bindings fail gracefully instead of breaking pantry writes The goal is reliability first. Semantic indexing should improve matching, not block core inventory CRUD. --- ## Query path: ingredient phrase to matched cargo At query time, the flow is: 1. Embed ingredient query text. 2. Query Vectorize within the organization namespace. 3. Apply threshold and top-k controls. 4. Hydrate matched item ids from D1. 5. Run quantity and unit compatibility checks before saying an ingredient is covered. That last step is where many systems fail. Similar text does not imply enough quantity. Ration applies conversion logic after retrieval so matching remains semantically tolerant but numerically strict. --- ## Thresholds and consistency controls Ration keeps aligned similarity thresholds for: - ingredient to cargo resolution - cargo deduplication during ingest - cargo deduction during meal cook actions This avoids a common regression where one subsystem accepts a match and another rejects it later. It sounds like a small detail, but consistency here directly affects user trust. --- ## Performance and caching strategy Semantic retrieval can become expensive if every request re-embeds similar text. Ration uses batch embedding and cache-assisted embedding paths to reduce repeated model calls. Cache entries are keyed by normalized text and time-bounded, which keeps repeated pantry terms cheap while still allowing updates over time. Workers + D1 + Vectorize locality also helps keep latency low for common read paths. --- ## Failure modes and practical safeguards No semantic system is perfect. Common edge cases: - overly broad ingredient queries ("sauce") - brand-heavy names that map weakly to generic ingredients - stale vectors after large item renames - high-similarity false positives across adjacent products Ration mitigates these with threshold tuning, namespace isolation, D1 hydration checks, and strict post-retrieval quantity logic. The principle is simple: vectors can suggest candidates, but final decisions should still pass deterministic checks. --- ## Why this matters for user experience From the user side, all of this complexity should collapse into one feeling: "I can search naturally, and the app still gives me correct planning answers." That is the real bar. Not just semantic search quality in isolation, but whether semantic matching holds up inside pantry tracking, meal planning, and shopping list generation. If it does, users keep using the system. If it does not, they fall back to guesswork. --- ## Building this pattern yourself If you are building a similar product, a practical approach is: - keep relational truth in a transactional store - use vector search for candidate recall, not final truth - verify candidate matches with deterministic business logic - keep thresholds aligned across all workflows that share semantic matching Ration follows this pattern because it scales from demo quality to daily-use quality. --- *Written by [Codex](https://openai.com/codex/). Curated and reviewed by the Ration team.* --- # Food Waste Is a Data Pipeline Problem > Reducing household food waste is not only about discipline. It is mostly an information freshness problem across inventory, recipes, planning, and shopping. **Published:** 2026-04-26 **Updated:** 2026-04-26 **Author:** Ration **Tags:** food waste reduction, pantry inventory, meal planning, grocery optimization, expiry tracking, kitchen data Most food waste at home does not happen because people do not care. It happens because the data is stale. What is in the fridge, what expires soon, what meals are possible, and what should be on the shopping list often live in separate places. By the time you make a decision, one or more of those views is out of date. That gap is where waste grows. --- ## Why "just be more organized" does not work A lot of advice around food waste sounds reasonable: - plan your meals - check your pantry - make a list - use leftovers The problem is not understanding those steps. The problem is doing all the reconciliation work manually every week. If the overhead is too high, people skip checks and buy duplicates "just in case." Items get pushed back in a shelf and forgotten. This is a systems problem, not a motivation problem. --- ## The loop that matters A useful kitchen system needs one connected loop: 1. **Ingest inventory** from receipts, quick entry, imports, or chat 2. **Match recipes** against what is actually available 3. **Build a weekly plan** with those constraints 4. **Generate a shopping delta** from plan minus inventory 5. **Deduct cooked ingredients** so next week starts from a clean state If any one of those breaks, the loop drifts and waste goes up. Many apps only solve one or two steps. Ration is differentiated because it treats all five as one workflow. --- ## Where Ration is practically useful The value shows up in very ordinary moments: ### Before a shop You can quickly ask what is low, what is already available, and what expires soon. That lowers duplicate purchases. ### During planning Instead of choosing meals first and checking inventory later, you can match meals against current stock and see near-misses with missing ingredients. ### During cooking When meals are marked cooked, ingredients deduct from inventory. This keeps the baseline truthful for the next plan instead of relying on memory. ### During cleanup Expiring items become visible while they are still usable, not after. Each step is small. Together they remove most of the coordination tax. --- ## Technical layer behind the loop For technical readers, Ration uses a straightforward architecture: - Cloudflare Workers for edge runtime - D1 as the canonical data store for pantry, meals, planning, and supply - Vectorize for semantic ingredient similarity - unit and density-aware conversion logic for realistic quantity checks - MCP and HTTP APIs over the same domain services This matters because the loop is only useful if responses are fast enough to use while standing in the kitchen or walking in a supermarket aisle. --- ## Why this outperforms disconnected tools A notes app can hold your shopping list. A bookmarks folder can hold recipes. A spreadsheet can hold inventory. Each tool can be good at its own job. The issue is cross-tool drift: - recipe updates do not adjust your list - cooked meals do not reduce stock - pantry changes do not reshape your plan Once drift starts, trust drops. When trust drops, people stop using the system and waste climbs again. Ration is helpful because it keeps these surfaces in sync by design. --- ## A useful way to think about food waste software If you are evaluating tools, ask one question: Does this product reduce the cost of keeping kitchen data fresh? If yes, it can reduce waste. If not, it becomes one more place where stale information accumulates. Ration is built around freshness as the default: - fast ingestion - semantic ingredient matching - computed shopping deltas - cook-time deduction The result is simple. You buy less duplicate food, use more of what you already have, and waste less because decisions are based on current data. --- *Written by [Codex](https://openai.com/codex/). Curated and reviewed by the Ration team.* --- # Designing a Consumer App for AI Agents: Ration's MCP Architecture > How Ration exposes pantry, meal planning, and shopping workflows through MCP with scoped auth, tool-level safety controls, and predictable schemas. **Published:** 2026-04-26 **Updated:** 2026-04-26 **Author:** Ration **Tags:** model context protocol, mcp server, ai agent tools, cloudflare workers, API design, pantry management 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:///api/auth`). **Organization API keys** remain available for REST v1 and advanced MCP (CI, manual Bearer headers, legacy clients). Current scope model supports: - `mcp:read` - `mcp:inventory:write` - `mcp:galley:write` - `mcp:manifest:write` - `mcp:supply:write` - `mcp: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: 1. check expiring items 2. match meals in delta mode 3. add selected meals to a week plan 4. 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](https://openai.com/codex/). Curated and reviewed by the Ration team.* --- # Why Pantry Search Needs Semantics, Not Just Keywords > Keyword search breaks in real kitchens because pantry data is messy human language. Here is how semantic matching makes pantry inventory actually useful. **Published:** 2026-04-26 **Updated:** 2026-04-26 **Author:** Ration **Tags:** pantry search, semantic search, kitchen inventory, recipe matching, cloudflare vectorize, meal planning If you have ever tried to search a pantry app and got no result for something you clearly have, you already know the problem. Your inventory says "tinned tomatoes." Your recipe says "canned tomato." You search for "tomato." A strict keyword system treats those as different strings and gives you bad answers. Most pantry software fails here because it expects clean data, but kitchens produce messy data. --- ## The language problem in pantry tracking People do not log food in one standard format. You might enter: - "Basmati rice" - "Rice (long grain)" - "Tilda rice" - "2kg rice" All of these can describe almost the same thing. Then recipes make it harder again: - "Rice" - "Cooked rice" - "Jasmine rice" If search is based on exact words, your app ends up technically correct and practically useless. This is why many users stop trusting pantry tools. Not because they do not care, but because the answers feel unreliable. --- ## What users actually need from search Real pantry search is not one query type. It is a set of quick decisions: - "What can I cook right now?" - "What is expiring this week?" - "What am I one ingredient short on?" - "Do I already have this at home?" To answer those well, the system has to understand similarity, not just spelling. That is where semantic matching matters. --- ## How Ration handles this In [Ration](https://ration.mayutic.com), pantry items live in Cargo, recipes live in Galley, plans live in Manifest, and shopping deltas live in Supply. When ingredient names are compared, Ration can use vector similarity to find close matches even when words differ. Internally, this is powered by embeddings and Cloudflare Vectorize, then combined with unit-aware quantity checks before deciding whether something is actually covered. So "chopped tomatoes" can still help satisfy a "tomato" ingredient line, but only if there is enough quantity in compatible units. That last part matters. Semantic matching without quantity and units gives pretty demos and bad planning. --- ## Why this feels better in day-to-day use The user experience change is simple: You stop managing aliases manually. You do not have to remember exactly how you named something two weeks ago. You can scan a receipt, add an item by chat through MCP, or type a quick manual entry and still get useful recipe matching later. That lowers friction in three places: - **Ingestion:** fast logging does not punish inconsistent naming - **Planning:** recipe suggestions are more realistic - **Shopping:** missing-item lists are tighter, so fewer duplicate purchases This is also why semantic pantry search is not just a search feature. It is core infrastructure for the whole meal planning loop. --- ## Technical readers: what is actually happening At a high level: 1. Inventory items are stored in D1 as the source of truth. 2. Item names are embedded with a Cloudflare Workers AI embedding model. 3. Vectors are stored by organization namespace in Vectorize. 4. Ingredient queries are embedded and matched by similarity. 5. Matches are hydrated from D1 and then validated with quantity/unit conversion logic. Ration also keeps thresholds aligned across matching, deduplication, and cook-time deduction so users do not see "available to cook" and then hit "cannot deduct ingredient" later. That consistency is easy to miss in demos, but it is a big part of product trust. --- ## Why this is a useful pattern beyond kitchens Pantry management is a good test case for semantic UX because the data is noisy, local, and constantly changing. If semantic retrieval can survive that environment, it can usually survive other consumer workflows where users mix shorthand, brand terms, and inconsistent units. Ration is useful because it treats this as an engineering problem: - keep data entry cheap - keep matching tolerant - keep quantity math strict - keep the loop connected That combination is what turns inventory data into action. --- *Written by [Codex](https://openai.com/codex/). Curated and reviewed by the Ration team.* --- # Breaking the Meal Planning Loop > The weekly cycle of planning, shopping, cooking, and repeating is relentless by nature. Here's how a connected workflow reduces the overhead without adding complexity. **Published:** 2026-03-11 **Updated:** 2026-03-11 **Author:** Ration **Tags:** meal planning, meal prep, grocery list, batch cooking, shopping list, food waste There is a cycle that anyone who meal plans knows well: decide what to eat, check what you have, buy what is missing, cook the food, eat the food, repeat. Every week. Forever. It is not complicated. But it is relentless. And the difficulty is not figuring it out. Most people who meal plan already have a system that works. The difficulty is that the coordination between steps, keeping recipes, inventory, and shopping in sync, takes real mental effort every single week. Not because the person is disorganised, but because the task itself is inherently repetitive and the information lives in too many places. --- ## The coordination tax Most people piece together a workflow that looks something like this: - Recipes in a bookmarks folder, a notes app, or across a few websites - A shopping list in a separate app or on paper - Pantry knowledge mostly in memory - A rough weekly plan on a whiteboard, a calendar, or just a running conversation Each of those is fine on its own. The problem is the bridging. "I want to make stir fry. Do I have soy sauce? Probably. Do I have rice noodles? I will check later. Actually, I will just buy them to be safe." Multiply that by five or six meals a week and you end up with duplicate purchases, forgotten ingredients, and a constant low-grade overhead that makes the whole process feel heavier than it needs to be. This is not a knowledge gap. It is a systems problem. The information exists, but it is scattered, and reconciling it manually every week is the part that wears people down. --- ## What a connected workflow looks like The fix is straightforward in principle: make the recipes, the inventory, and the shopping list aware of each other. When one changes, the others update. When you plan a meal, the system already knows what you have and what you need. In practice, that means a few things need to be true: **Inventory needs to be current.** If the system does not know what is in your kitchen, nothing downstream works. This is the [data ingestion problem](/blog/pantry-data-problem), and it is worth solving first. AI image scanning, conversational input, and structured import all help reduce the cost of keeping inventory accurate. **Expiry data needs to surface automatically.** Knowing that the chicken expires Tuesday should not require opening the fridge and checking. A system that tracks expiry dates can flag items proactively, giving you time to plan around them instead of discovering them too late. **Recipe matching should work both directions.** "What can I make with what I have?" is the obvious question. But "what am I one ingredient short of?" is often more useful. Matching recipes against inventory in both strict and near-miss modes turns the weekly "what should we eat" question into a set of concrete options. **Shopping lists should be computed, not composed.** Once you have a meal plan and a current inventory, the shopping list is just the difference between what you need and what you have. Building it by hand, from memory, is where duplicates and forgotten items come from. **Cooking should close the loop.** When you cook a meal, the ingredients should deduct from inventory automatically. That way next week starts from an accurate baseline, and the cycle actually gets easier over time instead of accumulating drift. [Ration](https://ration.mayutic.com) implements this full loop. Inventory lives in one place (called Cargo). Recipes live in another (Galley). The weekly plan (Manifest) ties them together, and the shopping list (Supply) is generated from the gap. When you mark a meal as cooked, ingredients deduct. When you plan the next week, you start from a clean state. --- ## The technical layer That workflow requires a few systems running in concert behind the scenes. ### A single inventory store Everything starts with the pantry. Every item has a name, quantity, unit, domain (food, household, alcohol), and optional expiry date. Whether an item was added through [AI scanning](/blog/pantry-data-problem), manual entry, or [conversational MCP](/blog/mcp-kitchen-assistant), it writes to the same data store. Ration uses Cloudflare D1 for this. No sync layer, no secondary cache. One source of truth. ### Semantic ingredient resolution Recipes reference ingredients by name. Users log pantry items in whatever shorthand they prefer. "Tinned toms," "chopped tomatoes," and "canned tomato" all need to resolve to the same thing for recipe matching to work. Vector embeddings solve this. Each pantry item gets an embedding stored in Cloudflare Vectorize. When the recipe matcher runs, it uses semantic similarity rather than string matching. "Basmati rice" in the pantry covers "rice" in a recipe. This is the same engine that powers [ingredient search](https://ration.mayutic.com/tools/unit-converter) across the platform. ### Density-aware unit conversion A recipe calls for 2 cups of flour. The pantry has 1.2 kg. Whether that is enough depends on the flour type. All-purpose is roughly 125g per cup. Almond flour is closer to 96g. Generic volume-to-weight conversion does not cut it for cooking. Ration uses ingredient-specific density data so the comparisons are accurate. The same conversion engine is available publicly in the [unit converter](https://ration.mayutic.com/tools/unit-converter). ### Edge-native performance Ration runs on Cloudflare Workers. V8 isolates at the edge, not a centralised server. Database queries go to D1, vector searches go to Vectorize, and AI features route through Workers AI. Most interactions resolve in under 100ms regardless of location. This matters because meal planning is a quick-check activity. You pull it up standing in the kitchen or walking through a supermarket aisle. If loading the inventory takes two seconds, you will just guess instead of looking. Fast response times are what make the habit stick. ### One API surface Everything in the UI is backed by the same API that powers the [MCP integration](/blog/mcp-kitchen-assistant). Adding items, planning meals, generating shopping lists: all available through the same interface, whether you are using the dashboard, an AI assistant, or a script. --- ## Systems over discipline The weekly loop does not go away. You still plan, shop, and cook. But the coordination overhead, the part that makes meal planning feel like a second job, shrinks when the system handles the reconciliation for you. You do not need to remember what is in the pantry. It is tracked. You do not need to build a shopping list from memory. It is computed. You do not need to manually update inventory after cooking. It deducts. The loop is still there. It just stops being the hard part. --- *Written by [Opus](https://www.anthropic.com/claude). Curated and reviewed by the Ration team.* --- # The Pantry Data Problem > Most pantry trackers fail because getting data in is harder than keeping it organized. Here's how AI image processing, APIs, and structured ingestion change the equation. **Published:** 2026-03-11 **Updated:** 2026-03-11 **Author:** Ration **Tags:** pantry tracker, pantry inventory, AI scanning, kitchen inventory, food waste, receipt scanning Every pantry tracker has the same problem: you have to use it. Not "use" as in open the app and browse your inventory. That part works fine. The hard part is the other side. Getting data in. Every item you buy needs to be logged. Every item you cook needs to be deducted. Every expiry date needs to be entered. If that process takes longer than tossing the receipt in a drawer, most people stop within a week. This is the data ingestion problem, and it is the reason most kitchen inventory tools end up abandoned. --- ## Why pantry tracking fails You come home from the shop carrying six bags. Now you are supposed to open an app and type "chicken breast, 1.2 kg" twelve separate times. By the third entry, you are behind. By the fifth, you have closed the app. The issue is not motivation. It is friction. The value of knowing what is in your kitchen is obvious: fewer duplicate purchases, less food waste, better meal planning. But the cost of maintaining that knowledge by hand is too high for most people to keep up with. Spreadsheets run into the same wall. They are flexible, but they do not understand that "chopped tomatoes" and "tinned toms" are the same ingredient. They cannot flag what is expiring. They cannot compare your pantry against your recipes. The tools are not bad. The entry cost is just too high relative to the payoff on any given day. --- ## Lowering the cost of getting data in The pattern that actually works is to push the ingestion burden away from the human. Instead of typing each item, let the system infer it from sources that already exist: a receipt photo, a picture of the fridge shelf, a natural-language sentence, or a file export from wherever the data lives now. [Ration](https://ration.mayutic.com) was built around this assumption. If you solve data entry, everything downstream, [meal planning](/blog/meal-planning-loop), shopping lists, food waste reduction, becomes possible. Here is how the ingestion layer works. ### Image-based scanning The idea is simple: take a photo and let a vision model extract the structured data. The input can be a grocery receipt, a PDF of an online order, or a photo of your pantry shelves with product labels visible. Ration routes images through Cloudflare AI Gateway to Google Gemini vision models. The model interprets the image and returns structured JSON: item name, quantity, unit, and domain (food, household, or alcohol). Ration normalizes the output, deduplicates against existing inventory, and merges quantities where an item already exists. One photo replaces ten minutes of typing. This is not OCR in the traditional sense. The model understands context. It can read a crumpled Tesco receipt and a handwritten shopping note with roughly the same reliability. It can also look at a fridge shelf and identify "Kerrygold butter" and "Ballymaloe relish" from their packaging. ### Conversational input via MCP If you already use an AI assistant like Claude or Cursor, you can add items through natural language. "I bought 500g of mince, a bag of spinach, and a block of feta" becomes three inventory entries without opening an app. The [MCP integration](/blog/mcp-kitchen-assistant) covers this workflow in detail. ### Manual entry Sometimes you are adding a single item. A jar of peanut butter you grabbed on the way home. Name, quantity, unit, optional expiry date. It is fast for one or two items, and it is always available when you do not have a receipt or a photo. ### Bulk import For people migrating from spreadsheets or another system. Export as CSV, upload, and the system maps columns to its data model. Useful for the initial setup so you are not retyping an inventory you already have somewhere. --- ## What accurate inventory enables Once the pantry data is reliable, the downstream value compounds quickly. The specifics vary by tool, but the general patterns are the same regardless of platform. **Expiry awareness.** If the system knows when items were added and when they expire, it can surface what needs to be used soon. You find out about the chicken breast on Sunday, not after it has gone off on Wednesday. Ration surfaces these alerts automatically and feeds them into recipe matching. **Recipe matching.** With a known inventory, you can compare what you have against what a recipe requires. The useful output is not just "you can make this" but "you are one ingredient short of this." Ration runs this comparison across your full recipe library and shows both fully-cookable meals and near-misses with a clear list of what is missing. **Shopping list generation.** A meal plan plus a current inventory equals a precise shopping list. Instead of guessing what to buy, the system diffs what you need against what you have. Ration generates this list automatically when you set your weekly plan, so you only buy the delta. **Unit-aware comparisons.** A recipe calls for 2 cups of flour. You have 1.5 kg. Whether that is enough depends on the type of flour. Accurate conversion requires ingredient-specific density data, not a generic multiplier. Ration handles this using the same [density engine](https://ration.mayutic.com/tools/unit-converter) that powers its public unit converter. --- ## The real cost of bad data Food waste is the quiet tax on every kitchen that does not track inventory. According to the [Irish EPA (2025)](https://www.epa.ie/our-services/monitoring--assessment/waste/national-waste-statistics/food/), Irish households generated 221,000 tonnes of food waste in 2023. That works out to roughly 120 kg per household per year, costing the average family around 700 euro annually. Most of it is not spoiled beyond use. It is forgotten, pushed to the back of a shelf, hidden behind something else, or bought in duplicate because nobody checked. A pantry tracker that people actually maintain, because the data entry cost is low enough, turns some of that waste into meals. That is not a feature pitch. It is the entire reason the ingestion problem matters. --- ## Where this is heading The scan pipeline will keep improving. More receipt formats, better item recognition, and eventually barcode scanning for packaged goods. The goal is to make the gap between "I bought something" and "the system knows about it" as close to zero as possible. In the meantime, the combination of AI image processing, conversational input via [MCP](/blog/mcp-kitchen-assistant), and structured bulk import means maintaining a pantry inventory does not have to be a discipline problem. It can be a systems problem, and systems problems have engineering solutions. --- *Written by [Opus](https://www.anthropic.com/claude). Curated and reviewed by the Ration team.* --- # Your Kitchen Has an API Now > How to connect Ration to Claude, Cursor, and any MCP client — with real prompts, real outputs, and workflows that make it worth setting up. **Published:** 2026-03-10 **Updated:** 2026-03-21 **Author:** Ration **Tags:** MCP, AI assistant, pantry management, meal planning, kitchen API Most kitchen apps are designed around tapping and swiping. Ration is too — but it also speaks a language that AI assistants understand natively. Through the [Model Context Protocol](https://modelcontextprotocol.io/) (MCP), you can manage your entire pantry, meal plan, and shopping list from [Ration](https://ration.mayutic.com) inside Claude, Cursor, or any MCP-compatible client. No custom integrations. No webhooks. No glue code. This post walks through what that actually looks like in practice, and why it turns pantry management, meal planning, and shopping list workflows into something an AI assistant can actually help with. --- ## What is MCP? MCP is an open protocol that lets AI assistants call tools on external services. Think of it like giving Claude a set of buttons it can press on your behalf: - "Search the pantry" - "Add eggs to the shopping list" - "What meals can I make tonight?" Ration runs a dedicated MCP server at `mcp.ration.mayutic.com`. Once connected, your AI assistant reads and writes the same data you see in the Ration dashboard. It's not a separate system or a sync. Same pantry. Same recipes. Same meal plan. --- ## Getting connected You need a Ration account — that's it. No API key required for standard MCP clients. **Prefer agent-first onboarding?** Your autonomous agent can self-register via [`auth.md`](https://ration.mayutic.com/auth.md), configure MCP itself, and start managing a kitchen before you sign up — then you claim ownership whenever you want. See [Let Your Agent Connect Itself](/blog/agent-first-mcp-onboarding). ### OAuth (recommended) 1. In your MCP client, add server URL **`https://mcp.ration.mayutic.com/mcp`** 2. Complete browser sign-in, pick your household, and approve permissions 3. Manage or revoke access anytime in **Hub → Settings → Connected Agents** ### Claude Desktop Add the MCP URL in your Claude MCP configuration. On first connect, your browser opens for OAuth automatically. After authorization, ask Claude: *"List my Ration pantry."* ### Cursor Open MCP settings → add a **remote** server → paste `https://mcp.ration.mayutic.com/mcp`. Ration tools appear in the agent tool list after you authorize. If you want a public example of Ration's kitchen tooling before connecting MCP, the [unit converter](https://ration.mayutic.com/tools/unit-converter) shows the same measurement system the app uses internally. ### Alternative: manual API key setup If your client does not support OAuth discovery, create an API key with **`mcp:*`** scopes in **Hub → Settings → API Keys**, then configure a Bearer header: ```json { "mcpServers": { "ration": { "command": "npx", "args": [ "mcp-remote", "https://mcp.ration.mayutic.com/mcp", "--header", "Authorization:${RATION_AUTH_HEADER}" ], "env": { "RATION_AUTH_HEADER": "Bearer rtn_live_your_key_here" } } } } ``` See [Connecting to MCP](/docs/api#mcp) for full details. --- ## Browsing your pantry The simplest starting point. Claude calls `list_inventory` and returns what you have on hand. > **You:** What do I have in my pantry right now? Claude pulls your full cargo list — names, quantities, units, and domains (food, household, alcohol). You can narrow it: > **You:** What food items do I have? Skip household stuff. > **Claude:** You have 47 food items. Here are some highlights: > - Chicken breast — 1.2 kg > - Basmati rice — 2 kg > - Olive oil — 750 ml > - Eggs — 12 > - Cheddar cheese — 400 g > - Garlic — 1 head --- ## Logging a grocery haul After a shop, instead of opening the app and tapping through entries one by one, just tell Claude what you bought. > **You:** I picked up 500g of mince, a bag of spinach, 2 cans of chopped tomatoes, and a block of feta. Claude calls `add_cargo_item` for each one, picking sensible units and quantities. Ration merges quantities for existing items automatically. > **Claude:** Done. Added to your pantry: > - Beef mince — 500 g (new) > - Spinach — 1 bag (new) > - Chopped tomatoes — 2 cans (merged with existing — now 4 total) > - Feta cheese — 1 block (new) No duplicate entries. The MCP tool just passes items through and Ration resolves the rest. --- ## Finding what you can cook This is the workflow that makes the whole setup worth it. Claude calls `match_meals`, which cross-references your pantry against your saved recipes. > **You:** What meals can I make with what I have? I don't want to go to the shop. Two modes are available: - **Strict mode** — only meals where every ingredient is covered - **Delta mode** — partial matches, with a clear list of what's missing > **Claude:** > > **Fully cookable:** > - Garlic Fried Rice — all ingredients available > - Greek Salad — all ingredients available > - Simple Omelette — all ingredients available > > **Almost there (one item away):** > - Spaghetti Bolognese — missing: spaghetti (500 g) > - Spinach & Feta Pie — missing: filo pastry (1 pack) That "almost there" list is often more useful than the strict one. You know exactly what to grab if you pass a shop. --- ## Rescuing expiring food Food waste is the enemy. Claude can check what needs attention before it's too late. > **You:** Anything expiring in the next 3 days? > **Claude:** 3 items expiring soon: > - Chicken breast (1.2 kg) — expires March 12 > - Spinach (1 bag) — expires March 11 > - Greek yogurt (500 ml) — expires March 13 Then follow it up naturally: > **You:** Can I make anything with the chicken and spinach before they go off? Claude runs `match_meals` filtered against those ingredients and suggests options. Multi-step reasoning that would take several taps in any UI happens in a single conversation. --- ## Planning meals Once you've picked meals, slotting them into the calendar is a single sentence. > **You:** Put the Garlic Fried Rice on Wednesday dinner and the Greek Salad on Thursday lunch. Claude calls `add_meal_plan_entry` twice — once per slot. The meals appear in your Manifest calendar immediately. --- ## Building a shopping list Your supply list understands domains. Claude assigns them correctly. > **You:** I need pasta, tinfoil, and a bottle of red wine for the weekend. Claude calls `add_supply_item` three times: pasta as food, tinfoil as household, wine as alcohol. Each lands on your active supply list, visible to anyone you've shared it with. Later, at the shop: > **You:** I got the pasta and the wine. Claude marks both as purchased. The tinfoil stays unchecked. --- ## Editing recipes Recipes evolve. Maybe you tried a variation and want to save it. > **You:** In my Spaghetti Bolognese recipe, swap the beef mince for turkey mince and add a teaspoon of smoked paprika. Claude calls `update_meal` with the modified ingredient list. The recipe updates in your Galley instantly — same directions, same servings, just the ingredients you changed. --- ## The compound effect Any single interaction saves a few taps. The real value is in chaining them across pantry tracking, meal planning, and shopping list management. A full session might look like this: ```text 1. "What's expiring?" → chicken, spinach, yogurt 2. "What can I make?" → chicken & spinach curry 3. "Put it on Tuesday dinner" → done 4. "What am I missing?" → coconut milk and naan 5. "Add those to my list" → done ``` Five prompts. Zero app-switching. You've rescued expiring food, planned a meal, and built a shopping list. That's the compound value MCP enables — not replacing the Ration UI, but giving you another way in when conversation is faster. --- ## Current limitations ### Not available via MCP AI-powered features like receipt scanning, meal generation, weekly auto-planning, and URL recipe import run only in the Ration dashboard and use Ration's credit system. **They are intentionally not exposed through MCP** — MCP is for structured pantry, plan, supply, and recipe CRUD, not for triggering billed AI jobs remotely. ### What does work **Semantic search** (`search_ingredients`) is fully available. It uses the same vector embeddings as the dashboard — search for "tomato" and you'll find "chopped tomatoes," "cherry tomatoes," and "tomato passata." **Meal plan edits** — Remove or reschedule entries (`remove_meal_plan_entry`, `update_meal_plan_entry`) using ids from `get_meal_plan`. **Supply list from selections** — `sync_supply_from_selected_meals` runs the same rebuild as Supply → Update list (current week's plan plus Galley selections). It may use Vectorize to match ingredient names to cargo; it does **not** spend AI credits. **New recipes** — `create_meal` adds a Galley recipe from structured data. For large imports, use the REST API (`galley` scope) instead of hundreds of tool calls. ### Rate limits Reads are capped at 30 per minute. Writes at 15 per minute. That's plenty for conversational use. The limits exist to prevent runaway automation from draining resources, not to restrict normal workflows. --- ## Who is this for? Anyone who already uses Claude or Cursor and wants faster pantry tracking, meal planning, and shopping list management. The setup takes two minutes — paste one URL, authorize in your browser, and your kitchen becomes part of your existing AI workflow instead of a separate app you have to remember to open. It's especially useful if you: - **Meal prep on Sundays** — plan multiple meals and build a shopping list in one conversation - **Track what's in the freezer** — ask Claude instead of digging through drawers - **Share a shopping list with a partner** — items you add through Claude appear on their phone instantly - **Batch-log groceries** — rattle off ten items in one message instead of tapping through a form --- *Written by [Opus](https://www.anthropic.com/claude). Curated and reviewed by the Ration team.* ---