Strega Recipes

Change a saved meal plan

update_meal_plan

Change the cook's saved meal plan in place: swap a day for another pick (constraints: faster, max_minutes, tags, query, or a slug the cook chose), drop a day, or add one, keeping their other days. Use when the cook says "swap Tuesday for something faster", "not the salmon", "we're out Thursday", "add one more dinner". Pass plan_id from plan_meals. Returns the whole plan by day, what changed, and the same list (same id and link), prep order, swaps, nutrition, cost and say, all recomputed. A dinner swapped out counts against it in later plans. Say what changed and the list line, then ask the one question in next_steps.

Input Schema

Name	Required	Description
`add`	No	Meals to add: [{}] for one more dinner
`drop`	No	Days to take out of the plan: ["Thu"]
`swap`	No	Days to change: [{ day: "Tue", constraints: { faster: true } }]
`units`	No	US cups/oz/°F or metric grams/ml/°C. Defaults to the cook's setting.
`pantry`	No
`plan_id`	Yes	plan_id from plan_meals
`with_shopping_list`	No	Rebuild the plan's list in place (the default)

Output Schema

Name	Required	Description
`say`	Yes	One 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
`asks`	No	At most one question for the cook, with a home in preferences
`cost`	Yes	What 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
`list`	No	The 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")
`plan`	Yes	The whole plan after the change, by day: the cook's other days as they were
`guide`	No	How to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
`changed`	Yes	What this call changed, one line per day: say these, then the new list line
`notices`	No	At most one note about Strega to pass on when there's room (one per cook per week; off with workflow whats_new: off)
`plan_id`	Yes	The same plan: it was changed in place, never replaced
`relaxed`	No	The time limit was too tight, so the plan used the nearest one that fits: tell the cook
`adjusted`	No	Defaults 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
`nutrition`	Yes	The plan's nutrition per serving (#244), an estimate
`next_steps`	No	Suggestions, 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_order`	Yes	What to cook first and why, from perishables, tags and servings. A suggestion the cook can ignore
`substitutions`	Yes	Swaps 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)

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations, it discloses that changes are in place, other days are preserved, a swapped-out dinner counts against later plans, and the whole plan is recomputed. The annotations already mark it as non-readonly and non-destructive, so this additional context is meaningful.

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?

The description is dense and front-loads the core operation and when to use it. It includes return-value and follow-up guidance that is useful but slightly more than strictly necessary given the output schema.

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

Completeness5/5

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

For a complex mutation tool with seven parameters, the description covers operations, constraints, plan_id sourcing, behavioral side effects, return contents at a high level, and follow-up. The input and output schemas carry the detailed field and return structure.

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

Parameters3/5

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

Schema description coverage is high at 86%, so the schema already documents most parameters. The description reinforces constraint semantics like faster, max_minutes, tags, query, and slug, but it does not add much for units, pantry, or with_shopping_list beyond the schema.

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?

The description states a specific verb and resource: change the cook's saved meal plan in place, with swap/drop/add operations. It also distinguishes this from creating a plan by requiring plan_id from plan_meals and by emphasizing that other days are kept.

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

Usage Guidelines4/5

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

It gives explicit usage contexts with natural-language examples such as "swap Tuesday for something faster" and "we're out Thursday." It does not name a clear alternative for creating a new plan, but the in-place scope is clear enough to select this tool correctly.

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

All Strega Recipes tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?