Skip to main content
Glama
Cookidoo MCP Server

Cookidoo MCP Server

by herp75

Generate Recipe Structure

generate_recipe_structure
Read-only

Build and validate a Cookidoo-ready recipe structure, including Thermomix-compatible settings, without changing anything on Cookidoo. Returns JSON for custom recipe upload or update.

Instructions

Generate and validate a recipe structure ready for upload to Cookidoo. Changes nothing on Cookidoo.

Returns a JSON structure to show to the user and then pass to upload_custom_recipe or update_custom_recipe. Thermomix settings are checked against what the target device supports (see get_thermomix_modes).

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": {
      "name": "<name>",
      "ingredients": "<ingredients>",
      "steps": "<steps>"
    },
    "name": "generate_recipe_structure"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesRecipe name (required)
hintsNoOptional cooking tips, as a list (or one per line)
stepsYesCooking steps, as a list (or one per line). A step without machine settings or ingredient links is plain text. Otherwise it is an object whose text holds one {settings} placeholder per entry of settings; the server writes each setting into the text and presets it on the Thermomix. A setting's "mode" picks its fields (allowed values are in the schema): "manual" (default: time, temperature, speed, reverse), "dough", "browning", "steaming", "turbo", "rice_cooker", "warm_up", "blend". "ingredients" links words of the text to an ingredient line. Example: {"text": "Add the onion and sauté {settings}.", "settings": [{"time": 180, "temperature": "120", "speed": "1"}], "ingredients": [{"text": "the onion", "ingredient": "1 onion"}]}
deviceNoTarget Thermomix, "TM5", "TM6" or "TM7". Default: the COOKIDOO_DEVICE setting, else the devices linked to the account (TM6 rules if a TM6 is among them), else TM6
servingsNoNumber of servings (default: 4, range: 1-20)
prep_timeNoActive preparation time in minutes (default: 30)
total_timeNoTotal time in minutes, at least prep_time (default: 60)
ingredientsYesIngredients with quantities, as a list (or one per line)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description reinforces this with "Changes nothing on Cookidoo" – no contradiction. It adds value beyond annotations by disclosing that settings are validated against the target device's supported modes, and that the output is an intermediate structure meant for user review. It stops short of mentioning any authentication/connection prerequisite, which is the remaining gap.

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 short sentences, front-loaded with what it does and the safety claim, followed by the return value and the validation caveat. No redundant restatement of parameters and nothing that could be cut.

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 an 8-parameter tool with a deeply nested schema and no output schema, the description covers the essential unknowns: no state change occurs, the output is a hand-off artifact, and settings are device-validated. Only the return structure's shape and any connection prerequisites are left implicit, which is minor given how prescriptive the input schema is.

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% and the nested settings/ingredients structure is documented in exhaustive detail in the schema itself, so the bar is a baseline 3. The description adds only one piece of meaning beyond the schema – that the device parameter governs which Thermomix settings pass validation – while the rich placeholder and mode semantics are already spelled out 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?

States a specific verb and resource ("Generate and validate a recipe structure") plus the destination context ("ready for upload to Cookidoo"), and explicitly separates it from the sibling write tools upload_custom_recipe and update_custom_recipe. An agent can tell this is the validate/build step rather than the commit step 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?

Gives explicit sequencing guidance: return the JSON to the user first, then hand it to upload_custom_recipe or update_custom_recipe. It also points to get_thermomix_modes when device capability matters, so the agent knows both the next step and the reference tool.

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