Bryti

Change a recipe

edit_recipe

DestructiveIdempotent

Change a recipe the household owns, found by its current title. Only the fields given change; ingredients, steps and timeline replace the whole list when given, so send them complete, as get_recipe shows them. Mark what can be made ahead in timeline, so it lands on the prep day.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recipeTitle": "<recipeTitle>"
    },
    "name": "edit_recipe"
  }
}

Input Schema

Name	Required	Description
`note`	No	The recipe's own note: the intro and the author's assessment. On edit_recipe an empty string removes it.
`tags`	No	The complete new tag list.
`steps`	No	The COMPLETE new list of steps.
`category`	No	The meal category.
`newTitle`	No	A new title, when the dish is being renamed.
`portions`	No	How many portions the base quantities make.
`timeline`	No	The steps done at a set time before serving, and the ones that can be made ahead. Mark what can be made ahead whenever the recipe or the user says so («sausen kan lages dagen før»); a step that must happen at cooking time has no entry, and most recipes have few. On edit_recipe the list replaces the whole timeline.
`equipment`	No	What the kitchen needs that is not food. Never on the shopping list. On edit_recipe the list replaces it.
`stepNotes`	No	Notes under the steps. On edit_recipe the list replaces all of them.
`ingredients`	No	The COMPLETE new ingredient list.
`recipeTitle`	Yes	The recipe's current title.
`ovenSettings`	No	The oven per step. On edit_recipe the list replaces all of them.
`totalMinutes`	No	Total minutes from start to serving (≥ active).
`activeMinutes`	No	Hands-on cooking minutes.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds the crucial detail an agent needs: only supplied fields change, while ingredients, steps and timeline replace wholesale and must be sent complete. That replacement hazard is exactly the behavior an agent would otherwise get wrong. It does not say whether edits can be reverted or what happens on a title mismatch.

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?

Three sentences, front-loaded with identity and scope, then the mutation rule, then the one non-obvious modeling hint. No restatement of the title or filler.

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?

For a 14-parameter mutation with no output schema, the description covers the lookup key, the partial-update contract, the destructive list replacement, and the trickiest nested concept (timeline). Remaining gaps — failure mode on unknown title, and confirmation of what is returned — are modest given the exhaustive schema.

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 100% schema description coverage the baseline is 3, and the description earns above it by explaining the replace-not-merge semantics for list parameters and by characterizing timeline as the mechanism that puts make-ahead work onto the prep day — meaning not restated in the schema.

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?

Names a specific verb and resource ('Change a recipe'), states the ownership scope ('the household owns'), and gives the lookup key ('found by its current title'). This distinguishes it clearly from save_recipe, delete_recipe and get_recipe in the sibling list.

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?

Explains the operating procedure: locate by current title, send only the fields to change, and send list fields complete 'as get_recipe shows them' — an implicit but clear pointer to the read sibling. It stops short of saying when to prefer save_recipe or import_recipe_from_url instead, or what to do if the title does not match.

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

All Bryti 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?