Skip to main content
Glama
Tandoor Recipes MCP

Tandoor Recipes MCP

by Cliftonz

Create recipe

create_recipe

Create structured recipes with names, steps, ingredient amounts, and optional servings, times, keywords, and nutrition for saving to a Tandoor Recipes instance.

Instructions

Create recipe. Required: name, steps[{instruction, ingredients[{food, amount, unit?}]}]. Optional: description, servings, working_time, waiting_time, keywords[]

Input Schema

NameRequiredDescriptionDefault
nameYes
stepsYes
formatNoResponse detail level. Default "slim".
privateNo
internalNo
keywordsNo
servingsNo
nutritionNo
propertiesNo
source_urlNo
descriptionNo
waiting_timeNo
working_timeNo
servings_textNo
show_ingredient_overviewNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.4.0

TDQS

C2.9/5.0
Behavior2/5

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

Annotations already state it is a non-destructive, non-idempotent write with no open-world access, so the baseline bar is low, yet the description adds nothing beyond them. It does not say whether duplicate names are rejected, what happens with private/internal flags, or what the response contains.

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?

Compact and front-loaded: the required parameters come before the optional ones, and the nested syntax is compressed into bracket notation with zero wasted words. The terse notation is dense but readable.

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

Completeness2/5

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

For a 15-parameter nested-object creation tool with no output schema and no annotations about response shape, the description is far too thin. It leaves the majority of parameters undocumented and says nothing about what the created recipe looks like or how defaults are applied.

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 coverage is only 7%, so the description must compensate, and it does partially by marking name and steps as required and sketching the nested steps/ingredients shape with unit optional. However, it omits 8 of the 15 parameters (format, private, internal, nutrition, properties, source_url, servings_text, show_ingredient_overview) and the per-step 'time' and ingredient 'note' fields, leaving large gaps.

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?

Opens with a specific verb+resource ('Create recipe'), which distinguishes it from update_recipe and get_recipe. It does not, however, distinguish it from import_recipe_from_url or explain how it relates to create_meal_plan.

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

Usage Guidelines2/5

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

The description only lists required and optional fields; it gives no guidance on when to use create_recipe instead of import_recipe_from_url or create_meal_plan, and no prerequisites are stated. Usage is left entirely implied by the tool name.

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