Strega Recipes

Change the cook's own recipe or version

update_recipe

Change the cook's own recipe or version. Use when the cook says "add more garlic to my version", "make mine private", "take it down" (unpublished: true; off Strega for everyone but them, reversible; a recipe others have cooked or saved can only come down this way), "use my photo for the cover", "undo that last change", or "I made it tonight, took about 50 minutes" (tested; ask for the time if they didn't say, never assume). Pass only what changes; ingredients or steps, if passed, are the complete new list. photo: only one the cook took, never generated, stock or found; even when asked, name the recipe and get a yes first. Before calling, show the cook the changed ingredients and steps and get a yes; never save silently. Every edit keeps a revision (restore_revision: n undoes edit n). Not the cook's? Use fork_recipe. recover_photo is recovery-only: discover with get_my_kitchen section pending_photos, show the selected photo, target and current-cover replacement consequence, then wait for explicit selection and confirmation. cook_confirmed is the model's assertion, not independent proof of consent; never auto-confirm. Copy the full observed version unchanged and combine recovery with no other edits.

Input Schema

Name	Required	Description
`slug`	Yes	The cook's recipe or version to change
`tags`	No
`photo`	No	A photo the cook took of this dish: the cover, or a step with step. Pass image_url or image_base64. Never a generated, stock or found-online picture. Asking for it isn't the yes: first tell the cook which recipe and where ("I'll set this photo as the cover of <title>. OK?") and call only after they say yes. It goes through Strega's photo check (a cover needs daylight and at least 1200 px on the long side); a refusal says what to fix and nothing changes. It replaces the current cover, a placeholder illustration included. If you can't pass the file, the cook can use "Add a photo" on the recipe page. Change publication status (unpublished) in a separate call, never together with a photo.
`steps`	No
`title`	No
`author`	No	Name to credit (the cook)
`tested`	No	Mark the recipe tested: the cook says they cooked it themselves and timed it. Ask the cook ("Have you cooked this? About how long did it take, start to finish?") and pass only what they say; never assume it, never estimate the minutes, and never mark a recipe tested because you drafted, imported or adapted it. null clears the mark. Shown as "Tested by the cook · 45 min" and counted as one timed cook.
`seasons`	No	Explicit recipe labels only: spring, summer, fall, winter. [] means unknown. Do not infer from ingredients, dates, location or weather.
`summary`	No	One or two sentences on what makes it good
`servings`	No
`chef_note`	No	The chef's note, up to 500 characters: a sentence or two in the cook's words on what makes the recipe theirs. Only what the cook said; never write one for them.
`visibility`	No
`ingredients`	No
`show_counts`	No	Whether the page shows "cooked N times · shared N times" once there are enough cooks (#46); default on. false hides them
`unpublished`	No	true takes the recipe off Strega for everyone but the cook (the link stays theirs, nothing is lost, their lists and plans still open it); false puts it back. Not an edit: no revision. Confirm first, like any change
`yield_label`	No	servings, cookies, loaves, jars…
`cook_minutes`	No
`prep_minutes`	No
`recover_photo`	No	Recover an uploaded cover without another intake. Use only with slug; no other edits, uploads, restoration or publication. First discover with get_my_kitchen section pending_photos, show the selected preview, target and replacement consequence, and wait for the cook's explicit confirmation.
`attached_photo`	No	A JPG, PNG or WebP photo the cook attached in the chat, for the cover (or a step with photo.step). Convert HEIC/HEIF to one of those formats first. Change publication status (unpublished) in a separate call, never together with a photo. ChatGPT fills in this file object when the cook attaches a picture; don't type a link here (a link goes in photo.image_url). The same rules as photo: only a photo the cook took of this dish; name the recipe and where it goes and get the cook's yes first; it goes through the photo check and replaces the current cover.
`restore_revision`	No	Undo: put the recipe back to how it was before edit n (see get_recipe's revisions). Other fields you pass apply on top.

Output Schema

Name	Required	Description
`url`	Yes	The recipe page: share it so the cook can follow along (steps check off, timers included)
`asks`	No	At most one question for the cook, with a home in preferences
`slug`	Yes	The recipe's slug: the id every tool takes
`guide`	No	How to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
`photo`	No	Only when photo or attached_photo was passed
`tested`	Yes
`changes`	Yes	What changed, in plain words
`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)
`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
`restored`	Yes	The revision that was restored, when restore_revision was passed
`revision`	Yes	The edit count after this change; update_recipe({ restore_revision: revision }) undoes it
`warnings`	Yes
`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
`visibility`	Yes	private = just for the cook (out of search, the sitemap and the original's list of variations)
`show_counts`	Yes	Whether the page shows public cook and share counts (#46)
`unpublished`	Yes	Off Strega for everyone but the cook (#171); update_recipe({ unpublished: false }) puts it back
`recovered_photo`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare the generic write profile (readOnly=false, destructive=false, idempotent=false), but the description adds the real behavioral facts: unpublishing is reversible and only affects other people's access, every edit creates a revision that restore_revision can undo, photos pass a photo check that may refuse and leave nothing changed, and cook_confirmed is an assertion rather than proof of consent. The "never save silently" and "never auto-confirm" directives are exactly the kind of context annotations cannot 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 purpose, then routing, then modes, then guardrails — good ordering with no filler sentences. However it is delivered as a single dense paragraph with nested quoted examples, which makes the several distinct workflows (edit, unpublish, photo, tested, restore, recover) harder to scan than a short bulleted structure would be.

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 21-parameter, nested-object mutation tool with an output schema, the description covers every high-risk path: partial updates, publication changes, photo intake and recovery, revision restore, and mandatory confirmation. Since an output schema exists, the absence of return-value description is appropriate rather than a gap.

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

Parameters5/5

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

Schema coverage is 62%, and the description fills the most consequential gap: "Pass only what changes; ingredients or steps, if passed, are the complete new list" — patch-vs-replace semantics not conveyed by the schema. It also constrains photo (only cook's own, one photo per call, separate call from unpublished), tested (ask, never estimate), and restore_revision (n undoes edit n).

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?

Opens with a specific verb+resource ("Change the cook's own recipe or version") and immediately scopes ownership. It explicitly names the sibling it is not — "If the cook is not the owner, use fork_remote/change... 'Change the cook's own recipe or version'... 'Change the cook's own... whatever' — and explicitly routes non-owners to fork_recipe, so an agent can pick between them without reading either 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 concrete triggering utterances for each mode ("make mine private", "take it down", "use my photo for the cover", "undo that last change", "I made it tonight, took about 50 minutes") plus explicit exclusions. It states prerequisites before calling (show the changed ingredients and steps and get a yes) and names alternatives (fork_recipe for non-owners, get_my_kitchen pending_photos + recover_photo for recovery).

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?