Your AI Kitchen (YAK)

Edit a recipe or draft

update_recipe

Destructive

Change any field of a recipe or draft the user owns or may edit. Only fields you pass change; lists you pass replace the old ones. Every edit is saved as a new revision (undo with restore_revision). To resize permanently, pass scale_to_servings or scale_factor; for a one-off view use get_recipe. Filing fields are owner-only. Blocked on read-only accounts. Returns the updated recipe.

Input Schema

Name	Required	Description
`id`	Yes	Recipe id (UUID) from search_recipes or an earlier result
`diet`	No	Diet labels only as the user stated them, e.g. ["Vegetarian"]
`tags`	No	0-3 free-form tags
`steps`	No	Strings or {text, timer_minutes, temp_f}; replaces the whole list
`title`	No	Dish name, max 200 chars, e.g. "Lemon Garlic Chicken"
`course`	No	Course, same values as save_recipe
`method`	No	Cooking methods, same values as save_recipe
`cuisine`	No	Any level, e.g. "Mexican", "Sicilian", "Asian"
`occasion`	No	e.g. ["Weeknight", "Christmas", "Game Day"]
`servings`	No	Number of servings the amounts make, e.g. 4 (default 4 on save)
`source_url`	No	Original web page URL, if any
`visibility`	No	private = only the user; family = shared with family_group_id. Default: the user's sharing default
`description`	No	One or two sentences about the dish, max 2000 chars
`ingredients`	No	Lines like "2 cups flour, sifted" or {quantity, unit, item, note, group}; replaces the whole list
`inspired_by`	No	Sources it riffs on: [{title, url}]
`cook_minutes`	No	Cook time in minutes
`prep_minutes`	No	Prep time in minutes
`scale_factor`	No	Permanently multiply all amounts, e.g. 0.5 or 2
`change_summary`	No	Short history note, max 300 chars, e.g. "Less salt"
`family_group_id`	No	Group id (from manage_family list) when visibility is family
`main_ingredient`	No	Main ingredient, same values as save_recipe
`scale_to_servings`	No	Permanently rescale all amounts to this many servings, e.g. 8

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 29, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations only declare the mutation profile (destructive, non-idempotent, not read-only); the description goes well beyond that with patch semantics ("only fields you pass change"), list replacement behavior, the revision-on-every-edit model with its undo path, ownership restrictions, and account-level blocking. That is exactly the context an agent needs before firing a destructive write.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five tight sentences with zero filler, front-loaded with the core contract and then the patch/scaling/permission caveats in order of operational risk. Every sentence carries information an agent could otherwise get wrong.

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 22-parameter mutation tool with no output schema, the description covers the return ("Returns the updated recipe"), the mutation model, the undo path, permissions, and the scaling-vs-view distinction. Nothing material is left for the agent to infer.

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 already 100%, so the baseline is 3, but the description adds real meaning the schema does not: lists passed replace rather than append, and scale_factor/scale_to_servings mutate permanently while get_recipe is the non-mutating alternative. These are the two highest-risk parameter ambiguities on a 22-param tool, and both are resolved.

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 ("Change any field of a recipe or draft") plus the ownership scope. It is immediately distinguishable from save_recipe (creation), get_recipe (read), and delete_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?

Names explicit alternatives and the conditions that select them: restore_revision for undo, get_recipe for a one-off view, and the scale_to_servings/scale_factor pair for permanent resizing. It also flags the preconditions that block a call (read-only accounts, owner-only filing fields).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Your AI Kitchen (YAK) 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?