Cronometer MCP

add_repeat_item

Idempotent

Automates recurring food logging in Cronometer by adding a chosen food to specific days of the week, so you can set repeat meals without manual entry.

Instructions

Make a food log itself automatically on chosen days of the week.

Give food_id (from search_foods) and optionally measure_id; without a measure the food's default serving is used. Or give only food_name and the best search match is used: its name is echoed back, so check it.

Args: quantity: How many of the measure, e.g. 1 for one medium banana. food_id: From search_foods. measure_id: A measure of that food, from get_food_details. food_name: Search text, when food_id is not known. days: "all", "weekdays", "weekends", or e.g. "Mon,Wed,Fri". diary_group: Meal to log into, e.g. "Breakfast" (defaults by time of day).

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": {
      "quantity": "<quantity>"
    },
    "name": "add_repeat_item"
  }
}

Input Schema

Name	Required	Default
`days`	No	all
`food_id`	No
`quantity`	Yes
`food_name`	No
`measure_id`	No
`diary_group`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.1.0Nov 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare a non-destructive, idempotent, open-world write, so the baseline is low. The description adds genuinely useful behavior beyond that: the food's default serving is used when no measure is supplied, diary_group defaults by time of day, and the resolved food name is echoed back so the caller should verify the match — a real caution against silent mis-selection.

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 in the first sentence, followed by a compact Args block that maps one line per parameter. Slightly awkward phrasing ("Make a food log itself automatically") and hard line wraps cost a little, but no sentence is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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 spelled out, and the fallback/default behavior is covered. What is missing for a mutating recurrence tool is lifecycle context: whether calling it twice creates two schedules, whether it replaces an existing repeat item, and how to remove one — leaving the agent to guess at side effects.

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?

With 0% schema description coverage, the description carries the full burden and mostly delivers: it defines quantity, food_id, measure_id, food_name, days, and diary_group, and it supplies the accepted days vocabulary ("all", "weekdays", "weekends", "Mon,Wed,Fri") that the schema lacks as an enum. Minor gaps remain, e.g. the valid diary_group values are only shown by one example.

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?

"Make a food log itself automatically on chosen days of the week" states a specific action and effect: it creates a recurring/auto-logging food entry. The resource and the recurring nature are clear enough to separate it from a one-off food entry, though it never names a sibling such as add_food_entry or delete_repeat_item to sharpen the boundary.

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 usefully explains two paths for identifying the food (food_id from search_foods, or food_name as a search phrase) and where measure_id comes from, which is real selection guidance. However, it gives no tool-level guidance about when to use this versus a single-entry add or how to undo it (delete_repeat_item is never mentioned), so usage is implied rather than stated.

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

Deploy Server