Unofficial Monsieur Cuisine MCP

Overview Schema Source Related Servers Discussions Admin

Import Paprika Recipes

import_paprika_recipes

Imports recipes from a Paprika export to a Monsieur Cuisine account, converting ingredients and steps to device programs and publishing by default. Skips existing recipes to avoid duplicates.

Instructions

Import recipes from a Paprika export archive onto the user's Monsieur Cuisine account, converting each one and (by default) publishing it.

For every selected recipe this: splits the ingredient lines into amount/unit/name ("30 g olive oil"), maps the Thermomix-style directions onto Monsieur Cuisine Smart device programs (customized / slow_cooking / roasting / steaming / kneading / scale - including a scale weighing step wherever the recipe calls for weighing), parses servings, prep/total times and the nutritional_info block, uploads the embedded photo as cover image, maps the Paprika categories/difficulty onto the language's MC category and complexity ids, then creates the recipe and (publish=True) publishes it immediately - private=True publishes only to the user's own account (no editorial review), private=False submits it for public review.

A recipe that fails the publish-completeness check stays as a draft and its publish_error is reported; fix it with edit_recipe + analyze_recipe, then publish_recipe. Re-running with skip_existing=True never creates duplicates (recipes already among the user's own are skipped).

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": {
      "zip_path": "<zip_path>"
    },
    "name": "import_paprika_recipes"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Optional cap on recipes imported in this call - use to work through a large export in batches.
`names`	No	Optional recipe-name substrings to import only those recipes (e.g. ["chicken", "soup"]); omit to import the whole export.
`private`	No	Publish privately to the user's own account (default True).
`publish`	No	Publish each imported recipe (default True).
`language`	No	Locale, e.g. "en-US".	en-US
`zip_path`	Yes	Path to the .paprikarecipes.zip export file.
`skip_existing`	No	Skip recipes whose title already exists among the user's own recipes (default True).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A4.6/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 burden and does so well: it discloses the conversion pipeline, default publishing, private versus public submission behavior, failed publish-completeness handling with publish_error, and duplicate avoidance via skip_existing. These are substantive side effects and failure modes 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 front-loaded with purpose and structured around the import pipeline. It is somewhat long, but most detail is justified by the complexity of the import/publish operation; only the exhaustive conversion list is borderline beyond what an invoking agent needs.

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 high-complexity import operation, rich schema, and existing output schema, the description is complete enough: it covers side effects, publishing modes, failure remediation, and idempotency. An agent has what it needs to call the tool correctly without return-value details.

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 description coverage is 100%, so the baseline is 3. The description adds useful semantic context beyond the schema for publish/private behavior and skip_existing idempotency, though it does not explicitly clarify limit, names filtering, or language beyond the schema's own descriptions.

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?

The description states a specific verb and resource: importing Paprika export recipes into the user's Monsieur Cuisine account, with conversion and publishing behavior. It clearly distinguishes this from sibling inspection tools like list_paprika_recipes/get_paprika_recipe and from other creation tools.

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

Usage Guidelines4/5

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

It gives clear context for when to use this tool (Paprika archive import), explains publish/private mode consequences, and names remediation alternatives edit_recipe + analyze_recipe then publish_recipe after a failed publish. It does not explicitly state when not to use it versus siblings such as list_paprika_recipes, so it falls short of full when/when-not/alternatives guidance.

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