io.github.rwestergren/cronometer-api-mcp

add_custom_food

Create a custom food in Cronometer with your own calorie, macro, and nutrient values, and get a food ID to log it in your diary.

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).

Input Schema

TableJSON Schema

Name	Required	Default
`name`	Yes
`fat_g`	Yes
`carbs_g`	Yes
`fiber_g`	No
`sugar_g`	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.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.4/5.0

Behavior4/5

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

Beyond the annotations (write operation, not idempotent), the description warns that nutrient IDs in extra_nutrients are not validated and must not duplicate macro IDs, and clarifies that nutrient amounts are for the full serving. This materially reduces the chance of misuse, although it does not discuss auth or failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and serving-size rule, then uses a tidy Args block to document all 12 parameters. No sentences are wasted; the extra_nutrients caveat is long but necessary.

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 12-parameter creation tool with no parameter descriptions in the schema, the description covers every arg, the intended follow-up workflow, the source for nutrient IDs, and a key correctness warning. The output schema exists, so return-value details need not be repeated.

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?

Since the schema has 0% description coverage, the Args section carries the full burden and does so completely: every parameter is listed with units, defaults, and the special extra_nutrients keying semantics. It adds meaning well beyond the bare schema titles.

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?

The description opens with a specific action and resource: 'Create a custom food in Cronometer with specified nutrition.' It clearly centers on creating a reusable food object, distinct from logging entries or recipes, and reinforces the purpose by explaining the follow-up with add_food_entry.

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?

The description gives a clear workflow clue—'After creation, use the returned food_id with add_food_entry to log it'—but it does not explicitly state when to prefer this tool over sibling alternatives like add_recipe, import_recipe, or search_foods. Usage context is implied by the name and first line rather than spelled out.

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