Bryti

Save a recipe

save_recipe

Save a new recipe to the household's own recipes. Mark what can be made ahead (a sauce, a dough) 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": {
      "title": "<title>",
      "category": "<category>",
      "ingredients": "<ingredients>",
      "steps": "<steps>",
      "tags": "<tags>",
      "activeMinutes": "<activeMinutes>",
      "totalMinutes": "<totalMinutes>",
      "portions": "<portions>"
    },
    "name": "save_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`	Yes	Descriptive tags; may be empty.
`steps`	Yes	Ordered cooking steps.
`title`	Yes	Recipe title, e.g. 'Grandma's fish soup'.
`category`	Yes	The meal category.
`portions`	Yes	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`	Yes	The ingredients with quantities.
`ovenSettings`	No	The oven per step. On edit_recipe the list replaces all of them.
`totalMinutes`	Yes	Total minutes from start to serving (≥ active).
`activeMinutes`	Yes	Hands-on cooking minutes.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 7, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the safety profile is known. The description adds the downstream consequence that make-ahead timeline entries are scheduled onto the household's prep day, which is useful behavior beyond the annotations, but it says nothing about duplicate-title handling, validation failures, or what is returned after saving.

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?

Two short sentences with zero filler; the core action is front-loaded and the one high-value field behavior follows. Nothing needs trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a 13-parameter, 8-required creation tool with deeply nested objects and no output schema, and the description covers only the timeline concept. Given 100% schema coverage the gaps are tolerable, but the agent gets no guidance on required-field expectations, ingredient keying, or what a successful save yields.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already carries the parameter burden, and the earliestMinutesBefore field itself documents the prep-day effect. The description reinforces the most important semantic (mark make-ahead work in timeline) but adds no syntax or constraints beyond what is already structured.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Save a new recipe to the household's own recipes"), and the word "new" implicitly separates it from the edit_recipe sibling. It stops short of naming edit_recipe or import_recipe_from_url explicitly, so the differentiation is inferred rather than declared.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives real usage guidance for the timeline field (mark anything that can be made ahead so it lands on the prep day). However, there is no explicit "when to use this vs. import_recipe_from_url or edit_recipe" routing, so an agent must infer the create-vs-edit boundary from the sibling names alone.

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?