Unofficial Monsieur Cuisine MCP

Overview Schema Source Related Servers Discussions Admin

Import Cookidoo Recipe

import_cookidoo_recipe

Imports one Cookidoo recipe into a Monsieur Cuisine account, converts Thermomix settings into Smart device programs, then creates and optionally publishes it privately or publicly.

Instructions

Import ONE Cookidoo recipe into the user's Monsieur Cuisine account.

Fetches the recipe from Cookidoo (Thermomix settings included), converts it (ingredients split, Thermomix -> MC Smart device programs, times, servings, nutrition, cover photo), creates the recipe and (publish=True) publishes it. private=True publishes only to the user's own account (no editorial review).

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_ref": "<recipe_ref>"
    },
    "name": "import_cookidoo_recipe"
  }
}

Input Schema

Name	Required	Description	Default
`email`	No
`country`	No
`private`	No	Publish privately (default True).
`publish`	No	Publish after creating (default True).
`language`	No
`password`	No
`recipe_ref`	Yes	Cookidoo recipe id or URL.
`mc_language`	No	Monsieur Cuisine locale, e.g. 'en-US'.	en-US

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it discloses the conversion performed (ingredient splitting, Thermomix -> MC Smart device programs, times, servings, nutrition, cover photo), that a recipe record is created, and that publish=True triggers publication while private=True limits it to the user's own account with no editorial review. It omits auth requirements, failure/duplicate behavior, and whether publish_recipe is bypassed.

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?

Front-loads the one-line purpose, then details mechanics and flag outcomes in a compact block. Dense but every clause conveys real behavior (conversion steps, publishing model); only the parenthetical 'Thermomix settings included' is marginal.

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?

An output schema exists, so return values need not be explained, and the mutation/publish side effects are covered. Yet for an 8-parameter write tool with no annotations, the missing authentication prerequisites and the four undocumented credential/locale parameters leave real gaps an agent would need to guess at.

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 50%: recipe_ref, publish, private, and mc_language are already documented in the schema. The description does enrich publish/private with consequence semantics ('publishes it', 'no editorial review'), but email, password, country, and language are undocumented in both places, leaving credential/locale semantics unexplained.

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 ('Import ONE Cookidoo recipe') and scopes it to the user's Monsieur Cuisine account, with 'ONE' implicitly distinguishing it from bulk import siblings such as import_paprika_recipes. It never names an actual sibling (get_cookidoo_recipe, create_recipe, publish_recipe), so the differentiation is inferred rather than explicit.

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 pipeline description (fetch -> convert -> create -> publish) implies when the tool applies, and the publish/private flags hint at output routing. However, there is no explicit statement of when to use this versus get_cookidoo_recipe (read-only fetch) or create_recipe (native creation), and no prerequisites such as needing a Cookidoo session despite cookidoo_login/cookidoo_status being siblings.

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