fitatu-api

Overview Schema Source Related Servers Discussions Admin

Change a private product

update_food

DestructiveIdempotent

Edit a Fitatu food product you created: change its nutrients, name, brand, or servings by food_id. Omitted fields stay unchanged, but logged rows may update.

Instructions

Change one of the user's own products (create_food's food_id or a get_my_foods PRODUCT hit's food_id): any value create_food takes but unit; what is not given stays as it is, and servings replaces the list. Any other product is refused before anything is changed (that check reads it). Fitatu usually changes the product in place (replaced_food_id null), and rows already logged with it then show the new values too. It may save the change as a new product instead (seen after a rename or new servings): food_id is then the new id and replaced_food_id the old, retired one, and rows logged before keep the old values. Before changing a product the user has logged, tell them their logged rows may change. Returns measures as create_food does and previous, which update_food takes on food_id to undo the change. data.ok says the server accepted it.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	The product's name, e.g. 'Baton owsiany'.
`brand`	No	Its brand, if the label has one.
`fat_g`	No	Fat in g in 100 g (100 ml for a drink), as the label gives it.
`salt_g`	No	Salt in g.
`barcode`	No	The 8 to 14 digits under the bars. Only the user sees it; find_by_barcode then finds this product.
`fiber_g`	No	Fibre in g.
`food_id`	Yes	create_food's food_id, or a get_my_foods PRODUCT hit's food_id.
`servings`	No	Every serving of it, each name once; replaces the list.
`sugars_g`	No	Of which sugars, in g; at most carbohydrate_g.
`protein_g`	No	Protein in g in 100 g (100 ml for a drink), as the label gives it.
`energy_kcal`	No	Energy in kcal, not kJ, in 100 g (100 ml for a drink), as the label gives it.
`carbohydrate_g`	No	Carbohydrate in g in 100 g (100 ml for a drink), as the label gives it.
`saturated_fat_g`	No	Of which saturated fat, in g; at most fat_g.

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

Behavior5/5

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

Goes well beyond the destructiveHint/idempotentHint annotations: it discloses the dual persistence model (usually in-place with replaced_food_id null, but sometimes saved as a brand-new product with the old id retired), the downstream effect on already-logged rows, the refusal-before-write guarantee, and the undo path via the returned 'previous'. This is exactly the mutation semantics an agent needs.

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 key eligibility constraint, and essentially every sentence carries needed information (eligibility, partial-update semantics, in-place vs new-product, undo, warning duty). The prose is dense and parenthetical-heavy, hurting readability, but little is wasted.

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 13-parameter destructive mutation with an output schema present, the description covers everything an agent needs: which products qualify, partial-update behavior, the two persistence outcomes, effect on logged rows, undo, and acceptance signaling via data.ok. Return measures need not be re-explained given the output schema.

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 per-field detail is already in the schema (baseline 3). The description adds genuine cross-cutting semantics: any value create_food accepts except 'unit', unspecified fields stay as-is (partial update), and 'servings' replaces the whole list rather than merging. It also confirms food_id's accepted origin.

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+resource (change one of the user's own products) and immediately scopes which products are eligible via create_food's food_id or a get_my_foods hit. It also clarifies which products are refused, distinguishing it from create_food and from generic product lookups without opening either schema.

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?

Gives clear context: only the user's own products (from create_food or get_my_foods) are accepted, others are refused before any change, and it instructs the agent to warn the user when a logged product may shift their logged rows. It also points to update_food with the returned 'previous' to undo. It stops short of an explicit 'use update_food instead of X' routing statement against siblings.

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