Fitatu MCP Unofficial

Update Fitatu Recipe

update_recipe

Destructive

Update a specified Fitatu recipe partially by raw recipe ID—change ingredients, steps, tags, servings, or timing while preserving omitted fields. Use null to clear time fields and [] to clear lists.

Instructions

Partially updates and confirms an owned active recipe identified by a raw recipeId. The same create limits apply. Pass preparation instructions as steps with one step per array item so Fitatu displays separate step fields. Omitted fields, including steps and mealSchema, are preserved; null clears nullable time fields, and [] clears lists. Raw public mealSchema values returned by get_recipe are not necessarily accepted mutation inputs. Tag categories must be RECIPE_TAG_USERS_TYPE or already present on this recipe. Fitatu may replace the identity; always use the returned recipeId. Returns { status, previousRecipeId, recipeId, identityChanged, details, warnings }; details.measures contains measureId values accepted by add_meal_items.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Replacement recipe name. Omit to preserve the current name.
`tags`	No	Complete replacement tag list. Omit to preserve current tags; use [] to remove all tags.
`steps`	No	Complete replacement preparation steps without numeric prefixes. Put one step in each string; omit to preserve the current steps and use [] to clear them.
`shared`	No	Replacement sharing setting. Omit to preserve the current value.
`recipeId`	Yes	Raw Fitatu recipe id returned by a recipe-aware MCP tool.
`servings`	No	Replacement positive integer serving count. Omit to preserve the current value.
`mealSchema`	No	Complete replacement list of suggested Fitatu meal keys using only this declared enum. Omit to preserve the stored value, including raw public catalog values; use [] to remove all suggestions.
`ingredients`	No	Complete replacement ingredient list. Omit to preserve current ingredients; at least one ingredient is required when provided.
`cookingTimeMinutes`	No	Replacement cooking time in whole minutes. Omit to preserve; use null to clear.
`preparationTimeMinutes`	No	Replacement preparation time in whole minutes. Omit to preserve; use null to clear.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	Fitatu accepted the write and the service confirmed its observable effect.
`details`	Yes	Canonical details for the updated recipe, read using the resulting recipeId.
`recipeId`	Yes	Canonical id to use after the update. This is always identical to details.recipeId.
`warnings`	Yes	Non-fatal write warnings; currently empty for validated recipe updates.
`identityChanged`	Yes	Whether Fitatu replaced the recipe id: true exactly when recipeId differs from previousRecipeId.
`previousRecipeId`	Yes	Recipe id targeted by the update. It may become obsolete when identityChanged is true.

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?

The description adds rich behavioral detail beyond annotations: omitted fields are preserved, null clears time fields while [] clears lists, identity may be replaced, and returned details.measures are accepted by add_meal_items. It also warns that raw public mealSchema values from get_recipe may not be valid mutation inputs. This substantially exceeds what destructiveHint/readOnlyHint convey.

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 dense but every sentence carries critical information. It front-loads the core purpose, then covers mutation semantics, identity replacement, tag constraints, and the return contract without redundancy. Length is 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?

For a partial-update mutating tool with 10 parameters, an output schema, and known sibling tools, the description covers the essential behavioral contract, return shape, and edge cases like identity changes and invalid raw mealSchema values. The provided output schema supplies formal return details, so the description is sufficiently complete.

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, but the description adds semantic value by explaining update semantics: null clears, [] clears lists, one step per array item, and tag category constraints. It also clarifies that returned mealSchema values are not necessarily valid inputs. This goes beyond the schema's per-field 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 action: 'Partially updates and confirms an owned active recipe identified by a raw recipeId.' This clearly distinguishes the tool from siblings like create_recipe, delete_recipe, and get_recipe by identifying both the operation and the target resource.

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 gives strong usage context: it applies to owned active recipes, uses a raw recipeId from a recipe-aware tool, and references 'the same create limits' from the create path. It does not explicitly list alternatives or when not to use this tool, but the context is clear enough to guide selection among sibling recipe tools.

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