This server provides a comprehensive MCP interface to Cronometer, enabling nutrition tracking, diary management, food search, activity logging, and more.
Food Log & Nutrition: Retrieve daily food entries (with nutrient contributions and energy summaries), macro/micronutrient totals, and nutrition scores (category grades and confidence levels).
Food Search & Details: Search Cronometer's food database by name and get detailed nutrition profiles and serving sizes.
Diary Management: Add or remove food entries, create custom foods with specific nutrition data, copy a previous day's entries, and mark days as complete.
Targets & Tracking: Access weekly macro targets and templates, fasting history within a date range, and aggregate fasting statistics.
Activity & Sleep: Log walks, workouts (with calories and steps), and sleep records (including stages and scores).
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@cronometer-api-mcp show my daily nutrition for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Hosted version for Claude.ai, ChatGPT, and Grok coming soon. Join the waitlist →
An MCP (Model Context Protocol) server for Cronometer nutrition tracking, built on the reverse-engineered mobile REST API.
Unlike cronometer-mcp, which takes a comprehensive GWT-RPC approach against Cronometer's web backend, this server talks to the same JSON REST API used by the Cronometer Android app -- with clean payloads and stable, versioned endpoints.
Food log -- diary entries with food names, amounts, meal groups
Nutrition data -- daily macro/micro totals and nutrition scores with per-nutrient confidence
Food search -- search the Cronometer food database, get detailed nutrition info
Diary management -- add/remove entries, copy days, mark days complete
Custom foods -- create foods with custom nutrition data
Macro targets -- read weekly schedule and saved templates
Fasting -- view history and aggregate statistics
Biometrics -- weight, body fat, heart rate, and other tracked metrics over a date range
Activity & sleep -- log walks and workouts, record a night's sleep with its stage breakdown
Related MCP server: nutrition-mcp
curl -LsSf https://astral.sh/uv/install.sh | shexport CRONOMETER_USERNAME="your@email.com"
export CRONOMETER_PASSWORD="your-password"uvx downloads and runs the server on demand -- no separate install step.
opencode.json){
"$schema": "https://opencode.ai/config.json",
"mcp": {
"cronometer": {
"type": "local",
"command": ["uvx", "cronometer-api-mcp"],
"environment": {
"CRONOMETER_USERNAME": "{env:CRONOMETER_USERNAME}",
"CRONOMETER_PASSWORD": "{env:CRONOMETER_PASSWORD}"
},
"enabled": true
}
}
}claude_desktop_config.json){
"mcpServers": {
"cronometer": {
"command": "uvx",
"args": ["cronometer-api-mcp"],
"env": {
"CRONOMETER_USERNAME": "your@email.com",
"CRONOMETER_PASSWORD": "your-password"
}
}
}
}Tool | Description |
| Diary entries for a date, each enriched with food name, source, serving measure/count, and that food's per-entry nutrient contribution, plus an energy_summary (target/consumed/remaining kcal) and a nutrition_summary of consumed totals for every tracked nutrient |
| Consumed macro and micronutrient totals for every nutrient tracked in Cronometer |
| Category scores (Vitamins, Minerals, etc.) with per-nutrient consumed amounts and confidence levels |
Tool | Description |
| Search the Cronometer food database by name |
| Full nutrition profile and serving sizes for a food |
Tool | Description |
| Weekly macro schedule and saved target templates |
| Fasting history within a date range |
| Aggregate fasting statistics |
All date parameters use YYYY-MM-DD format and default to today when omitted.
Tool | Description |
| Log a food serving to the diary |
| Permanently delete diary entries — no undo |
| Create a custom food with specified nutrition |
| Copy all entries from the previous day |
| Mark a diary day as complete or incomplete |
Tool | Description |
| Log a walk or workout — duration, calories burned, optional step count |
| Record a night's sleep, with optional deep/light/REM breakdown and score |
Cronometer stores these in two different places: a walk is an Exercise diary entry, a night's sleep is a Biometric.
Cronometer has no steps field. It is not one of the 54 biometric metrics and
not a field on a diary entry. log_exercise writes the step count into the entry
name, so it is visible in the diary but is text — Cronometer cannot total or
chart it. For step trends, read them from wherever they are actually recorded.
Exercise calories must be net of BMR — Cronometer counts BMR separately, so a
fitness tracker's gross session calories double-count rest. log_exercise takes
the burn three ways, best first:
Argument | Use when | Accuracy |
| copying from a tracker (Fitbit | exact — the server nets it against that day's real BMR |
| you already have a net figure | exact, if your figure is |
neither | you only know the duration | a guess (3.5 METs) |
The response reports calories_source so you can always tell which one ran.
Both tools refuse to write a same-day duplicate unless you pass force=true —
if a device integration already syncs walks or sleep, logging on top of it silently
inflates the day's burn or double-counts a night.
Neither has a delete counterpart. This is deliberate, not an oversight: the only
known deletion endpoint for these entry types removes far more than it is asked to.
Remove an exercise or biometric entry in the Cronometer app instead. See CLAUDE.md
§4.
FORK: hardened fork, read/write. This fork ran read-only through its first eight phases; the owner enabled writes on 2026-07-27. Write tools carry
readOnlyHint: Falseandremove_food_entrycarriesdestructiveHint: True, so clients can warn before mutating. Every tool — read and write — is rate-limited and audited. The biometrics tools (list_biometrics,get_biometrics) were restored in49d1263.log_exerciseandlog_sleepwere added on 2026-08-06, putting the surface at exactly 17 — 10 read, 7 write.tests/test_tool_surface.pypins it in both directions.Date ranges are capped at 90 days per call, calls are rate-limited to 60/hour, and every call is logged (shapes and counts only, never contents). See
CLAUDE.mdfor the constraints,AUDIT.mdfor the upstream security review, andRUNBOOK.mdfor operations.
The server supports remote deployment with OAuth 2.1 authorization (PKCE) for use with Claude.ai and other remote MCP clients.
Variable | Required | Description |
| Yes | Cronometer account email |
| Yes | Cronometer account password |
| No | Transport mode: |
| Remote | HMAC key used to sign and verify access tokens |
| Remote | OAuth client ID, verified at |
| Remote | OAuth client secret, verified at |
| Remote | FORK: required to complete |
| Remote | Public base URL; must match the deployed URL exactly |
| No | FORK: allowed OAuth redirect origins (default |
| No | Listen port for remote transports (default 8000) |
FORK: the four variables marked Remote are mandatory whenever
MCP_TRANSPORTissseorstreamable-http— the server refuses to start without them. Upstream treated them as optional and served the diary unauthenticated when they were absent, so a forgotten secret was a silent downgrade to no authentication at all.
The project includes a Procfile and .python-version for direct deployment with the Heroku Python buildpack:
# Create app
dokku apps:create cronometer-api-mcp
# Set environment
dokku config:set cronometer-api-mcp \
MCP_TRANSPORT=streamable-http \
MCP_AUTH_TOKEN=$(openssl rand -hex 32) \
MCP_OAUTH_CLIENT_ID=my-client \
MCP_OAUTH_CLIENT_SECRET=$(openssl rand -hex 32) \
MCP_BASE_URL=https://your-domain.com \
CRONOMETER_USERNAME=your@email.com \
CRONOMETER_PASSWORD=your-password
# Deploy
git push dokku mainWhen deployed remotely with OAuth configured, connect from Claude.ai using:
Server URL: https://your-domain.com/mcp
OAuth Client ID: Value of MCP_OAUTH_CLIENT_ID
OAuth Client Secret: Value of MCP_OAUTH_CLIENT_SECRET
Claude.ai will open a browser tab for authorization. Click Authorize to complete the connection.
For local development, copy .env.example to .env and fill in your credentials:
cp .env.example .env
# edit .env
uv run cronometer-api-mcpThe CLI auto-loads .env on startup (dev convenience only). Real environment variables always win over .env, so production deployments and MCP client env blocks are unaffected.
This server communicates with mobile.cronometer.com -- the same REST API used by the Cronometer Android/Flutter app. The API was reverse-engineered through:
Static analysis of libapp.so (Dart AOT snapshot) from the APK to discover endpoint names
Traffic interception via Frida + mitmproxy to capture exact request/response formats
Trial-and-error against the live API to confirm payload shapes
The API uses two protocols:
v2 (POST /api/v2/*) -- JSON-body auth, used for most operations (food search, diary read/write, nutrition, fasting, macros, biometrics)
v3 (DELETE /api/v3/user/{id}/*) -- Header-based auth (x-crono-session), used for diary entry deletion
You can use the client directly:
from cronometer_api_mcp.client import CronometerClient
from datetime import date
client = CronometerClient()
# Search for foods
results = client.search_food("chicken breast")
# Get food details
food = client.get_food(results[0]["id"])
# Log a serving
client.add_serving(
food_id=food["id"],
measure_id=food["defaultMeasureId"],
grams=200,
)
# Get today's diary
diary = client.get_diary()
# Get nutrition scores
scores = client.get_nutrition_scores()MIT
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). serving_name: Name for the serving size (default "1 serving"). serving_grams: Weight of one serving in grams (default 100).
| Name | Required | Description | 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 | ||
| saturated_fat_g | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds that it creates a persistent custom food and returns a food_id, which is useful beyond annotations. It does not detail deletion or modification implications, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and important usage note. The parameter list is structured but somewhat lengthy. Nonetheless, every sentence adds value, particularly given the need to compensate for schema deficiencies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all 11 parameters, mentions return value usage, and provides a critical serving size caveat. With an output schema present, missing details like error handling are minor. Mostly complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by detailing each parameter, including units (kcal, g, mg) and defaults (e.g., serving_name default '1 serving'). This adds essential meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it creates a custom food with specified nutrition, distinguishing itself from sibling tools like search_foods and add_food_entry by noting the returned food_id is used with add_food_entry. The verb 'Create' and resource 'custom food' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to create a custom food, and then use add_food_entry to log it. It also notes that nutrient amounts are for the full serving size. However, it does not explicitly state when not to use or list alternative methods for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a food entry to the Cronometer diary.
Use search_foods to find food_id and measure_id, then get_food_details to confirm serving sizes and gram weights.
Args: food_id: Numeric food ID from search_foods results. measure_id: Measure/unit ID from get_food_details. grams: Weight of the serving in grams. date: Date to log as YYYY-MM-DD (defaults to today). translation_id: Translation ID from search results (usually 0). diary_group: LEAVE THIS AS "auto" unless the user explicitly named a meal. Do NOT infer it yourself from the time -- you do not know the user's timezone or which meals their account has, and guessing "snacks" at 11pm has repeatedly filed food under Morning Snacks. On "auto" the server reads the user's local clock and their own configured meals and picks correctly.
Only pass a value when the user said one, e.g. "add it to
lunch". Matching is case-insensitive on a substring of
the account's real meal names; the error lists them.The response includes a logged_to block naming the meal it chose, the local time, and the timezone. Tell the user which meal it went to -- that is how a misfiled entry gets caught immediately rather than days later.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| grams | Yes | ||
| food_id | Yes | ||
| measure_id | Yes | ||
| diary_group | No | auto | |
| translation_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint false). Description adds context: response includes logged_to block, warns about misfiling, and explains diary_group behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and front-loaded, but somewhat lengthy due to detailed parameter docs. Every sentence adds value; conciseness is slightly sacrificed for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters, response handling, prerequisites, and edge cases (e.g., meal guessing). With output schema present and good annotations, description is fully sufficient for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description thoroughly explains all 6 parameters, including defaults, usage, and implications (e.g., diary_group auto behavior, translation_id, date format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Add a food entry to the Cronometer diary' with a specific verb and resource. Distinguishes from sibling tools like search_foods and remove_food_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use search_foods and get_food_details first. Provides detailed guidance on diary_group, warning against inferring meals and explaining when to override default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy all diary entries from the previous day to the given date.
Additive -- does not remove existing entries on the destination date.
Args: date: Destination date as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Additive -- does not remove existing entries on the destination date,' which adds meaningful behavioral context beyond the annotations. The annotations already indicate non-destructive behavior, but the description clarifies the exact merge semantics and what side effects will not occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose, followed by the key additive behavior and a concise parameter explanation. Every sentence conveys essential information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, a clear source/destination model, an additive safety note, and an output schema, the description is complete. An agent has enough information to invoke the tool correctly without additional missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description fully documents the only parameter: date as YYYY-MM-DD with a default of today. It also clarifies that date is the destination date, which adds meaning beyond the raw schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Copy' and the resource 'all diary entries from the previous day' to a specified destination date. This is a specific, unambiguous operation that distinguishes copy_day from the provided siblings, none of which describe copying diary entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the core statement 'Copy all diary entries from the previous day to the given date.' However, the description does not explicitly discuss when to prefer this tool over alternatives or mention any exclusions, so usage guidance is only implicit rather than clearly framed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get daily nutrition summary with consumed macro and micronutrient totals.
Returns the amounts actually consumed for the day, covering every nutrient the user tracks in Cronometer (i.e. has a target set for). The response has:
summary: flat macro totals (energy, protein, carbs, net_carbs, fat, fiber, alcohol). A value is null if that macro isn't tracked.
nutrients: the full list of tracked nutrients, each with id, name, amount, unit, category, and confidence.
A nutrient only appears if it's tracked in Cronometer. To surface e.g. saturated fat, cholesterol, or trans fat, set a target for it in Cronometer and it will flow through automatically.
Args: date: Date as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by explaining that 'only tracked nutrients' appear and that to surface specific nutrients, targets must be set in Cronometer. It also describes the response structure and null values, which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (under 100 words) and well-structured: first sentence states purpose, then breaks down the response, then notes on tracked nutrients, then parameter. No extraneous information, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and presence of an output schema, the description sufficiently explains what the tool returns and the condition for nutrient appearance. It could mention that data is user-specific, but this is implied by the context of the tool suite. Overall, it provides enough context for an agent to decide on usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries the full burden. It provides format ('YYYY-MM-DD') and default behavior ('defaults to today'), adding meaning beyond the schema's bare property definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get daily nutrition summary with consumed macro and micronutrient totals,' specifying the verb ('get') and resource ('daily nutrition summary'). It distinguishes from sibling tools by describing the aggregate nature of the output, such as 'summary: flat macro totals' and 'nutrients: full list of tracked nutrients,' which is distinct from tools like get_food_log or get_nutrition_scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining daily nutrition totals but lacks explicit guidance on when to use versus alternatives. It does not state when not to use or provide comparisons with sibling tools, leaving the agent to infer based on the output described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get fasting history from Cronometer.
Returns fasts within the date range including status, timestamps, and duration.
Args: start_date: Start date as YYYY-MM-DD (defaults to 30 days ago). end_date: End date as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | ||
| start_date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is known. The description adds valuable behavior beyond annotations: returned fields (status, timestamps, duration) and default date behavior (30 days ago to today), which helps the agent understand what a call will produce.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core purpose appears first, then return contents, then parameter details. Every sentence contributes useful information without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, rich annotations, and an output schema present, the description covers the essential call context: what is fetched, the default range, and the date format. Minor details like timezone handling or status enumeration are not specified, but these are not critical given the output schema and the simple read-only nature of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only shows nullable string parameters with null defaults and 0% description coverage. The description compensates by documenting start_date and end_date as YYYY-MM-DD with explicit defaults, giving the agent the format and semantics needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Get fasting history from Cronometer.' It then clarifies exactly what is returned—'fasts within the date range including status, timestamps, and duration'—which distinguishes it from related siblings like get_fasting_stats, add_fast, or delete_fast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a fasting history within a date range is needed, and the date-range context is clear. However, it does not explicitly mention alternatives or when not to use this tool, leaving the agent to infer the boundary against siblings like get_fasting_stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate fasting statistics.
Returns total fasting hours, longest fast, average fast duration, and completed fast count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive, so the description does not need to restate safety. The description adds meaningful behavioral context by specifying that the tool returns computed aggregates rather than raw entry data, which is not captured by the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one clear purpose sentence followed by a line enumerating return values. It is front-loaded with the core action and adds no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only aggregated stats tool with rich annotations and an output schema, the description covers the essential information. It clearly states what the tool does and what it returns, and there are no hidden inputs or side effects an agent would need to know about.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is no parameter semantics burden on the description. The baseline of 4 applies because with no parameters, nothing additional is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves 'aggregate fasting statistics' and enumerates the exact computed metrics returned: total fasting hours, longest fast, average fast duration, and completed fast count. This distinguishes it from the sibling get_fasting_history, which implies raw history rather than summary metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'aggregate' and the list of summary metrics imply this tool is for overview statistics rather than detailed history, but the description does not explicitly mention when to prefer it over get_fasting_history or other fasting-related tools. No alternatives or exclusion criteria are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed food information including nutrition and serving sizes.
Use this after search_foods to get the full nutrient profile and the available serving sizes for a food.
Args: food_id: Food ID from search_foods results.
| Name | Required | Description | Default |
|---|---|---|---|
| food_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, which cover safety and idempotence. The description adds that the tool returns nutrition and serving sizes and that food_id comes from search_foods, but does not disclose additional behavioral details such as the response structure or how it handles missing data. With rich annotations, the description's incremental value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an args section) and well-structured, with each sentence serving a purpose. It front-loads the core action and returns information, then provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are already defined), the simple one-parameter tool is fully described. The description covers the tool's purpose, parameter origin, and integration with sibling tools, meeting all needs for a complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that food_id is 'Food ID from search_foods results', which adds critical context beyond the schema's type and title. This effectively guides the agent in providing the correct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed food information including nutrition and serving sizes. It distinguishes from siblings like search_foods (which provides basic info) and get_food_log (which returns logged entries), making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool after search_foods to obtain full nutrient profiles and serving sizes, providing clear usage context and sequence. It effectively guides the agent on when to apply the tool relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all diary entries for a given date.
Returns every food entry logged for the day. Each "Serving" entry is enriched (best-effort) with the food's name, source, the serving measure (unit name and grams per unit), the number of servings, and that food's own nutrient profile scaled to the amount eaten. Non-food entries (exercise, biometrics) carry their own name.
Note: the per-entry "nutrients" are each food's individual contribution, which is distinct from the day-level nutrition_summary aggregate below.
Also returns a top-level energy_summary field with pre-computed values most relevant to the user:
total_target_kcal: daily calorie target dynamically adjusted for expenditure and weight goal (equivalent to Cronometer's "Total Target" in the Energy Summary screen)
consumed_kcal: total calories consumed
remaining_kcal: calories remaining to stay on target (total_target_kcal - consumed_kcal). Always report this when summarizing the user's day. Prefer this over manually deriving values from the burn breakdown fields.
Also returns a nutrition_summary field with consumed totals for every nutrient the user tracks in Cronometer (macros plus any tracked micronutrients such as saturated fat, cholesterol, or omega-3/6):
macros: flat macro totals (energy, protein, carbs, net_carbs, fat, fiber, alcohol)
nutrients: the full list of tracked nutrients with amounts and units
Args: date: Date as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds significant behavioral context beyond annotations: it details the enrichment process, the structure of entries, the difference between per-entry and aggregate nutrients, and the exact fields in energy_summary and nutrition_summary. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized, well-structured, and front-loaded with the core purpose. Every sentence adds value: it explains what is returned, how entries are enriched, the nutrient distinction, and details the summary fields with bullet points. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, comprehensive annotations, and an output schema, the description provides complete context. It fully explains the return structure and the meaning of fields, leaving no ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the single parameter 'date'. The description adds full semantics: 'Date as YYYY-MM-DD (defaults to today).' This compensates completely for the lack of schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all diary entries for a given date' and elaborates on what is returned (enriched servings, non-food entries, and summaries). It distinguishes this tool from siblings like get_daily_nutrition by explaining the per-entry vs aggregate distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool (to retrieve diary entries for a date) and gives guidance on preferring the energy_summary fields over manual calculations. However, it does not explicitly state when not to use this tool or compare it to siblings like get_daily_nutrition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current macro targets including weekly schedule and templates.
Returns the weekly macro schedule (which template applies to each day) and all saved macro target templates with their values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context by explaining that the result includes the per-day template mapping and all saved templates with their values, which clarifies what 'macro targets' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main purpose is front-loaded and the second sentence expands the meaning of 'weekly schedule and templates' without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema, rich read-only annotations, and presence of an output schema, the description provides all essential context. It clearly states what the tool returns, making it complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema fully documents the calling contract. The description correctly implies no arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('current macro targets'), and the precise scope ('weekly schedule and templates'). It also distinguishes the tool from the ambiguous sibling 'get_targets' by naming the macro-specific contents returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this is the tool to call when the agent needs the current weekly macro schedule or saved macro target templates. It does not explicitly name alternatives or exclusions, but with zero parameters and such specific return content, the usage context is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get nutrition scores with per-nutrient consumed amounts and category grades.
Returns category scores (All Targets, Vitamins, Minerals, Electrolytes, Antioxidants, Immune Support, Metabolism, Bone Health) with the actual consumed amount and confidence level for each tracked nutrient.
This is the richest nutrition endpoint -- use it when you need to know both how much of each nutrient was consumed AND how close each is to the target.
Args: date: Date as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by detailing the return structure: category scores, consumed amounts, confidence levels, and default date behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is informative. The first sentence captures the core purpose. The second elaborates on return structure. The third provides usage guidance. There is no fluff or repetition, and it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return content (categories, amounts, confidence) and date parameter behavior. With an output schema present, it does not need to detail every field. It is complete for understanding what the tool does and its main input. Minor gap: no mention of error conditions or timezone, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'date' is described with format YYYY-MM-DD and default behavior (defaults to today). This adds meaning beyond the input schema, which only specifies string|null with no format or default. Schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves nutrition scores with per-nutrient consumed amounts and category grades. It explicitly distinguishes itself from siblings by calling it 'the richest nutrition endpoint' and contrasting with simpler endpoints like get_daily_nutrition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: 'when you need to know both how much of each nutrient was consumed AND how close each is to the target.' Does not explicitly mention when not to use or name alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a diary day as complete or incomplete.
Args: date: Date to mark as YYYY-MM-DD. complete: True to mark complete, False for incomplete.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| complete | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the core mutation (marking a day complete or incomplete), which aligns with the annotations readOnlyHint=false and destructiveHint=false. It does not add richer behavioral context such as side effects on streaks or handling of non-existent days, but the annotations already provide idempotency and destructiveness safety, lowering the burden on the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences followed by a structured Args block. The purpose is front-loaded, and there is no filler or redundant explanation. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation, the description covers the operation and all parameter meanings. The output schema and annotations cover return values and safety characteristics. It stops short of a 5 by leaving edge-case behavior (e.g., what happens if the day does not exist) unmentioned, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and a default, with zero parameter descriptions. The description's Args block compensates fully by specifying the exact date format 'YYYY-MM-DD' and the boolean mapping 'True to mark complete, False for incomplete'. This gives an agent everything needed to set each parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('mark') and resource ('diary day') with the two possible states 'complete or incomplete'. It is clearly distinguishable from all sibling tools, which deal with foods, biometrics, exercises, and fasting rather than diary completion status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever a diary day's completion status needs to be set. It does not explicitly name alternatives or exclusions, but no sibling tool appears to overlap this functionality, so explicit routing is unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove one or more food entries from the Cronometer diary.
Use get_food_log to find entry IDs.
Args: entry_ids: List of serving/entry IDs to remove. date: Date the entries belong to as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| entry_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already carry the key behavioral hints: destructiveHint=true, readOnlyHint=false, and idempotentHint=true. The description adds the target ('Cronometer diary') and the 'one or more' batch capability, but it does not disclose potential side effects, failure semantics, or irreversibility beyond what 'Remove' and the destructve annotation imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the purpose, followed by a short prerequisite and an Args list. Every sentence contributes necessary information and there is no filler or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two simple parameters, an output schema, and annotations covering destructive/idempotent behavior, the description is complete: it states what is removed, how to find valid IDs, and how to specify the date. No critical information needed to invoke the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining both parameters: entry_ids is 'List of serving/entry IDs to remove,' and date is 'YYYY-MM-DD (defaults to today).' It adds format and default semantics that the input schema, which only declares 'string or null', does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Remove one or more food entries from the Cronometer diary.' This clearly distinguishes it from sibling tools like edit_food_entry or add_food_entry by naming the removal operation and the target (diary entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit prerequisite guidance: 'Use get_food_log to find entry IDs,' which tells the agent how to obtain the required parameter. However, it does not explicitly state when not to use this tool or compare it to alternatives such as edit_food_entry, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Cronometer's food database by name.
Returns matching foods with their IDs and source information. Pass a food_id to get_food_details for full nutrition info.
Args: query: Food name or keyword (e.g. "eggs", "chicken breast").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that it returns matching foods with IDs and source information, and includes the query parameter usage, which provides behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences and a docstring section. Every sentence adds value: purpose, outcome, and usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, single parameter, and comprehensive annotations, the description is complete. It explains what the tool returns, how to use it, and what to do with the results (pass to get_food_details).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description includes a detailed parameter docstring with examples ('e.g. "eggs", "chicken breast"'), adding significant meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Cronometer's food database by name.' with a specific verb and resource. It also distinguishes from sibling tool get_food_details by explaining the workflow: search then pass food_id to get_food_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains the tool's purpose and links to get_food_details for full nutrition info, providing an implicit usage context. However, it does not explicitly state when not to use this tool or compare to other search or logging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_custom_foodadd_food_entrycopy_dayget_daily_nutritionget_fasting_historyget_fasting_statsget_food_detailsget_food_logget_macro_targetsget_nutrition_scoresmark_day_completeremove_food_entrysearch_foodsScored across 13 tools
Tools have distinct primary purposes, but get_food_log, get_daily_nutrition, and get_nutrition_scores provide overlapping nutrition data at different granularities. Descriptions help differentiate, but an agent might still be confused about which to use for a specific need.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., get_macro_targets, search_foods, add_food_entry). The naming is predictable and clear.
With 13 tools, the surface is well-scoped for a nutrition tracking API. Each tool serves a clear function without unnecessary duplication, covering targets, logging, food management, and fasting.
Core CRUD operations are covered (search, add, remove, custom food creation). Day management (copy, mark complete) and multiple read endpoints exist. Missing is an update/editing capability for diary entries, but removal and re-addition can compensate.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
MCP server exposing supplements database used by iNutriPlan.com