Unofficial Monsieur Cuisine MCP

Overview Schema Source Related Servers Discussions Admin

Get Recipe

get_recipe

Fetch full recipe details—ingredients, per-serving instructions, and nutrition—as clean JSON, including your own draft or private recipes that public pages don't expose.

Instructions

Fetch full details for a single recipe: ingredients, step-by-step instructions per serving size, and nutrients (calories/protein/ carbohydrate/fat).

Always call this tool to get recipe details instead of fetching the recipe's web page directly - the web page requires a headless browser to render and does not expose this data as clean JSON.

Works for public recipes without login. It also reads the caller's OWN unpublished recipes (draft / private-publish) - those aren't served by the public API, so it falls back to the authenticated endpoint, which needs a saved login session. (Own recipes come back in a slightly different shape.)

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_id": "<recipe_id>"
    },
    "name": "get_recipe"
  }
}

Input Schema

Name	Required	Description	Default
`language`	No	Locale to fetch the recipe in, e.g. "pl-PL", "en-US".	en-US
`recipe_id`	Yes	Numeric recipe id, from the `id` field of a search_recipes or list_my_recipes result (not the URL slug).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A4.2/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 well: it discloses the auth requirement for own unpublished recipes, the internal fallback to an authenticated endpoint, and that own recipes return a slightly different shape. It stops short of failure behavior — what happens if the session is missing or the id is invalid — which matters for a tool with a login-dependent code path.

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?

Front-loads what is returned, then the directive to use it instead of the web page, then the auth caveat. Three short paragraphs, each carrying distinct information, with no restated title or filler.

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?

An output schema exists, so return values needn't be spelled out, and the description covers the genuinely tricky parts: source, auth, and shape variation. Only the error/missing-session path is left implicit, which is a modest gap for a tool that can silently fall back to an authenticated call.

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%, so both parameters are already documented, including that recipe_id is the numeric id rather than the URL slug. The description adds nothing about the language parameter (locale fallback behavior) or about how language interacts with own-recipe shape differences. Baseline 3 is appropriate.

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 ('Fetch full details for a single recipe') and enumerates the payload: ingredients, step-by-step instructions per serving size, and nutrients. Combined with the schema's note that recipe_id comes from search_recipes/list_my_recipes, an agent can distinguish this from the list/search siblings without opening anything else.

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?

Explicitly tells the agent to prefer this over scraping the recipe's web page and explains why (headless browser, no clean JSON). It also scopes coverage: public recipes without login, plus the caller's own drafts. The one gap is that it never says when to use get_cookidoo_recipe or get_paprika_recipe instead, which are direct alternatives in the sibling set.

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