io.github.rwestergren/cronometer-api-mcp

update_custom_food

DestructiveIdempotent

Edit an existing custom food you created by changing only the nutrients, serving details, or barcodes you provide; diary entries using it adopt the updated values.

Instructions

Edit an existing custom food (one you created) in place.

Only the arguments you pass change; everything else keeps its current value. Find the food_id with search_foods (source "Custom") or get_food_details. Diary entries that already use the food pick up the new values. Recipes cannot be edited with this tool, even though they also show as source "Custom".

Nutrient amounts are per serving: the food's default serving, or serving_grams when you pass it. To change the serving weight without re-entering nutrition, pass serving_grams alone; the stored per-100g values stay put, so the per-serving numbers scale with the new weight.

Args: food_id: ID of the custom food to edit. name: New food name. calories: Calories per serving (kcal). protein_g: Protein per serving (g). fat_g: Fat per serving (g). carbs_g: Carbs per serving (g). fiber_g: Fiber per serving (g). sugar_g: Sugar per serving (g). sodium_mg: Sodium per serving (mg). saturated_fat_g: Saturated fat per serving (g). extra_nutrients: Additional nutrients keyed by Cronometer nutrient ID (from get_daily_nutrition) and valued per serving; must not reuse an ID the named args already cover. serving_name: New name for the default serving. The app shows the serving as " "; a leading number ("2 cookies") is taken as the quantity (see serving_quantity). serving_grams: New total weight of the default serving in grams. Also resets the quantity to serving_quantity (or 1). serving_quantity: How many units make up the default serving (default 1 whenever serving_grams is passed). Without serving_grams the serving's total weight stays the same, so each unit gets lighter or heavier: changing "2 cookies = 30 g" to 3 gives "3 cookies = 30 g". To keep the per-unit weight, also pass serving_grams (45 here). Check the result with get_food_details, which lists each measure's quantity. barcodes: Replaces the food's barcodes (see add_custom_food for the accepted formats); pass [] to remove them all. To add one, pass the current barcodes from get_food_details plus the new one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No
`fat_g`	No
`carbs_g`	No
`fiber_g`	No
`food_id`	Yes
`sugar_g`	No
`barcodes`	No
`calories`	No
`protein_g`	No
`sodium_mg`	No
`serving_name`	No
`serving_grams`	No
`extra_nutrients`	No
`saturated_fat_g`	No
`serving_quantity`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.6Oct 15, 2026

addedInput schema / properties / barcodes

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Barcodes"
+}

addedInput schema / properties / serving_quantity

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Serving Quantity"
+}

Addedv0.2.4Sep 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing patch semantics ('only the arguments you pass change'), cross-entity side effects ('diary entries that already use the food pick up the new values'), replacement semantics for barcodes, and the subtle scaling rule that per-100g storage stays fixed while per-serving values scale with serving_grams.

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 purpose and mutation semantics, then a clean Args block; nearly every sentence earns its place given the subtle serving_quantity arithmetic. It is long, and the serving_quantity explanation could be tightened, but the length is driven by genuine ambiguity in the parameters rather than padding.

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 15-parameter mutation tool, nothing essential is missing: identity lookup, patch behavior, side effects on diary entries and recipes, unit semantics, and a verification path (get_food_details) are all covered. Return values need no explanation since an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage across 15 parameters, the description carries the full burden and delivers: it defines per-serving units, the extra_nutrients key source and its collision rule with named args, the serving_grams/serving_quantity interaction with a concrete worked example, and the barcodes replace-not-append rule with [] to clear.

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 ('Edit an existing custom food (one you created) in place') and immediately bounds what the tool does not cover (recipes, despite sharing source 'Custom'). An agent can distinguish it from add_custom_food and delete_custom_food without opening any schema.

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 routes the agent to search_foods (source "Custom") or get_food_details to obtain the required food_id, and names an exclusion case (recipes cannot be edited here). It tells the agent how to enter the tool and how to verify the result, not just what it does.

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