Skip to main content
Glama

Strega Recipes

Cook step by step

get_cook_steps
Read-only

A recipe as hands-free steps for cooking along: a gather list, then one step at a time with its amounts, the ingredients it uses, its tip and any timer. Use when the cook says "walk me through it", "I'm cooking it now", "what's next?" (pass step for just that one, or from_step to pick up where they left off). Give one step per reply and offer the step's timer. The recipe url shows the same steps as a checklist on their phone. Works signed out.

Input Schema

NameRequiredDescriptionDefault
slugYes
stepNoJust this step (1-based), for "what's next?" in a voice flow; the gather list comes only with step 1 or no step
unitsNoUS cups/oz/°F or metric grams/ml/°C. Defaults to the cook's setting.
servingsNo
allergensNoExplicit per-request allergen screening, separate from exclude_ingredients. Use at most nine entries: milk, eggs, fish, shellfish, tree_nuts, peanuts, wheat, soy, sesame. Fixed aliases: dairy → milk, egg → eggs, peanut → peanuts, tree nuts → tree_nuts, soya → soy, sesame seeds → sesame. Nuts and seafood are ambiguous: specify tree_nuts/peanuts or fish/shellfish explicitly. Gluten is not wheat and lactose is not milk; neither is supported here. No spelling guesses are made. Retry with supported categories. Empty adds no restriction and never clears saved rules. Not saved to Strega preferences or plans.
from_stepNoThis step and the rest, e.g. after a pause
units_forNoThe cook's own unit for particular ingredients, by ingredient key or name: { "butter": "tbsp", "flour": "g" }. Units: tsp, tbsp, cup, fl oz, ml, oz, lb, g. When the cook asks for an amount in another unit, pass this rather than converting yourself; the ingredient list and every step follow. Ones that can't convert come back in ignored_units
unknown_ingredientsNoWhile allergen screening is active: exclude (default) omits insufficiently classified recipes; flag includes them with uncertainty. Named recipe retrieval always warns and returns the recipe.

Output Schema

NameRequiredDescriptionDefault
urlYesThe recipe page: share it so the cook can follow along (steps check off, timers included)
asksNoAt most one question for the cook, with a home in preferences
slugYesThe recipe's slug: the id every tool takes
timeYesHow long it takes (#54)
guideYesHow to pace the cook: gather list and step 1 only, then one step per reply (plus any rule for this turn)
stepsYes
titleYes
unitsYes
gatherYesEvery ingredient line, scaled: read first (empty when the call started at a later step)
noticesNoAt most one note about Strega to pass on when there's room (one per cook per week; off with workflow whats_new: off)
warningNoPresent when the recipe hits the cook's allergies, diet or avoid list: say this before anything else
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
servingsYes
warningsNoEach conflict with the cook's preferences, as a label
screeningNo
units_forNoThe units_for entries that applied: ingredient key → unit (#95)
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
total_stepsYesHow many steps the recipe has; steps holds all of them, one (step) or the rest (from_step)
ignored_unitsNounits_for entries that didn't apply (no such ingredient, unknown unit, or one it can't be shown in), each with why
usual_servingsNoThe cook's household size, offered (not applied): ask before scaling
cook_session_idNoUse this session id with rate_recipe when explicitly marking this cook made-it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint=false, and the description adds genuinely new operational context: "Works signed out" (auth requirement), the delivery convention of one step per reply, and the instruction to offer the step's timer. It does not contradict the annotations, though it says nothing about paging limits or what happens past step 60.

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 concept, then usage triggers, then delivery instruction. Dense but nearly every clause carries information; the parenthetical parameter routing and the checklist-on-phone note both earn their place.

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?

An output schema exists so return values needn't be explained, and the description covers the remaining gaps for an 8-parameter tool: auth state, per-reply delivery, and step-vs-range semantics. It leaves units/servings/allergens entirely to the schema, which is acceptable given 75% coverage, but the interaction between servings and step amounts is never addressed.

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 schema coverage at 75% the schema carries most parameter documentation, but the description still adds routing meaning: step returns just that one step while from_step returns that step and the rest. That is framed in terms of user intent rather than field types, which is real added value over the schema text.

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?

It states a specific verb (get) and resource (cook steps) and defines the exact return shape: a gather list followed by one step at a time with amounts, ingredients, tip and timer. That is distinctive against the sibling set, which contains get_recipe (full recipe) and search_recipes, because it makes clear this is a cooking-along feed rather than a document fetch.

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 literal user triggers ("walk me through it", "I'm cooking it now", "what's next?") and routes between the step and from_step parameters by user situation (single step vs. resume after a pause). What it lacks is an explicit exclusion naming get_recipe as the choice when the user wants the full recipe at once rather than walking through it.

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