Strega Recipes

Delete the cook's own recipe for good

delete_recipe

DestructiveIdempotent

Delete a recipe the cook owns, for good, when nobody else has touched it (no versions, reviews or saves by other cooks). Use when the cook says "delete that test recipe", "get rid of it". Without confirm it only reports what would go and whether it can; name the recipe, get a yes, then call with confirm: true. A recipe others have cooked or saved can't be deleted: the answer points at update_recipe({ unpublished: true }), which takes it off Strega for everyone but the cook and can be undone.

Input Schema

Name	Required	Description	Default
`slug`	Yes	The cook's own recipe
`confirm`	No	true only after the cook said yes to deleting this recipe by name

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)
`title`	Yes
`in_use`	Yes	By other cooks; any of them means unpublish instead
`deleted`	Yes	true only after confirm: true and the delete went through
`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
`can_delete`	Yes	Nobody else has made a version of it, reviewed it or saved it
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing the two-phase protocol: without confirm it is a dry run that reports what would go and whether deletion is possible; the caller must get a named yes first. It also explains the eligibility rule (no versions, reviews or saves by others) and that the alternative path is reversible where this one is not.

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 action and precondition, then the confirm protocol, then the fallback — a sensible escalation order. It is dense but nearly every clause carries decision-relevant information; the quoted user phrasings are useful but cost some length.

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 destructive two-parameter tool with annotations and an output schema, everything an agent needs to act correctly is present: eligibility precondition, the confirm round-trip, what the non-confirmed call returns, and the exact alternative when deletion is refused.

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 baseline is 3, but the description adds real meaning: confirm: true is gated on a spoken yes to the recipe by name, and the unflagged call is a non-destructive preview. The slug parameter is framed by its ownership constraint and its failure mode (the answer redirects to update_recipe).

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?

States a specific verb and resource ("Delete a recipe") plus the ownership precondition ("the cook owns") and the hard eligibility gate ("nobody else has touched it"). It also names the sibling it is confused with by pointing to update_recipe as the fallback, so an agent can distinguish it without opening 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 explicit trigger phrases ("delete that test recipe", "get rid of it"), an explicit when-not path ("A recipe others have cooked or saved can't be deleted"), and names the alternative tool with the exact parameters to use instead (update_recipe({ unpublished: true })). Nothing is left to inference.

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?