Cookidoo MCP Server

Overview Schema Source Related Servers Discussions Admin

Upload Custom Recipe

upload_custom_recipe

Creates a new custom recipe on a user's Cookidoo account for a specified Thermomix after explicit approval; use it only to add recipes, not modify existing ones.

Instructions

Create a brand new custom recipe on the user's Cookidoo account, for one Thermomix.

Only call this after the user explicitly approved the recipe. Each call creates another recipe: to change one already uploaded, use update_custom_recipe instead.

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": {
      "recipe_json": "<recipe_json>"
    },
    "name": "upload_custom_recipe"
  }
}

Input Schema

Name	Required	Description	Default
`device`	No	Target Thermomix, "TM5", "TM6" or "TM7" (same default as generate_recipe_structure). The recipe is created for this device.
`recipe_json`	Yes	The validated recipe JSON from generate_recipe_structure

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Nov 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the description's added value is the non-idempotency warning: "Each call creates another recipe", which tells the agent that repeated invocation produces duplicates. It also notes the recipe is bound to one Thermomix. It stops short of describing what happens on verification failure or whether duplicate names are rejected, so it is strong but not exhaustive.

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 clauses, front-loaded with the action and immediately followed by the approval gate and the sibling alternative. No filler or restatement of the title.

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?

With an output schema present, return values need no explanation, and the definition covers the mutation behavior, duplication risk, approval gate, and sibling routing. It could mention the implicit dependency on a validated recipe_json from generate_recipe_structure rather than leaving that to the schema, which is the only remaining gap for a create operation.

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 100% and both parameters are already documented, including the device enum and its link to generate_recipe_structure's default. The description only adds the framing that the recipe is scoped to a single Thermomix, which mildly clarifies the device parameter; the baseline 3 applies when the schema does the heavy lifting.

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?

"Create a brand new custom recipe on the user's Cookidoo account, for one Thermomix" gives a specific verb (create), resource (custom recipe), target system (Cookidoo), and scope (single device). It also explicitly contrasts with update_custom_recipe, so an agent can distinguish the two without opening either 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?

States a hard precondition ("Only call this after the user explicitly approved the recipe") and names the correct alternative plus the condition that selects it ("to change one already uploaded, use update_custom_recipe instead"). Both when-to-use and when-not-to-use are covered.

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