Fitatu MCP Unofficial

Get Fitatu Recipe

get_recipe

Read-onlyIdempotent

Retrieve canonical recipe details by raw recipe ID, including per-serving nutrition, ingredients, measures, and edit status. Handles soft-deleted recipes while flagging them as not editable.

Instructions

Gets canonical per-serving details and add_meal_items measures for a raw recipeId returned by a recipe-aware MCP tool. Soft-deleted recipes remain readable with deleted=true and editable=false. Raw productId and recipeId spaces may overlap, so the recipeId field determines how the supplied value is interpreted. Returns canonical recipe details { recipeId, name, servings, shared, editable, deleted, mealSchema, tags, ingredients, nutritionPerServing, measures, ...optionalFields }.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`recipeId`	Yes	Raw Fitatu recipe id returned by a recipe-aware MCP tool.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Recipe display name.
`tags`	Yes	Complete tag list; an empty array means the recipe has no tags.
`steps`	Yes	Ordered preparation steps parsed from Fitatu's newline-delimited recipe description; an empty array means no instructions are available.
`shared`	Yes	Whether Fitatu marks the recipe as shared with its public catalog.
`userId`	No	Owning Fitatu user id, when the upstream response exposes it.
`deleted`	Yes	Whether Fitatu reports that the recipe has been deleted.
`editable`	Yes	True only when this recipe is active and the authenticated user may currently update or delete it. Deleted and unowned recipes are false.
`measures`	Yes	Measures accepted for this recipe by add_meal_items. Copy recipeId with one listed measureId; an empty array means Fitatu returned no usable measures.
`recipeId`	Yes	Canonical raw Fitatu recipe id for subsequent MCP operations.
`servings`	Yes	Positive integer number of servings produced by the recipe.
`mealSchema`	Yes	Raw Fitatu meal keys stored with the recipe. Public catalog values such as dinner are preserved and are not the accepted input enum for recipe mutations.
`ingredients`	Yes	Canonical ingredient list; an empty array means Fitatu returned no usable ingredients.
`weightPerServingG`	No	Calculated weight of one recipe serving in grams, when Fitatu provides it.
`cookingTimeMinutes`	No	Cooking time in whole minutes; omitted when unavailable.
`nutritionPerServing`	No	Nutrition calculated for one serving, omitted when Fitatu provides no nutrient values.
`preparationTimeMinutes`	No	Preparation time in whole minutes; omitted when unavailable.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 21, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds substantial behavioral context beyond that: soft-deleted recipes remain readable with deleted=true and editable=false, and overlapping productId/recipeId spaces are resolved by the recipeId field. These details inform the agent about edge-case behavior and result interpretation, going well beyond what annotations provide.

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?

The description is efficiently structured: the main purpose is front-loaded, followed by key edge-case behaviors, and finally the return structure. Every sentence adds necessary information—no filler. The length is justified by the technical complexity (ID-space overlap, soft-delete handling) and is still concise.

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 a single parameter, a full input schema description, and an output schema (indicated by the return structure), the description covers all essential aspects: what it does, when to use it, input constraints, edge cases, and the shape of the result. It does not need to restate return values since an output schema exists. Nothing critical for an agent to call this tool correctly 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?

The input schema already describes recipeId as 'Raw Fitatu recipe id returned by a recipe-aware MCP tool,' giving 100% coverage. The description adds further semantic value by explaining that 'Raw productId and recipeId spaces may overlap, so the recipeId field determines how the supplied value is interpreted.' This clarifies ambiguity that the schema alone does not address, making the parameter semantics richer.

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 opens with a specific verb and resource: 'Gets canonical per-serving details and add_meal_items measures for a raw recipeId.' It further narrows the input to IDs 'returned by a recipe-aware MCP tool,' distinguishing this read tool from siblings like search_recipes (query-based) and create/update/delete mutations. The term 'canonical' reinforces its role as the authoritative recipe detail fetcher.

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?

The description clearly states the input is a raw recipeId from a recipe-aware MCP tool, which tells an agent when to use it (when it already holds such an ID). It also notes soft-deleted recipes remain readable with deleted=true and editable=false, providing context about behavior in that edge case. However, it does not explicitly name alternative tools or give a 'when not to use' clause, so it lacks explicit exclusions.

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