Click on "Install 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 log 200g chicken breast for dinner 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
Related MCP server: nutrition-mcp-server
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 with food names, amounts, and meal groups, 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 |
| Log a food serving to the diary |
| Remove one or more diary entries |
| Create a custom food with specified nutrition |
| Copy all entries from the previous day |
| Mark a diary day as complete or incomplete |
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.
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: |
| No | Bearer token for remote auth (enables OAuth flow) |
| No | OAuth client ID for remote clients |
| No | OAuth client secret for remote clients |
| No | Public base URL for OAuth metadata endpoints |
| No | Listen port for remote transports (default 8000) |
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)
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 | ||
| calories | Yes | ||
| protein_g | Yes | ||
| fat_g | Yes | ||
| carbs_g | Yes | ||
| fiber_g | No | ||
| sugar_g | No | ||
| sodium_mg | No | ||
| saturated_fat_g | No | ||
| serving_name | No | 1 serving | |
| serving_grams | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true. The description adds context about nutrient amounts per serving and the return value usage, but does not disclose potential side effects (e.g., duplicate name handling) or error conditions.
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, front-loaded with the purpose, and organized into a brief paragraph followed by a clear 'Args:' list. Every sentence adds value with no unnecessary text.
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 complexity (11 parameters, output schema exists), the description covers the main workflow, parameter details, and return value usage. Omits error handling or validation details, but is adequate for the tool's straightforward purpose.
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 description coverage, the description fully compensates by listing each parameter with a clear explanation, including units (g, mg, kcal) and defaults for optional ones. Adds contextual hint that amounts are for the full serving size.
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 action ('Create a custom food') and the resource ('in Cronometer with specified nutrition'). It distinguishes from sibling tools like add_food_entry (logging) and search_foods (searching).
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 the returned food_id with add_food_entry, providing a clear workflow. Implicitly differentiates from alternatives, but does not explicitly state when not to use this tool.
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: Meal slot -- one of "auto", "breakfast", "lunch", "dinner", "snacks" (case-insensitive, default "auto").
| Name | Required | Description | Default |
|---|---|---|---|
| food_id | Yes | ||
| measure_id | Yes | ||
| grams | Yes | ||
| date | No | ||
| translation_id | No | ||
| diary_group | No | auto |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral details like case-insensitivity for diary_group and default values, but does not elaborate on side effects beyond what is implied by 'add.' No contradiction with 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 appropriately sized: a single sentence for purpose, followed by a usage hint, then a clear bullet list of parameters. Every sentence provides value, and the structure is front-loaded with the main action.
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 6 parameters, annotations, and an output schema, the description covers all necessary context: purpose, prerequisite tools, parameter explanations, and defaults. The output schema exists, so return values are not needed in the description.
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 description coverage, the description fully compensates by explaining each parameter: food_id from search_foods, measure_id from get_food_details, grams as weight, date format, translation_id default 0, and diary_group possible values. This adds substantial meaning beyond the raw schema.
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 'Add a food entry to the Cronometer diary,' using a specific verb and resource. It distinguishes the tool from siblings like search_foods and remove_food_entry, making the purpose unambiguous.
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 advises using search_foods and get_food_details as prerequisites, providing clear context and guidance on when to use this tool. It also explains default behaviors for parameters.
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?
Discloses additive, non-destructive nature. Annotations are consistent and description adds context beyond them. Could mention what happens if no entries exist or return format.
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?
Extremely concise: three sentences total, front-loaded with the key behavior, 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?
Covers core behavior well for a simple tool with one optional parameter and an output schema. Lacks mention of error conditions or return value specifics.
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?
Explicitly describes the date parameter format (YYYY-MM-DD) and default value (today), adding semantic 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?
Clearly states the action (copy), source (previous day), and destination (given date). Distinguishes from sibling tools like add_food_entry or mark_day_complete.
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?
Implies when to use (copying previous day's entries), but lacks explicit guidance on alternatives or when not to use. Does not mention moving vs copying or other scenarios.
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 indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying that returned macro values are null if untracked, that nutrients only appear if targets are set, and that the response includes confidence levels. No contradictions with 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 well-structured with a clear opening sentence, bullet-point explanation of the response, and a concise Args section. Every sentence adds value 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 simplicity of the tool (one optional parameter) and the presence of an output schema (though not shown), the description fully explains the response structure, default behavior, and conditions for data inclusion. It is complete for effective use.
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 only one parameter, 'date', with no description. The description adds the format 'YYYY-MM-DD' and explains that it defaults to today, which is meaningful beyond the schema's default null. This compensates for the 0% schema coverage.
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 it returns a daily nutrition summary with consumed macro and micronutrient totals. It explicitly mentions that it covers every nutrient the user tracks in Cronometer, differentiating it from sibling tools like get_macro_targets or get_food_log which serve different purposes.
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 explains that nutrients appear only if tracked in Cronometer, but it does not explicitly state when to use this tool versus alternatives like get_food_log or get_nutrition_scores. The usage context is implied but not contrasted with siblings, lacking explicit 'when' and 'when not' guidance.
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 |
|---|---|---|---|
| start_date | No | ||
| end_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, idempotentHint=true, etc., so the description adds minimal behavioral context. It mentions returned fields (status, timestamps, duration) but does not elaborate on other behaviors like error handling or data freshness.
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 with only four sentences. It front-loads the purpose and return fields, then lists parameters. No extraneous 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?
Given the presence of an output schema and annotations, the description covers the essential aspects. It could mention behavior on empty results or date range limits, but it is largely complete for a simple read operation.
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 coverage is 0%, so the description fully explains both parameters: format (YYYY-MM-DD) and defaults (30 days ago, today). This adds significant meaning beyond the schema's type and default null.
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 it gets fasting history from Cronometer, including returned fields. However, it does not distinguish from the sibling tool `get_fasting_stats`, which might have overlapping functionality.
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?
No explicit guidance on when to use this tool versus alternatives like `get_fasting_stats`. The description only states what it does, not when it is appropriate or when not to use it.
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 readOnly, idempotent, and non-destructive hints. The description adds value by specifying the exact return fields (total hours, longest fast, average duration, completed count), which goes beyond what annotations provide. No contradictions found.
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 consists of two concise sentences with no redundancy. It front-loads the purpose and lists the return values efficiently.
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 no parameters, comprehensive annotations, and an output schema for return values, the description covers all necessary information. It is complete for an agent to understand and use the tool 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?
No parameters exist, so baseline is 4. The description does not need to add parameter-level information, and it correctly omits irrelevant details.
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 'Get' and specifies 'aggregate fasting statistics,' which distinguishes it from sibling tools like 'get_fasting_history' that likely return per-day data. The listed return fields further clarify its purpose.
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?
No explicit when-to-use or when-not-to-use guidance is provided. However, the description implicitly suggests it is for aggregate stats as opposed to history, and the annotations indicate it is a safe read operation, which partially covers usage context.
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 available measure_ids needed for add_food_entry.
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=true and idempotentHint=true, so the description doesn't need to restate safety. It adds value by specifying that the tool returns 'full nutrient profile and available measure_ids', which is beyond the annotation scope.
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?
Three short, front-loaded sentences: first states purpose, second gives usage context, third documents the parameter. 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 presence of an output schema, the description doesn't need to detail return structure. It covers purpose, usage, and parameter sourcing. Could optionally mention that results are read-only, but annotations already convey that.
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?
Despite 0% schema coverage, the description explains that 'food_id' comes from 'search_foods results', which gives critical context for how to obtain the parameter value. This is sufficient for proper invocation.
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 'Get' and the resource 'detailed food information including nutrition and serving sizes', distinguishing it from siblings like search_foods (which lists foods) and add_food_entry (which adds 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?
It explicitly says 'Use this after search_foods' and 'needed for add_food_entry', providing both temporal context and the downstream purpose. This tells the agent exactly when and why to use this tool.
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, including food names, amounts, meal groups, and nutrient data.
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?
The description significantly expands on annotations, detailing the `energy_summary` and `nutrition_summary` fields, including specific field meanings and usage instructions (e.g., 'Always report this when summarizing'). No contradictions with annotations (readOnlyHint, idempotentHint).
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 well-structured and concise, front-loading the main purpose and using bullet points for details. Every sentence adds value 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?
The tool has a single optional parameter and an output schema; the description thoroughly explains the return fields (`energy_summary`, `nutrition_summary`) and offers usage guidance, leaving no significant gaps for an agent to invoke it 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?
With 0% schema coverage, the description compensates by specifying the date parameter format (`YYYY-MM-DD`) and default behavior (`defaults to today`), adding meaningful context beyond the schema's minimal 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 tool retrieves all diary entries for a given date, specifying the data returned including food names, amounts, meal groups, and nutrient data. It distinguishes itself from siblings like `get_daily_nutrition` and `get_food_details` by focusing on daily 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 implies use for viewing daily logs, with explicit guidance on preferring `remaining_kcal` over manual derivation. However, it does not explicitly exclude scenarios or compare to alternatives like `add_food_entry` or `search_foods`.
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 declare readOnly, non-destructive, idempotent. The description adds value by detailing the return content (weekly schedule and templates). No contradictions. Could mention if the data is cached, but not necessary.
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 sentences, with the first stating the main purpose and the second detailing return content. No extraneous text. Efficient and 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?
Given no parameters, comprehensive annotations, and the presence of an output schema (not shown but noted in context), the description sufficiently explains the tool's behavior and return values for a read-only getter.
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?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter info. Baseline of 4 is appropriate.
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 it retrieves current macro targets, specifically weekly schedule and templates. It uses a specific verb 'Get' and resource 'macro targets', and the context distinguishes it from sibling tools like 'get_daily_nutrition' which deal with actual intake.
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?
No explicit guidance on when to use versus alternatives, but the purpose is clear and the tool is simple with no parameters. The description implies it's for retrieving target configuration, but it doesn't provide exclusions or alternatives.
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 the tool as read-only and idempotent. The description adds minimal behavioral context beyond the return structure (categories, consumed amounts, confidence levels). It does not disclose any additional behavioral traits, but the annotations cover the key safety aspects.
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 five sentences, front-loading the main purpose and including an 'Args:' section. Every sentence adds value, and there is no wasted wording.
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's simplicity (one optional parameter, output schema exists), the description sufficiently explains what the tool returns and when to use it. It does not need to describe return values because the output schema handles that.
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 zero description coverage, but the description explains the single parameter 'date' with format 'YYYY-MM-DD' and default behavior ('defaults to today'). This adds essential meaning that the schema alone 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 clearly states the verb 'Get' and the resource 'nutrition scores', and elaborates on what it returns (per-nutrient consumed amounts, category grades). It distinguishes itself from siblings by calling itself the 'richest nutrition endpoint' and specifying when to use it.
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 says 'use it when you need to know both how much of each nutrient was consumed AND how close each is to the target.' This provides clear context for when to use it, though it does not name specific alternatives or state when not to use it.
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?
Annotations already indicate idempotent and non-destructive. Description adds that complete flag toggles state, but omits side effects (e.g., impact on nutrition scores or history). No contradiction with 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?
Extremely concise: two-line description plus Args section. Every word adds necessary detail 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?
Has output schema (not shown) which may compensate, but description lacks info on return value, error cases, or effect of marking already complete day. Adequate for a simple toggle but not fully transparent.
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 coverage 0% means description must clarify parameters. Description specifies date format (YYYY-MM-DD) and complete meaning (True/False), adding value over schema's type-only info. But does not explain default behavior or required status.
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?
Description clearly states verb 'Mark' and resource 'diary day', with explicit options (complete/incomplete). Distinguishes from sibling tools like add_food_entry or 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?
No guidance on when to mark a day complete vs other actions, nor preconditions or effects on related data. User must infer context from name alone.
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 |
|---|---|---|---|
| entry_ids | Yes | ||
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include destructiveHint=true, idempotentHint=true, openWorldHint=true. Description adds 'Remove' aligning with destructive but does not elaborate on idempotency or irreversibility 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 short, front-loaded with the main action, followed by a usage hint and parameter descriptions. No redundant sentences.
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 prerequisites, parameters, and defaults. With an output schema present, it does not need to explain return values. Adequate for a removal 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?
Despite 0% schema coverage, description explains both parameters: entry_ids as 'List of serving/entry IDs to remove' and date with format and default, adding meaning beyond the schema.
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?
Description states specific verb 'Remove' and resource 'food entries from the Cronometer diary,' clearly distinguishing from sibling tools like add_food_entry or get_food_log.
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 a clear prerequisite: 'Use get_food_log to find entry IDs.' Does not explicitly state when not to use, but the purpose is unambiguous given it's a removal tool.
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. Use the food_id and measure_id from results with add_food_entry, or pass 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, destructiveHint, idempotentHint, and openWorldHint. The description adds value by detailing what results contain (IDs, source info) and how they connect to other operations, which is consistent and informative.
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, with two short paragraphs: one for purpose and output, one for parameter. Every sentence adds value, and the structure is front-loaded with the key action.
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's simplicity (one parameter, output schema exists), the description covers essential aspects: what it does, what it returns, and how to use results. It could mention pagination or matching behavior, but the openWorldHint may account for variability.
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 no description for the query parameter. The description provides a clear definition with examples ('e.g. "eggs", "chicken breast"'), fully compensating for the 0% schema coverage.
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', specifying the verb and resource. It distinguishes from sibling tools by explaining how results feed into add_food_entry and 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?
The description provides explicit guidance on using results with add_food_entry or get_food_details, implying this is the appropriate tool for query-based lookup. It lacks explicit when-not-to-use, but the context and sibling set make it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose. add_custom_food creates a new food, while add_food_entry logs it. get_daily_nutrition returns totals, get_nutrition_scores adds category grades. Fasting tools are separate from diary tools. No overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., add_food_entry, get_food_log, mark_day_complete). No mixing of styles or ambiguous verbs.
13 tools is appropriate for a nutrition tracking API. It covers food search, custom creation, logging, removal, day copying, nutrition queries, fasting, and diary state management without being overwhelming.
Core logging and reading operations are present, but missing update operations (e.g., edit a diary entry or modify macro targets) and deletion of custom foods. Users must remove and re-add for edits, which is a notable gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Log meals, check calories and macros, set up a nutrition plan, and search foods.
Food logging, nutrition summaries, and meal photo calorie and macro estimates.
Personal nutrition tracking — log meals, track macros, review history, import from another app.
Log what you ate by talking to your AI assistant — calories and macros, completely free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mhyounis19/cronometer-api-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
