Fitatu MCP Unofficial

Create Fitatu Recipe

create_recipe

Create a Fitatu recipe by providing a name, ingredients, and servings, then receive a recipe ID and details for adding to your meal plan.

Instructions

Creates and confirms a Fitatu recipe from validated products selected with search_food. A non-empty name, at least one ingredient, and a positive whole number of servings are required. Pass preparation instructions as steps with one step per array item so Fitatu displays separate step fields. Ingredient quantities must be positive finite numbers. For custom tags use RECIPE_TAG_USERS_TYPE. Recipes are private unless shared=true. Returns { status, recipeId, details, warnings }; details.measures contains measureId values accepted by add_meal_items, recipeId is canonical, and repeating the same request creates another recipe.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Non-empty recipe name after trimming.
`tags`	No	Complete list of system or custom recipe tags. Omit to create the recipe without tags.
`steps`	No	Ordered preparation steps without numeric prefixes. Put exactly one step in each string; Fitatu displays every array item as a separate step field. Omit or use [] when no instructions are available.
`shared`	No	Whether the recipe may be visible in Fitatu's public catalog. Defaults to false (private).
`servings`	Yes	Positive integer number of portions produced by the recipe.
`mealSchema`	No	Fitatu meal keys for which the recipe is suggested: breakfast, second_breakfast, lunch, snack, supper. Omit for no suggestions. Use only this declared enum; raw public catalog values returned by get_recipe may not be valid mutation inputs.
`ingredients`	Yes	Products included in the recipe. Provide at least one validated product/measure selection.
`cookingTimeMinutes`	No	Non-negative whole cooking time in minutes. Omit or use null when unknown.
`preparationTimeMinutes`	No	Non-negative whole preparation time in minutes. Omit or use null when unknown.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	Fitatu accepted the write and the service confirmed its observable effect.
`details`	Yes	Canonical recipe details returned by a read-after-write request.
`recipeId`	Yes	Canonical id for subsequent operations. This is always identical to details.recipeId.
`warnings`	Yes	Non-fatal write warnings; currently empty for validated recipe creation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=false and idempotentHint=false, and the description amplifies these by explicitly stating 'repeating the same request creates another recipe'. It also discloses the privacy default ('private unless shared=true') and the return contract (status, recipeId, details, warnings) with a pointer to add_meal_items. This is rich behavioral context beyond the structured annotations.

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 seven sentences, which is on the longer side, but every sentence earns its place: purpose, required fields, step formatting, numeric validation, tag guidance, privacy default, and return behavior. The main purpose is front-loaded, and there is no filler or repetition.

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 9-parameter creation tool, the description is remarkably complete. It covers prerequisites, validation rules, preparation steps semantics, tag handling, visibility default, return structure, downstream compatibility, and non-idempotency. The output schema exists, so the return-value details do not need full enumeration, but the description still provides the critical integration points.

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. The description adds value by explaining the 'why' behind step arrays ('one step per array item so Fitatu displays separate step fields'), reinforcing numeric constraints ('positive finite numbers'), and directing custom tags to RECIPE_TAG_USERS_TYPE. These clarifications exceed what the schema alone provides.

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 uses a specific verb-resource pair ('Creates and confirms a Fitatu recipe') and immediately names the source of validated products ('selected with search_food'). This distinguishes it from siblings like update_recipe, get_recipe, and delete_recipe without needing to open their schemas.

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 states clear prerequisites: products must be validated via search_food, required fields (name, ingredients, servings), and downstream integration ('measureId values accepted by add_meal_items'). It does not explicitly say 'use update_recipe to modify an existing recipe', but the creation context and non-idempotency warning make the intended use unambiguous.

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