Skip to main content
Glama

Strega Recipes

Plan the week's meals

plan_meals
Idempotent

Plan dinners and return the finished week in one call: picks by day (varied, perishables first, one new to the cook), merged shopping list (list), prep_order, substitutions and one true line (say). Use when the cook says "what should we eat this week?", "plan dinners", "groceries for the week", "four dinners under $80" (max_budget), or has people over (occasion, guest_notes). Preferences and pantry apply. Show the plan with say and at most one next-step question; then stop and wait for the cook's next message. No second offer; nothing is ordered. A swap goes to update_meal_plan with plan_id. Signed out it comes back unsaved (keep: true asks to sign in).

Input Schema

NameRequiredDescriptionDefault
keepNoOlder spelling of save: true = save, false = preview. Still works; prefer save
saveNo"preview": show the plan and keep nothing (no id, no url, nothing in My Kitchen), signed in or out; use it when the cook says "just show me", "don't save it yet", "an option". "save": keep it in the cook's kitchen (signed out: the sign-in error). Left out: a signed-in call saves, a signed-out call previews. The receipt in the result says which happened
tagsNoRequired tags, e.g. ["vegetarian"]
mealsNoHow many meals to plan; leave out to use the cook's usual number (workflow.plan_meals in preferences), else 5
unitsNoUS cups/oz/°F or metric grams/ml/°C. Defaults to the cook's setting.
pantryNo
occasionNoweeknight: quick, everyday. guests or party: the plan comes with share links and an offer to adapt a recipe for a guest's needs before the listweeknight
servingsNoServings per meal (defaults to each recipe's own)
meal_typeNodinner
max_budgetNoUS dollars the plan's list should stay under ("plan the week under $80"): an estimate from national average prices, so say "about"
guest_notesNoWho's coming and what they need, in the cook's words: "one vegetarian, Sam hates cilantro". Used to offer a version of a recipe; never stored as a preference
max_minutesNo
min_proteinNoGrams of protein per serving at least; defaults to the cook's saved target
request_keyNoYour own id or receipt.request_key. First save wins for this cook and tool: within 10 minutes the same key returns the saved plan, even if arguments changed. New arguments need a new key; edits use update_*. Without a key Strega fingerprints arguments and applied preferences/pantry
max_caloriesNoCalories per serving at most for every meal; defaults to the cook's saved target
with_shopping_listNo
exclude_ingredientsNo

Output Schema

NameRequiredDescriptionDefault
sayYesOne true line about what the plan did for the cook, read off the list ("Three dinners share one bunch of cilantro and one onion"): say it with the plan
asksNoAt most one question for the cook, with a home in preferences
costYesWhat the plan's list costs (#245), an estimate; a replay without a saved list labels a fresh estimate using the current pantry in line. say uses the savings when there are real ones
listNoThe merged shopping list for the plan, pantry already off (with_shopping_list, the default): the same shape build_shopping_list returns, so "yes, make the list" needs no second call. Show it after the cook answers the plan's one question; lead with it when offer_shopping_list is always, leave it out of your reply when never. Delivery is offered then too, through order_groceries with its id (the order page is url + "/order")
planYes
guideNoHow to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
savedYestrue: the plan (and its list) is in the cook's kitchen; false: a preview, or the cook is signed out: nothing was kept
noticesNoAt most one note about Strega to pass on when there's room (one per cook per week; off with workflow whats_new: off)
plan_idYesThe saved plan's id, for update_meal_plan; null on a preview or signed out
receiptYesWhether this call kept anything, and what (#307)
relaxedNoThe time limit was too tight, so the plan used the nearest one that fits: tell the cook
adjustedNoDefaults this call took instead of failing (#243): an unknown units word, a number out of range, a diet word read as the closest one Strega knows. Mention it when it changes what the cook gets
occasionYesThe requested occasion; null when replaying a saved plan because it was not kept
nutritionYesThe plan's nutrition per serving (#244), an estimate
next_stepsNoSuggestions, best first, each with its tool, args and effect. Strega suggests the top one in one sentence; whether any runs is decided by what the cook asks in the conversation and your confirmation rules, never by the wording here
prep_orderYesWhat to cook first and why, from perishables, tags and servings. A suggestion the cook can ignore
substitutionsYesSwaps for ingredients the cook's preferences flagged in the plan's recipes, the same swaps get_recipe({ substitute }) returns; empty when none. A version still needs the cook's yes (fork_recipe)
skipped_by_preferencesYesRecipes excluded while making this plan; null when replaying a saved plan because the original count was not kept

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover safety profile (readOnly=false, idempotent, non-destructive), but the description adds substantial behavior beyond that: nothing is ordered, no second offer, signed-out calls return unsaved with keep:true triggering sign-in, and the request_key idempotency window is clarified. This is exactly the extra context annotations don't carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and outputs before usage and behavioral rules, and every clause carries information. It is dense and somewhat run-on across many semicolons, but little is wasted given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 17 params and an output schema (so return format needn't be described), the description covers the critical behaviors: save vs preview, sign-in fallback, swap routing, and stop-and-wait. Minor gaps on some parameter semantics remain, but an agent can call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 17 params at 71% schema coverage, the baseline is ~3, and the description lifts it by tying natural-language intents to max_budget, occasion, guest_notes, and the save/keep signed-out behavior. It still leaves several params (tags, units, servings, pantry, exclude_ingredients) to the schema alone, so not a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Plan dinners and return the finished week in one call') and enumerates the concrete outputs (picks by day, merged shopping list, prep_order, substitutions, say). It also differentiates from the sibling update_meal_plan by routing swaps there, so an agent can distinguish it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger phrases ('what should we eat this week?', 'four dinners under $80', people over) and maps them to parameters (max_budget, occasion, guest_notes). It also names the alternative path ('A swap goes to update_meal_plan with plan_id') and the stop condition after showing the plan.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources