Skip to main content
Glama

Strega Recipes

Publish a new recipe

create_recipe

Publish a recipe to Strega. Use with draft_id from draft_recipe once the cook has seen and confirmed the draft, passing only the fields they changed; never publish pasted text straight from fields. Pass fields without a draft only for a recipe you worked out with the cook in this conversation, after showing it to them. Steps use ingredient tags, never typed amounts: "Whisk {flour} with {salt}". Recipes are public and appear under My recipes unless visibility is "private" (just for the cook); an exact copy of one the cook already has is refused (use update_recipe). tested marks it cooked and timed only when the cook says they made it; ask, never assume. Returns the url and any warnings.

Input Schema

NameRequiredDescriptionDefault
tagsNo
stepsNo
titleNo
authorNoName to credit (the cook)
testedNoMark 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.
seasonsNoExplicit recipe labels only: spring, summer, fall, winter. [] means unknown. Do not infer from ingredients, dates, location or weather.
summaryNoOne or two sentences on what makes it good
draft_idNoA draft_id from draft_recipe, to publish that draft
servingsNo
chef_noteNoThe 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.
visibilityNoprivate = just for the cook, from the first save (#171); public (the default) lists it under My recipes and in search
ingredientsNo
yield_labelNoservings, cookies, loaves, jars…
cook_minutesNo
prep_minutesNo

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
guideNoHow to answer this turn: rules for you, the assistant, not words for the cook. Follow them before anything else here (#258)
testedYes
noticesNoAt most one note about Strega to pass on when there's room (one per cook per week; off with workflow whats_new: off)
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
warningsYese.g. an ingredient never used in a step
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
visibilityYesprivate = just for the cook (#171)
completenessYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations flag a non-readOnly, open-world, non-idempotent write; the description adds the consequences: publication is public by default and appears under My recipes unless visibility is 'private', duplicates are refused, and the call returns a url plus warnings. That is meaningful context the annotations cannot express.

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?

Single dense paragraph with the core rule (draft_id, confirmed draft) front-loaded and each remaining sentence carrying a distinct constraint. It is tight but runs long as a wall of clauses, which slightly hurts scannability for a 15-parameter tool.

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?

Covers the mutation workflow, duplicate behavior, visibility consequences, tested semantics and return value, and the output schema handles the response shape. It never states the minimum viable payload (at least one ingredient and one step), which is the main gap for a create tool with zero required parameters.

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?

At 53% schema coverage across 15 params, the description adds real semantics for the hardest fields: steps must use {tag} syntax rather than typed amounts, tested reflects only a cook-confirmed timed cook, visibility defaults to public. It stays silent on tags, servings, prep_minutes and cook_minutes, so it does not fully close the coverage gap.

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 ('Publish a recipe to Strega') and immediately scopes it against siblings: draft_id comes from draft_recipe, and an exact duplicate is refused with a pointer to update_recipe. An agent can distinguish this from draft_recipe, save_recipe, fork_recipe and update_recipe without opening any 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 explicit branch conditions: use draft_id after the cook confirms the draft and pass only changed fields; use bare fields only for a recipe worked out in-conversation after showing it; use update_recipe for a duplicate. It also states when to set tested and that the agent must ask rather than assume, which is a real when-to-use boundary.

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