Cronometer MCP

add_exercise

Idempotent

Log an exercise entry with name, duration, and calories burned to a Cronometer diary. Use it to record workouts, then edit or remove entries if corrections are needed.

Instructions

Log an exercise entry.

A wrong entry can be corrected with edit_exercise or deleted outright with remove_exercise.

Args: name: What the exercise was called. minutes: Duration in minutes. calories_burned: Calories burned, as a positive number. date: Date as YYYY-MM-DD (defaults to today). activity_id: Optional Cronometer activity, from search_activities. Leave 0 for a free-form entry named name.

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": {
      "name": "<name>",
      "minutes": "<minutes>",
      "calories_burned": "<calories_burned>"
    },
    "name": "add_exercise"
  }
}

Input Schema

Name	Required	Description	Default
`date`	No
`name`	Yes
`minutes`	Yes
`activity_id`	No
`calories_burned`	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.4/5.0

Behavior4/5

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

Annotations already declare non-readonly, open-world, non-destructive, idempotent behavior, so the bar is lower; the description still adds useful error-recovery context (a bad entry is fixable or removable) and clarifies that activity_id=0 creates a free-form entry rather than linking a catalog activity. It says nothing about duplicate entries despite the idempotentHint=true annotation, which an agent could misread.

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?

The purpose is front-loaded in the first line with the recovery path immediately after, then a compact Args block. The structured list is readable and earns its space, though the multi-line prose wrapping adds minor visual noise.

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 not be described, and all inputs plus the correction workflow are covered. The only shortfall is that a write tool whose annotations claim idempotency does not explain how repeated calls behave, which an agent would want to know before logging.

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 must carry the burden and does: every one of the five parameters is explained, including units (minutes), sign convention (calories as a positive number), date format with a today default, and the meaning of the 0 sentinel for activity_id plus where a real value comes from.

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 opening line states a specific verb and resource ("Log an exercise entry") and the following sentence names the sibling tools (edit_exercise, remove_exercise) that handle adjacent operations, so an agent can place this tool precisely in the CRUD set without comparing schemas.

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 clear routing: use edit_exercise to fix a wrong entry, remove_exercise to delete one, and search_activities to obtain an activity_id. It does not state prerequisites or clarify when to log a free-form entry versus a known Cronometer activity beyond the parameter note.

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

Deploy Server