Skip to main content
Glama

Strega Recipes

Build a merged shopping list

build_shopping_list
Idempotent

Merge recipes (each at its own servings) and anything else into one shopping list by aisle, in what a store sells (10 cloves garlic → 1 head). Use for "make me a list", "what do I need to buy?" or "add paper towels and 2 lb bananas" (extra_items keep the cook's amounts). What the cook has stays off (left_off); staples and small amounts of bulk items (3 tbsp flour) come back as likely_have, not bought: ask which they have or are out of, then update_shopping_list. Items that hit their allergies are flagged privately for this cook; warnings are not saved in the shareable list. Signed in, the list is saved and returns a shareable url and an id for order_groceries; signed out it comes back unsaved (keep: true asks them to sign in).

Input Schema

NameRequiredDescriptionDefault
keepNoOlder spelling of save: true = save, false = preview. Still works; prefer save
saveNo"preview": show the list 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
unitsNoUS cups/oz/°F or metric grams/ml/°C. Defaults to the cook's setting.
pantryNoIngredients the cook already has, e.g. ["flour", "eggs"]
recipesYes
extra_itemsNoAnything else for the same trip, as the cook said it, amount included: ["paper towels", "2 lb bananas"]. A matching recipe ingredient gets that quantity added when the units agree, or both amounts when they don't.
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 list, even if arguments changed. New arguments need a new key; edits use update_*. Without a key Strega fingerprints arguments and applied preferences/pantry
include_staplesNoPut salt, oil, sugar, etc. on the list instead of the pantry check

Output Schema

NameRequiredDescriptionDefault
idNoThe saved list's id, for order_groceries and update_shopping_list (only when saved)
urlNoShareable list page (only when saved)
asksNoAt most one question for the cook, with a home in preferences
textYesThe list as plain text, for a message
guideNoHow to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
savedYestrue: the list is in the cook's kitchen (id and url set); false: a preview, or the cook is signed out: nothing was kept
unitsYes
aislesYes
pantryYesWhat the cook already has, left off the buy list (count in left_off): check the pantry, don't buy
noticesNoAt most one note about Strega to pass on when there's room (one per cook per week; off with workflow whats_new: off)
receiptYesWhether this call kept anything, and what (#307)
recipesYes
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
left_offNoHow many lines were left off because the cook has them: "left off 6 you have"
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
likely_haveNoStaples 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_askedNoThe id of the item "Did you forget?" already asked about on this list (#63): asked once per list
cost_estimateYesWhat the list costs at the store in whole packages (#245), an estimate

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description explains that prepared lists are saved for signed-in cooks, return a shareable URL and id, and come back unsaved for signed-out cooks unless keep=true triggers sign-in. It also discloses that allergy warnings are private and not saved in the shareable list, which is valuable behavioral context not captured by the annotations.

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 information-dense and front-loads the core purpose before usage examples and behavioral details. It is somewhat packed with semicolon-separated caveats, but nearly every clause adds operational value for this relatively complex tool.

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?

Given the tool's complexity, eight parameters, annotations, and an output schema, the description is complete enough for correct invocation. It covers the main behaviors an agent must know: list merging, pantry handling, allergy warnings, save versus preview semantics, and routing to related tools.

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 already high at 88%, so the schema carries most parameter semantics. The description adds useful meaning for extra_items quantities, pantry handling, likely_have behavior, and the signed-in versus signed-out effect of save/keep, though some parameters such as units and request_key are left to 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: merge recipes and extra items into one aisle-organized shopping list with store-unit normalization. It clearly distinguishes this from related tools by mentioning update_shopping_list and order_groceries, so an agent can identify its role without opening the 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?

It gives explicit triggering phrases such as "make me a list" and "what do I need to buy?", plus an example of adding non-recipe items. It also routes follow-up pantry decisions to update_shopping_list and saved lists to order_groceries, covering when and how to use this tool versus alternatives.

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