Strega Recipes

Update a saved shopping list

update_shopping_list

Change a saved list after the cook answers what build_shopping_list or plan_meals set aside as likely_have, or says how the trip went. remove: things they have (they come off, and count as left off); need: set-aside things they're out of (they move to the buy aisles); add: anything else for the trip, as they said it; outcomes: what happened at the store per item (bought, skipped, bought_elsewhere with the store they name). Use when the cook says "I have the flour and oil", "I'm out of chili flakes" or "skipped the salmon, got the bread at the bakery". Changes only this list, never the pantry: ask "Want me to remember these for next time?" first, then call pantry. Returns the pared list, its estimate and the order offer.

Input Schema

Name	Required	Description
`add`	No	Anything else for the same trip, amount included: ["paper towels", "2 lb bananas"]
`need`	No	Set-aside (likely_have) things the cook is out of: they go back to the buy list at full size
`remove`	No	Things the cook has, as they said them: ["flour", "olive oil"]
`list_id`	Yes	Id of the saved list from build_shopping_list or plan_meals
`outcomes`	No	How the trip went, per line (#63): what they bought, skipped, or got somewhere else

Output Schema

Name	Required	Description
`id`	Yes	The saved list's id
`url`	Yes	Shareable list page
`asks`	No	At most one question for the cook, with a home in preferences
`text`	Yes	The list as plain text, for a message
`added`	Yes	Names added to the list
`guide`	No	How to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
`units`	Yes
`aisles`	Yes
`needed`	Yes	Names that moved from likely_have to the buy aisles
`pantry`	Yes	What the cook already has, left off the buy list (count in left_off): check the pantry, don't buy
`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)
`recipes`	Yes
`removed`	Yes	Names that came off the list: what the cook has
`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
`left_off`	No	How many lines were left off because the cook has them: "left off 6 you have"
`not_found`	Yes	Names that matched nothing on the list: say so, and check the spelling against the list
`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
`likely_have`	No	Staples and small amounts of bulk items (3 tbsp flour, 4 tbsp wine) the cook probably has: set aside instead of a full-size purchase, not counted in the cost. Ask which they do need (they move to the aisles) and which they have (they come off) with update_shopping_list; absent on lists saved before this
`forgot_asked`	No	The id of the item "Did you forget?" already asked about on this list (#63): asked once per list
`outcomes_set`	Yes	Outcomes recorded this call (#63): what the cook said happened to each line
`cost_estimate`	Yes	What the list now costs at the store in whole packages, an estimate

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare mutating-but-non-destructive and non-idempotent; the description adds the state model beyond that – remove counts as "left off", need moves items "to the buy aisles", and it states the list-vs-pantry boundary plus the confirmation step. It does not set expectations about re-running the same call (non-idempotency) or partial failure semantics.

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 purpose then per-parameter behavior, but the sentence structure is dense with parentheticals and the closing "Returns the pared list, its estimate and the order offer" duplicates 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?

Covers all five parameters, the sibling boundary, the pantry hand-off, and the example utterances an agent needs to map free-form cook speech onto the four arrays; return values are already specified by the output schema.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantic mapping the schema doesn't: what the items must look like ("as they said it") and what each operation does to list state (removed items counted as left off, set-aside items returned at full size). It goes beyond restating field names.

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?

"Change a saved list" names a specific verb and resource, and the opening clause ties it to the two siblings that produce the list (build_shopping_list, plan_meals). An agent can tell this is the mutation tool for an existing list rather than the creation tool.

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 conditions with quoted cook utterances ("I have the flour and oil", "I'm out of chili flakes", "skipped the salmon...") and explicitly routes pantry-remembering elsewhere: "Changes only this list, never the pantry: ask ... first, then call pantry."

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?