Skip to main content
Glama

Create Recipe

create_recipe

Create a new Monsieur Cuisine Smart recipe draft under your account by providing a title and optional ingredients, steps, nutrition, and photo; publishing remains a separate step.

Instructions

Create a new recipe as a DRAFT under the logged-in user's account.

The recipe is created for the Monsieur Cuisine Smart (MC3.0), the only supported device. Only title is required. The recipe is saved as a draft (status "draft") and is NOT published. Pass image_path to attach a dish photo (see below). Publishing is a separate step: once the draft is complete, call publish_recipe (public review, or private=True for a private publish). A published recipe cannot be reverted to a draft; to take it down, switch it to private or delete it with delete_recipe.

Requires a saved login session: run uv run monsieur-cuisine-mcp-login once beforehand. If no session is saved, this tool raises an error telling the user to do that.

The valid step program names and their params are listed in full under steps below - you do NOT need another call to enumerate them. Only complexity_id and category_ids are language-specific ids you cannot guess: call list_recipe_creation_options(language) first (same language) to get those, or omit them (a draft is valid without them).

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>"
    },
    "name": "create_recipe"
  }
}

Input Schema

NameRequiredDescriptionDefault
fatNoFat per serving (g). Rounded to a whole number.
stepsNoOrdered list of step dicts. Each step is {"text": <instruction>, ...optional program fields}; a plain string is shorthand for a text-only step. Add an optional "title" (short step heading): every step needs a non-empty title to be publishable, so when omitted a localized ordinal ("Krok 1"/"Step 1") is filled in automatically. A step with no "program" is a plain text instruction. To run an automatic device program, add "program" plus the params it uses. All times are in SECONDS. Full list of programs (Monsieur Cuisine smart) and their params: - "customized": temperature_celsius, speed, time_seconds, reverse (bool, true = counter-clockwise) - "kneading", "kneading_solid_dough", "kneading_soft_dough", "kneading_liquid_dough": time_seconds - "steaming", "rice_cooking", "food_processor", "puree", "smoothie", "turbo": time_seconds - "roasting", "sous_vide", "slow_cooking", "fermentation": temperature_celsius, time_seconds - "scale" (weighing): weight_grams - "cooking_eggs": egg_size ("small"|"medium"|"large"), egg_texture ("soft"|"waxy_soft"|"hard") - "precleaning": cleaning_duration ("short"|"long") Examples: {"text": "Rozdrobnij", "program": "customized", "speed": 7, "temperature_celsius": 90, "time_seconds": 120} {"text": "Zwaz skladniki", "program": "scale", "weight_grams": 250} {"text": "Wymieszaj recznie"} # plain text step
titleYesDish name (required).
proteinNoProtein per serving (g). Rounded to a whole number.
caloriesNoEnergy per serving (kcal). Rounded to a whole number.
languageNoRecipe language/locale, e.g. "pl-PL", "en-US".en-US
image_pathNoOptional path to a local dish photo (JPEG, PNG or WebP) to attach as the recipe's cover image. It is uploaded to the media service and set as both the thumbnail and the details image. This is the photo a draft needs before it can be published in the web app.
descriptionNoShort description of the dish.
ingredientsNoList of ingredient dicts for the default general group, each with keys "name", "amount", "unit". Ingredients are free text - the "name" is used verbatim (like typing a custom ingredient in the app without picking a suggestion), no database match required. Add an optional "system_ingredient_id" (a positive id from search_ingredients) only to link a specific database ingredient. The default group is auto-named "General Ingredients" (a group needs a name to publish).
carbohydrateNoCarbohydrate per serving (g). Rounded to a whole number.
category_idsNoCategory ids from list_recipe_creation_options.
complexity_idNoDifficulty level id from list_recipe_creation_options.
servings_unitNoServing unit, from list_recipe_creation_options' serving_units (e.g. "porcje").
servings_amountNoNumber of servings the recipe yields.
ingredient_groupsNoOptional named ingredient groups, each {"name": <group name>, "ingredients": [ingredient dicts]} (same ingredient shape as above). Use for recipes split into sections like "Dough" / "Sauce"; give each a non-empty name so the recipe can be published.
prep_time_minutesNoPreparation time in minutes.
ready_time_minutesNoTotal time until ready, in minutes.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the draft status, non-published state, login-session requirement and failure behavior, irreversible publish behavior, and that image_path is uploaded as cover art. These are meaningful operational details beyond the schema.

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?

The description is long but appropriately front-loaded for a 17-parameter creation tool, starting with the draft outcome and then covering publishing, auth, and language-specific ids. A few phrases repeat schema information, but the length is largely justified by the tool's complexity.

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

Completeness5/5

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

Given the absence of annotations, the presence of an output schema, and the complexity of a 17-parameter create operation, the description covers the key gaps an agent would otherwise face: draft state, auth prerequisites, publishing workflow, and when to fetch creation options. Nothing essential is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful cross-parameter semantics: only title is required, complexity_id/category_ids are language-specific and optional, and image_path should be a local photo path for the cover image. It also points to list_recipe_creation_options without repeating all schema details.

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 (create_recipe) and immediately clarifies the resulting state: a DRAFT under the logged-in user's account. It distinguishes this from publish_recipe, edit_recipe, and delete_recipe by explaining that creation and publishing are separate steps.

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 when-to-use guidance, prerequisites (saved login session), and the alternative path for publishing via publish_recipe with private=True. It also tells the agent to call list_recipe_creation_options for language-specific ids or omit them safely, and to call delete_recipe instead of reverting a published recipe.

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