fitatu-api

Overview Schema Source Related Servers Discussions Admin

Copy a meal

copy_meal

Copy food rows from one meal to another meal or day; select specific rows or the whole meal, keeping quantities, products, recipes, and custom nutrition.

Instructions

Copy the food rows of a meal, or only row_ids of it, to another meal and/or day in one write, e.g. 'the same breakfast as yesterday' or 'plan this lunch for tomorrow'. Products and recipes keep their measure and quantity, custom rows their name and nutrition; rows of other types are not copied and are listed in skipped. Returns the copies' row_ids (remove_items with them undoes the copy); data.ok says a re-read shows them all. Each call adds rows unless row_id is reused.

Input Schema

TableJSON Schema

Name	Required	Description
`eaten`	No	Sets every copy: true when the user ate it or just asks to log it, false when they plan ahead. Omit it to keep each row's eaten.
`row_id`	No	Optional UUID version 1 the copies' row_ids are derived from; omit it to get a new one. Repeating the copy with the same row_id and arguments writes the same rows again instead of new ones: when a failed copy's error has a retry_row_id, repeat it with that row_id. Never a row_id from get_day.
`row_ids`	No	Only these rows of from_meal (row_ids from get_day); omit it for the whole meal.
`to_date`	Yes	Day to copy to, as YYYY-MM-DD (from_date itself when to_meal differs); when the user says today, yesterday, this week or a weekday, call get_today and count from its date.
`to_meal`	No	Meal to copy into (default: from_meal). Meal slot. The keys are fixed, but users rename their meals in the app: match the user's words against get_day's meal_name and pass that meal's meal_key. Only the meals get_day lists exist.
`from_date`	Yes	Day as YYYY-MM-DD; when the user says today, yesterday, this week or a weekday, call get_today and count from its date.
`from_meal`	Yes	Meal to copy. Meal slot. The keys are fixed, but users rename their meals in the app: match the user's words against get_day's meal_name and pass that meal's meal_key. Only the meals get_day lists exist.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`error`	No	describe_error() of what went wrong; docs/AGENTS.md, Results and errors.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description goes well beyond them: what is preserved (measures/quantities for products and recipes, name/nutrition for custom rows), what is skipped and surfaced in 'skipped', the additive nature ('Each call adds rows unless row_id is reused'), the undo path via remove_items, and the row_id idempotency-key mechanism. This is rich disclosure layered on top of the 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?

Three front-loaded sentences that lead with the core action before qualifying details. Dense but mostly earned; the return-value/undo sentence is somewhat packed and overlaps with the output schema, but nothing is wasted boilerplate.

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?

With an output schema present, annotations covering safety, and 100% schema coverage across 7 parameters, the description still adds the behavioral context an agent needs: copy semantics per row type, skip behavior, undo, and repeat-call semantics. Complete for this tool's complexity.

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% and the property descriptions are already very detailed (row_id retry semantics, meal_key matching, date counting from get_today). The prose adds little parameter-level meaning beyond what the schema states, so the baseline of 3 applies.

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 names a specific verb and resource ('Copy the food rows of a meal... to another meal and/or day in one write') and immediately scopes it with a partial-copy variant ('or only row_ids of it'). Concrete examples ('the same breakfast as yesterday', 'plan this lunch for tomorrow') make the intent unmistakable and distinguish it from siblings like move_item, add_food, and add_foods.

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?

It gives clear usage context through examples and explains the eaten flag as selecting 'log it' vs 'plan ahead', plus retry behavior when a copy fails. It stops short of explicitly naming a competing tool or a when-not-to-use condition (e.g. move_item vs copy), leaving some routing to inference.

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