Cronometer MCP

update_custom_food

Idempotent

Fix a custom food without re-logging: edit its name, notes, nutrients, or serving measures in place while existing diary entries stay attached.

Instructions

Edit one of your custom foods in place, keeping its diary entries.

Only what you pass changes. Entries already logged stay attached to this same food and their nutrition follows the edit, so a typo or a wrong nutrient can be fixed without re-logging anything.

Nutrients are merged into the existing profile, so correcting one value leaves the rest alone. Call list_nutrients for the accepted names.

Amounts are for one serving, the same basis get_food_details reports and returns as serving_grams. That is the food's default measure, which is not always 100 g: a juice measured in millilitres takes per-millilitre values. Read the food first and the two always agree.

Args: food_id: The custom food to edit. name: New name. notes: New note text. nutrients: Nutrient name to amount per serving, merged in. measures: [{"measure_id": int, "name": str, "grams": float}] to fix a wrongly weighted measure. name and grams are each optional. Leave measure_id out to ADD a serving size instead, giving name and grams: that is how a food gets a per-piece measure such as "1 karkki" or "1 viipale" alongside plain grams, so it can be logged by the count as well as by weight.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "food_id": "<food_id>"
    },
    "name": "update_custom_food"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`notes`	No
`food_id`	Yes
`measures`	No
`nutrients`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.1.0Nov 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond the annotations (which only give readOnly=false, idempotent=true, destructive=false) by disclosing partial-update semantics ('Only what you pass changes'), merge-not-replace behavior for nutrients, that diary entries remain attached, and the add-vs-edit behavior of measures. This is exactly the consequence-level detail an agent needs for a mutation tool.

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-loads the core mutation semantics before the Args block, and each sentence carries information. It is somewhat long with the measures explanation spanning several lines, but no sentence is filler, so it stays readable.

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?

An output schema exists, so return values need not be described; the description instead covers everything an agent needs to invoke correctly — mutation scope, unit basis tied to get_food_details, merge semantics, and full param edge cases. Nothing material is missing.

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?

Schema description coverage is 0%, so the description carries the full burden and it does: every one of the 5 params is explained, including the subtle case of omitting measure_id to ADD a serving size, the per-piece measure pattern, and the per-serving unit basis. Far above the baseline for a zero-coverage schema.

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?

Specific verb+resource ('Edit one of your custom foods in place, keeping its diary entries') that immediately distinguishes it from add_custom_food, retire_custom_food and edit_food_entry by stating the in-place semantics. An agent can tell exactly which sibling to pick 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 Guidelines4/5

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

Gives clear context for use ('a typo or a wrong nutrient can be fixed without re-logging anything') and points to a prerequisite ('Call list_nutrients for the accepted names'; 'Read the food first'). It does not explicitly exclude or route against the nearest alternatives like edit_food_entry or add_custom_food, so it stops short of a 5.

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

Deploy Server