Fitatu MCP Unofficial

Add Fitatu Meal Items

add_meal_items

Add products, recipes, or custom fallback items to a Fitatu meal for a specific date and meal key, validating each item before confirming it in the meal plan.

Instructions

Validates, submits, and confirms products, recipes, or fallback one-off custom items in a Fitatu meal. Prefer a catalog product or recipe: search with search_food or search_recipes first, then provide productId and measureId for a product or raw recipeId and measureId for a recipe. Custom items are not preferred; use name and nutrition values only when no suitable catalog match exists. The id field selects the variant. Deleted recipes and mismatched measures are rejected before synchronization. Returns { status: 'confirmed', date, mealKey, addedItems: [{ inputIndex, itemId }] }; each itemId is persisted and ready for later meal-item mutations.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Target day in YYYY-MM-DD format where the meal items should be added.
`items`	Yes	One or more strict variants. Prefer {productId, measureId, ...} or {recipeId, measureId, ...} selected through search_food or search_recipes. The {name, energyKcal, ...} custom variant is a fallback only when no suitable product or recipe exists.
`mealKey`	Yes	Fitatu meal key to add items into. Use mealKey values returned by get_day_plan_items. Typical keys are breakfast, second_breakfast, lunch, snack, supper, but accounts with renamed or additional meals may use other keys such as dinner.

Output Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Day where the new meal items were confirmed.
`status`	Yes	The requested mutation was observed in the persisted Fitatu day plan.
`mealKey`	Yes	Meal containing the confirmed new items.
`addedItems`	Yes	Confirmed new items in input order.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only state readOnly=false, openWorld=true, idempotent=false, and destructive=false, so the description carries the behavioral burden. It adds meaningful detail: validation happens before synchronization, rejected inputs are called out, results include a confirmed status, and returned itemIds are persisted and ready for later meal-item mutations. No contradiction with annotations exists.

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 the core action and then gives usage priorities, rejection behavior, and the result shape. It is longer than minimal but each sentence earns its place, except for the vague 'id field selects the variant' sentence, which adds little clarity.

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 three-way variant complexityholo, the description is complete: it explains how to choose among product, recipe, and custom variants, what identifiers to provide, what validation risks exist, and what the caller can expect in the response. Combined with the fully documented schema, an agent has enough to invoke the tool correctly.

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 schema already documents each parameter. The description still adds value beyond the schema by explaining preference ordering, specifying raw recipeId, and noting that custom items should only be used when no catalog match exists. The phrase 'The id field selects the variant' is slightly vague and does not map cleanly to a named schema property, which keeps this from a perfect score.

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-plus-resource statement: it validates, submits, and confirms products, recipes, or custom items in a Fitatu meal. It clearly distinguishes the three item variants and differentiates this tool from the surrounding meal-mutation siblings by emphasizing that it adds new items rather than updating, replacing, or removing them.

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

Usage Guidelines5/5

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

The description gives explicit usage direction: search_food or search_recipes should be used first, catalog products or recipes are preferred, and custom items are a fallback only when no suitable match exists. It also explains preconditions such as using raw recipeId and measureId and warns that deleted recipes and mismatched measures are rejected.

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