Cronometer MCP

remove_food_entry

DestructiveIdempotent

Delete Cronometer diary entries (foods, exercise, biometrics, notes) by entry ID and date; use get_food_log to find IDs. Deletion is permanent.

Instructions

Remove diary entries of any kind: foods, exercise, biometrics, notes.

Use get_food_log to find entry IDs (servingId, exerciseId, biometricId or noteId). Deleting cannot be undone.

Args: entry_ids: List of entry IDs to remove. date: Date the entries belong to as YYYY-MM-DD (defaults to today).

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": {
      "entry_ids": "<entry_ids>"
    },
    "name": "remove_food_entry"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No
`entry_ids`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.1.0Nov 14, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description's 'Deleting cannot be undone' largely restates destructiveHint, though the mapping of entry kind to ID field name (servingId, exerciseId, biometricId, noteId) is genuinely additive. It says nothing about partial failures, cascading effects, or what happens when an ID does not exist.

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?

Three short blocks: purpose and scope, prerequisite lookup plus irreversibility warning, then a compact Args list. The destructive warning is placed before the parameter list, so the risk is front-loaded and every sentence carries information.

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

Completeness4/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 no explanation, and the description covers scope, ID sourcing, date format, and irreversibility. What remains thin is error behavior—invalid or already-deleted IDs, and whether one bad ID aborts the whole batch—which matters for a destructive batch operation.

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?

Schema description coverage is 0%, so the description must carry the load, and it mostly does: entry_ids is explained as the list of IDs obtained from get_food_log, and date is given an explicit YYYY-MM-DD format plus a 'defaults to today' semantics that the schema (default null) does not convey. It does not clarify whether date must match the entry's own date or what happens on a mismatch.

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 verb and resource ('Remove diary entries') and immediately scopes it to all entry kinds (foods, exercise, biometrics, notes), which lets an agent distinguish it from the narrower siblings remove_biometric, remove_exercise, and remove_note.

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?

It gives a clear prerequisite workflow: call get_food_log first to obtain entry IDs, and names the four ID flavors. It does not, however, say when to prefer this general remover over the type-specific siblings, so the alternative selection is left to inference.

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

Deploy Server