fitatu-api

Overview Schema Source Related Servers Discussions Admin

Remove logged foods

remove_items

DestructiveIdempotent

Delete logged food rows from a day by row_id, listing each removed item with its details so it can be added again. Also reports missing ids, making repeats safe.

Instructions

Delete logged food rows from a day by row_id (meals[].items[].row_id in get_day). removed lists each deleted row with what it was (meal, meal_name, row_id, name, food_type, food_id, measure_id, measure_name, measure_quantity, energy in kcal, protein/fat/carbohydrate in g, eaten), enough to add it again: with add_food, or with add_custom_item from its name and nutrition when food_id is null (a custom row); failed lists the rows still there. Ids that are not food rows on the day (already deleted, or an activity's row_id) are listed in missing, so repeating the call is safe. Preview a removal with preview_removal, which only reads; dry_run does the same here. data.ok is false when a row was missing or failed; the result's top-level ok only says the call ran.

Input Schema

TableJSON Schema

Name	Required	Description
`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.
`dry_run`	No	Only report what would be deleted; preview_removal does it without a destructive call.
`row_ids`	Yes	row_ids from get_day.

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.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description goes further by explaining the mechanism behind idempotency (non-food/already-deleted ids land in missing), the recovery data returned, and the distinction between data.ok and the top-level ok, which is real added context.

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?

Front-loaded with the action and row identifier in the first clause, and every sentence carries information. It is dense to the point of being run-on, and the dry_run/preview_removal point is repeated from the schema, so it is not maximally tight.

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 destructive, idempotent mutation this covers what it needs: identifier source, preview path, restoration options, failure semantics and the missing/failed/removed distinction. An output schema exists, so the return-value detail is largely redundant but harmless.

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, but the description adds provenance for row_ids (the exact meals[].items[].row_id path) and clarifies dry_run's relation to preview_removal beyond the schema's own wording. That is a modest but real increment over the structured fields.

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?

States a specific verb and resource (delete logged food rows from a day) and pins the identifier to its source (meals[].items[].row_id in get_day). It is clearly separable from siblings like preview_removal, add_food, update_item and remove_activity, so an agent can route without opening schemas.

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?

Explicitly names preview_removal as the read-only alternative and notes dry_run does the same here, gives the recovery path (add_food for normal rows, add_custom_item when food_id is null), and warns that repeating the call is safe. This is genuine when/when-not guidance plus alternatives.

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