This server provides comprehensive access to Cronometer nutrition tracking via its API, enabling management of food logs, food search, nutrition data, and biometric tracking.
Food Log & Nutrition:
get_food_log: Retrieve diary entries for a date, including food details, serving sizes, individual nutrient contributions, energy summary (target/consumed/remaining kcal), and full daily nutrition summary.
get_daily_nutrition: Get consumed macro and micronutrient totals for all tracked nutrients on a day.
get_nutrition_scores: Obtain category-level scores (e.g., Vitamins, Minerals) with per-nutrient consumed amounts and confidence levels.
Food Search & Details:
search_foods: Search the Cronometer food database by name for food IDs and basic info.
get_food_details: Get a full nutrition profile and available serving sizes for a specific food.
Diary Management:
add_food_entry: Log a food serving by specifying food ID, measure ID, grams, date, and meal group (breakfast, lunch, dinner, snacks, or auto).
remove_food_entry: Remove one or more diary entries by entry ID.
add_custom_food: Create a custom food with user-defined nutrition (calories, macros, sodium, etc.) and serving sizes.
copy_day: Copy all entries from the previous day to a specified date.
mark_day_complete: Mark a diary day as complete or incomplete.
Targets & Tracking:
get_macro_targets: Retrieve the weekly macro schedule and all saved macro target templates.
get_fasting_history: View fasting history within a date range, including status, timestamps, and duration.
get_fasting_stats: Get aggregate fasting statistics (total hours, longest fast, average duration, completed count).
list_biometrics: List all trackable biometric metrics (e.g., weight, body fat, heart rate) with their associated units.
get_biometrics: Retrieve a biometric time series (e.g., weight, body fat) over a specified date range.
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., "@io.github.rwestergren/cronometer-api-mcp add an apple to my lunch diary"
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
Related MCP server: fatsecret-mcp-server
curl -LsSf https://astral.sh/uv/install.sh | shexport CRONOMETER_USERNAME="your@email.com"
export CRONOMETER_PASSWORD="your-password"If the account has two-factor authentication enabled, /api/v2/login
answers TOTP_CODE_REQUIRED unless the request carries the current 6-digit
code. Give the server the base32 key that Cronometer showed when 2FA was set
up (the same key you scanned into your authenticator app) and it derives the
code itself at every login (RFC 6238, SHA-1, 30 s period):
export CRONOMETER_TOTP_SECRET="ABCD EFGH IJKL MNOP QRST UVWX YZ23 4567"Spaces and lowercase are fine. Leave it unset for accounts without 2FA.
Diary entries are stamped in your Cronometer account's timezone, which the server reports at login. If that zone is wrong (for example, an older build had reset it) you can force a specific IANA zone without changing your account settings:
export CRONOMETER_ACCOUNT_TZ="America/Los_Angeles"When set, this takes precedence over both the value reported at login and any cached session, so it also overrides a stale cached timezone.
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}",
"CRONOMETER_TOTP_SECRET": "{env:CRONOMETER_TOTP_SECRET}",
"CRONOMETER_ACCOUNT_TZ": "{env:CRONOMETER_ACCOUNT_TZ}"
},
"enabled": true
}
}
}claude_desktop_config.json){
"mcpServers": {
"cronometer": {
"command": "uvx",
"args": ["cronometer-api-mcp"],
"env": {
"CRONOMETER_USERNAME": "your@email.com",
"CRONOMETER_PASSWORD": "your-password",
"CRONOMETER_TOTP_SECRET": "your-base32-key",
"CRONOMETER_ACCOUNT_TZ": "America/Los_Angeles"
}
}
}
}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 |
| Log a food serving to the diary |
| Remove one or more diary entries |
| Create a custom food with specified nutrition |
| Create a recipe from existing foods referenced by ID and gram weight |
| Create a recipe from a free-text ingredient list; Cronometer matches each line to a database food and converts the amount to grams |
| 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 |
| List trackable biometric metrics and their units |
| Biometric time series (e.g. weight, body fat) within a date range |
All date parameters use YYYY-MM-DD format and default to today when omitted.
stdio only. For remote/hosted use, the stdio server is wrapped by
supergateway (see Dockerfile),
which owns the HTTP listener and exposes MCP streamable-HTTP at /mcp. The
server has no built-in authentication — any remote deployment must sit
behind an authenticating gateway or reverse proxy.
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
Recipe import is the one asynchronous operation: import_recipe returns a job id, and poll_async_result is polled until the server reports 100% progress and attaches the parsed ingredients.
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()
# Import a recipe from a free-text ingredient list
recipe = client.import_recipe("one hot dog\nketchup\nbun")
print(recipe["food_id"], recipe["ingredients"])
# Parse without saving, to review the matches first
preview = client.import_recipe("2 tbsp olive oil\n200g chicken", save=False)
# 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: Meal slot -- one of "auto", "breakfast", "lunch", "dinner", "snacks" (case-insensitive, default "auto").
| 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 already indicate readOnlyHint=false (mutation) and openWorldHint=true. The description adds behavioral context by explaining parameter sources (food_id from search_foods, etc.) and effect (adds entry to diary), going 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 well-structured with an Args section and clear sentences. It could be slightly more concise (e.g., default values could be omitted from text since schema shows them), but it remains effective.
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, 3 required, and an output schema (present but not shown), the description covers all parameters, workflow, and usage context comprehensively. It is complete for a mutation tool with these complexities.
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 the meaning and source of each parameter (e.g., food_id from search_foods, date format YYYY-MM-DD, diary_group enum values). This adds significant value 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?
The description clearly states 'Add a food entry to the Cronometer diary', uses a specific verb (add) and resource (food entry), and distinguishes from sibling tools like search_foods (for finding) and get_food_details (for confirming).
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 search_foods and get_food_details before calling this tool, providing clear context. It lacks explicit when-not-to-use statements, but the workflow guidance is sufficient.
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 discloses the additive nature ('does not remove existing entries'), which adds behavioral context beyond the annotations. The annotations already indicate not read-only and not destructive, but the description clarifies the specific mutation behavior. However, it does not mention any other side effects, permissions, or limits.
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 three short sentences. Every sentence adds value: the first states the core action, the second explains the additive behavior, and the third documents the parameter. 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 the tool's simplicity (single optional parameter, additive operation), the description covers all necessary aspects: what it does, its side effects, and how to use the parameter. The presence of an output schema further reduces the need to describe return values. No gaps identified.
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 the only parameter 'date': its format (YYYY-MM-DD) and default value. This is meaningful beyond the schema, which only specifies string or null. The description is clear and actionable.
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 ('Copy') and the resource ('all diary entries from the previous day to the given date'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like add_food_entry or mark_day_complete, which serve different functions.
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 some usage context by noting that the operation is additive and does not remove existing entries. However, it lacks explicit guidance on when to use this tool versus alternatives, such as when to prefer it over manual entry copying, and does not mention any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a biometric time series such as weight or body fat from Cronometer.
Returns the recorded values over the date range as a list of {day, value} points.
Use list_biometrics to find metric_id and unit_id (e.g. Weight is metric_id 1, with unit_id 1 for kg or 2 for lbs).
Args: metric_id: Numeric metric ID from list_biometrics. unit_id: Numeric unit ID from the metric's units in list_biometrics. 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 |
|---|---|---|---|
| unit_id | Yes | ||
| end_date | No | ||
| metric_id | Yes | ||
| 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. Description adds return format and date range defaults, no contradictions. Doesn't detail pagination limits, but sufficient for the tool's nature.
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?
Efficient: first sentence states purpose, then return format, then prerequisite, then parameter details. 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?
With output schema present, description adequately explains return format. Covers all 4 parameters, distinguishes from siblings. Could mention any limits, but satisfactory.
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 description carries full burden. It explains metric_id and unit_id come from list_biometrics, and start_date/end_date defaults. Adds meaning beyond schema types.
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 it retrieves a biometric time series (weight, body fat) from Cronometer, returns {day, value} points. Distinct from sibling list_biometrics which is for discovery.
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 advises using list_biometrics to find metric_id and unit_id first. Provides default date ranges. Lacks explicit when-not-to-use, but clear prerequisite makes it useful.
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, idempotentHint, and non-destructive behavior. The description adds value by specifying the return fields (status, timestamps, duration) and default date ranges, which are not in annotations. No contradiction.
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: one sentence summarizing purpose, one line on return fields, then parameter details. It is front-loaded with the main action and avoids 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 presence of an output schema, the description need not detail return values. Parameter documentation is complete with format and defaults. The tool is simple and well-described for a 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 has 0% description coverage, but the description thoroughly explains both parameters: format as YYYY-MM-DD and defaults (start_date 30 days ago, end_date today). This fully compensates for the lack of schema descriptions.
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 fasting history from Cronometer for a given date range, including status, timestamps, and duration. It distinguishes itself from siblings like get_fasting_stats by focusing on historical data rather than summary statistics.
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 basic usage with parameter defaults and format, but does not explicitly differentiate from alternatives like get_fasting_stats or mention when not to use this tool. Usage is implied rather than guided.
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 readOnlyHint, idempotentHint, and non-destructive. The description adds value by explicitly listing the returned statistics, which is not captured in the schema or 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?
Two concise sentences, front-loaded with the primary action, and neatly lists the return values in a bullet-like structure. 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 no parameters, strong annotations, and an output schema (not shown but exists), the description fully covers what the tool does and what it returns. Nothing 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?
There are zero parameters, so no explanation needed. The description effectively communicates what the tool provides without any ambiguity.
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 gets aggregate fasting statistics, listing specific return fields (total hours, longest fast, average duration, completed count). It distinguishes itself from the sibling tool get_fasting_history by focusing on summary stats vs. history.
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 purpose is straightforward with no parameters, so explicit usage guidelines are not critical. However, no guidance is given on when to choose this over get_fasting_history, which could be helpful. Still, clarity is high.
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, openWorldHint, idempotentHint, and not destructive. The description adds value by specifying the data returned (nutrition, serving sizes, measure_ids) and how it's used in the workflow, but doesn't contradict 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: one line for purpose, one line for usage guidelines, and an Args section. No redundant words, 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 the simple one-parameter input and the presence of an output schema, the description covers purpose, usage context, parameter source, and relationship to siblings. It's complete for an agent to correctly select and invoke 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 only parameter food_id has no schema description (0% coverage). The description compensates by stating 'Food ID from search_foods results,' which tells the agent the source of the ID.
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's purpose: 'Get detailed food information including nutrition and serving sizes.' It also positions the tool in a workflow: after search_foods and before add_food_entry, distinguishing it from siblings.
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 says 'Use this after search_foods to get the full nutrient profile and available measure_ids needed for add_food_entry.' This provides clear when-to-use and how it fits with 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 signal read-only, idempotent, non-destructive behavior. The description adds the return content (weekly schedule and templates) but does not disclose any additional behavioral traits like authentication needs or data freshness. With annotations present, the description provides adequate but minimal extra value.
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 concise sentences with no filler. The main purpose is stated first, followed by a clear breakdown of what is returned.
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, annotations are comprehensive, and an output schema exists, the description covers the essential information. It explains the return content sufficiently, though it might be improved by briefly noting that templates include saved values.
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%. The description does not need to elaborate on parameters. Baseline is 4 for no parameters.
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 uses a specific verb ('Get') and resource ('macro targets'), and further clarifies it includes 'weekly schedule and templates'. This clearly distinguishes it from sibling tools like get_daily_nutrition 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 this tool is for retrieving macro targets, but lacks explicit guidance on when to use it versus alternatives, such as get_daily_nutrition. No 'when not to use' or alternative tool references are provided.
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.
List the biometric metrics tracked in Cronometer.
Returns every metric type the account can record (Weight, Body Fat, Heart Rate, Blood Glucose, Waist Size, Sleep, blood panels, body measurements, etc.). Use the metric_id and a unit_id from the results with get_biometrics.
| 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, openWorldHint, idempotentHint, and destructiveHint= false. The description adds value by listing example metrics and indicating the tool returns all metric types, which goes beyond the annotations without contradiction.
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 no wasted words: the first states purpose, the second provides examples and usage guidance. Information is front-loaded and well-organized.
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 and an existing output schema, the description fully explains what the tool returns and how to use the results with get_biometrics. No gaps remain.
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 information; baseline 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 explicitly states 'List the biometric metrics tracked in Cronometer' and provides examples (Weight, Body Fat, etc.), making the verb+resource clear. It also mentions using results with get_biometrics, distinguishing it from the sibling tool that retrieves specific data.
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 advises to use metric_id and unit_id from results with get_biometrics, providing clear context on when to use this tool and how it connects to another. No explicit when-not-to-use, but the guidance is sufficient.
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 provide idempotentHint and destructiveHint. Description adds no extra behavioral context (e.g., effect on other states, permission needs).
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 (3 lines) with a clear title line and docstring-style parameter descriptions. 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?
For a simple toggle tool with output schema available, the description covers the core action and parameters. Minor lack of typical use-case 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?
Schema has no parameter descriptions (0% coverage), so the description's explanation of 'date' and 'complete' parameters is essential and clear, with format and usage.
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 uses a specific verb ('Mark') and resource ('diary day'), clearly indicating the action. It is distinct from siblings like 'copy_day'.
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 complete vs incomplete or when to use this tool over alternatives such as 'copy_day' or the various get tools.
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?
Annotations already provide destructiveHint=true and idempotentHint=true, and the description's 'Remove' aligns with them. No contradictions. The description adds minimal behavioral context beyond the annotations, such as no mention of authorization or side effects, but it is adequate.
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 no wasted words. It uses a clear structure: one-line purpose, prerequisite hint, and a simple Args list. Every sentence adds value.
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 removal tool with only two parameters, the description fully covers what an agent needs: what it does, how to find entry IDs, and what the parameters mean. Output schema exists but is not needed for this level of completeness.
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 adds necessary meaning: entry_ids are 'list of serving/entry IDs to remove' and date is 'the date the entries belong to as YYYY-MM-DD (defaults to today).' This compensates well for the missing schema descriptions.
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 'Remove' and the resource 'food entries from the Cronometer diary', making the purpose unambiguous. It distinguishes itself from siblings like add_food_entry and 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?
The description provides a clear prerequisite: 'Use get_food_log to find entry IDs.' It does not explicitly state when not to use this tool, but the context is sufficient for an AI agent to understand the typical usage scenario.
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 indicate read-only and idempotent; description adds that results include IDs and source. No contradictions, and it provides necessary 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?
Four sentences, front-loaded with purpose, no redundancy, each sentence adds value. 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?
Covers input, output hints, and integration with sibling tools. Given existence of output schema, description is sufficiently complete for a search 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 the 'query' parameter with examples ('eggs', 'chicken breast'), adding meaningful semantics beyond the type 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 tool searches Cronometer's food database by name and returns matching foods with IDs and source information, distinguishing it from get_food_details and add_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 describes how to use results (food_id and measure_id for add_food_entry, food_id for get_food_details), providing clear context for use. Lacks explicit exclusion scenarios but adequate.
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. Dates show when Glama detected each change.
v0.1.0add_custom_foodadd_food_entrycopy_dayget_biometricsget_daily_nutritionget_fasting_historyget_fasting_statsget_food_detailsget_food_logget_macro_targetsget_nutrition_scoreslist_biometricsmark_day_completeremove_food_entrysearch_foodsEach tool targets a distinct resource and action (e.g., get_food_log vs. add_food_entry, search_foods vs. get_food_details). No overlapping purposes, descriptions clearly differentiate.
All tools follow a consistent verb_noun pattern in snake_case (e.g., get_food_log, add_food_entry, list_biometrics). No mixing of conventions or unpredictable naming.
15 tools cover the core domain of food logging, nutrition tracking, fasting, and biometrics without being excessive. Each tool has a clear purpose and earns its place.
Covers key operations: CRUD for food log (add, get, remove), food search/details, custom food creation, nutrition summaries, targeting, fasting, and biometrics. Missing update for food entries and custom foods, but core workflows are supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP server for training, nutrition, wellness, and performance data with OAuth 2.0.
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Hosted MCP server for the Healthie EHR & telehealth API: patients, appointments, charting, tasks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rwestergren/cronometer-api-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server