io.github.rwestergren/cronometer-api-mcp

add_custom_food

Create a custom food in Cronometer with specified nutrition and serving details, then log it as a food entry using the returned food_id.

Instructions

Create a custom food in Cronometer with specified nutrition.

Nutrient amounts should be for the full serving size specified. After creation, use the returned food_id with add_food_entry to log it.

Args: name: 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, default 0). sugar_g: Sugar per serving (g, default 0). sodium_mg: Sodium per serving (mg, default 0). saturated_fat_g: Saturated fat per serving (g, default 0). extra_nutrients: Additional nutrients beyond the core macros above (vitamins, minerals, amino acids, etc.), keyed by Cronometer nutrient ID (from get_daily_nutrition, which pairs each id with its name) and valued per the full serving. IDs aren't validated, so a wrong one writes the wrong nutrient; must not reuse an ID the named macro args already cover. serving_name: Name for the serving size (default "1 serving"). serving_grams: Weight of one serving in grams (default 100). barcodes: Product barcodes (EAN-13, UPC-A, EAN-8, UPC-E or GTIN-14), e.g. the digits printed under the bars on the package; spaces and dashes are ignored. Scanning one of them in the Cronometer app then finds this food (search_foods does not match barcodes). The check digit is verified, so a misread digit is rejected rather than saved.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	Yes
`fat_g`	Yes
`carbs_g`	Yes
`fiber_g`	No
`sugar_g`	No
`barcodes`	No
`calories`	Yes
`protein_g`	Yes
`sodium_mg`	No
`serving_name`	No	1 serving
`serving_grams`	No
`extra_nutrients`	No
`saturated_fat_g`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.2.6Oct 15, 2026

addedInput schema / properties / barcodes

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

Changed1 schema field changedv0.2.3Sep 8, 2026

addedInput schema / properties / extra_nutrients

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "number"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Extra Nutrients"
+}

First observedv0.1.0Jul 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations cover the safety profile (write, non-idempotent, non-destructive, open-world), and the description adds substantial behavior beyond them: extra_nutrients IDs are unvalidated so a wrong ID silently writes the wrong nutrient, IDs must not collide with the named macro args, barcode check digits are verified so misreads are rejected, and search_foods does not match barcodes. These are real failure modes and validation semantics an agent could not infer from structured fields.

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?

Purpose is front-loaded, followed by the serving-size constraint and workflow note, then a well-organized Args block. It is long, but with 0% schema coverage the per-parameter prose is necessary rather than filler; only the barcodes paragraph runs slightly long.

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 mutation tool with an output schema present, the description supplies everything the agent needs: complete parameter semantics, the per-serving convention, the follow-up logging step, and the non-obvious validation pitfalls. Return-format detail is rightly omitted 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?

Schema description coverage is 0%, so the description carries the full burden and does so: it documents all 13 parameters with units (kcal, g, mg), defaults, the per-serving basis, the serving_name/serving_grams meaning, the barcode format list, and the keying/validation rules for the nested extra_nutrients map. This is exactly the compensation the low coverage demands.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Create a custom food in Cronometer with specified nutrition.' This clearly separates it from update_custom_food and delete_custom_food by the create semantics. It doesn't explicitly name the sibling it is not, so it falls just short of the 5 benchmark.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

It provides post-creation workflow guidance ('use the returned food_id with add_food_entry to log it'), which is genuinely useful cross-tool routing. However, it never states when to reach for this tool versus add_recipe, import_recipe, or search_foods, so the when-to-use condition is only implied.

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