This server provides a comprehensive MCP interface to Cronometer, enabling nutrition tracking, diary management, food search, activity logging, and more.
Food Log & Nutrition: Retrieve daily food entries (with nutrient contributions and energy summaries), macro/micronutrient totals, and nutrition scores (category grades and confidence levels).
Food Search & Details: Search Cronometer's food database by name and get detailed nutrition profiles and serving sizes.
Diary Management: Add or remove food entries, create custom foods with specific nutrition data, copy a previous day's entries, and mark days as complete.
Targets & Tracking: Access weekly macro targets and templates, fasting history within a date range, and aggregate fasting statistics.
Activity & Sleep: Log walks, workouts (with calories and steps), and sleep records (including stages and scores).
Click on "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 show my daily nutrition for today"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Hosted version for Claude.ai, ChatGPT, and Grok coming soon. Join the waitlist →
An MCP (Model Context Protocol) server for Cronometer nutrition tracking, built on the reverse-engineered mobile REST API.
Unlike cronometer-mcp, which takes a comprehensive GWT-RPC approach against Cronometer's web backend, this server talks to the same JSON REST API used by the Cronometer Android app -- with clean payloads and stable, versioned endpoints.
Food log -- diary entries with food names, amounts, meal groups
Nutrition data -- daily macro/micro totals and nutrition scores with per-nutrient confidence
Food search -- search the Cronometer food database, get detailed nutrition info
Diary management -- add/remove entries, copy days, mark days complete
Custom foods -- create foods with custom nutrition data
Macro targets -- read weekly schedule and saved templates
Fasting -- view history and aggregate statistics
Biometrics -- weight, body fat, heart rate, and other tracked metrics over a date range
Activity & sleep -- log walks and workouts, record a night's sleep with its stage breakdown
Related MCP server: nutrition-mcp
curl -LsSf https://astral.sh/uv/install.sh | shexport CRONOMETER_USERNAME="your@email.com"
export CRONOMETER_PASSWORD="your-password"uvx downloads and runs the server on demand -- no separate install step.
opencode.json){
"$schema": "https://opencode.ai/config.json",
"mcp": {
"cronometer": {
"type": "local",
"command": ["uvx", "cronometer-api-mcp"],
"environment": {
"CRONOMETER_USERNAME": "{env:CRONOMETER_USERNAME}",
"CRONOMETER_PASSWORD": "{env:CRONOMETER_PASSWORD}"
},
"enabled": true
}
}
}claude_desktop_config.json){
"mcpServers": {
"cronometer": {
"command": "uvx",
"args": ["cronometer-api-mcp"],
"env": {
"CRONOMETER_USERNAME": "your@email.com",
"CRONOMETER_PASSWORD": "your-password"
}
}
}
}Tool | Description |
| Diary entries for a date, each enriched with food name, source, serving measure/count, and that food's per-entry nutrient contribution, plus an energy_summary (target/consumed/remaining kcal) and a nutrition_summary of consumed totals for every tracked nutrient |
| Consumed macro and micronutrient totals for every nutrient tracked in Cronometer |
| Category scores (Vitamins, Minerals, etc.) with per-nutrient consumed amounts and confidence levels |
Tool | Description |
| Search the Cronometer food database by name |
| Full nutrition profile and serving sizes for a food |
Tool | Description |
| Weekly macro schedule and saved target templates |
| Fasting history within a date range |
| Aggregate fasting statistics |
All date parameters use YYYY-MM-DD format and default to today when omitted.
Tool | Description |
| Log a food serving to the diary |
| Permanently delete diary entries — no undo |
| Create a custom food with specified nutrition |
| Copy all entries from the previous day |
| Mark a diary day as complete or incomplete |
Tool | Description |
| Log a walk or workout — duration, calories burned, optional step count |
| Record a night's sleep, with optional deep/light/REM breakdown and score |
Cronometer stores these in two different places: a walk is an Exercise diary entry, a night's sleep is a Biometric.
Cronometer has no steps field. It is not one of the 54 biometric metrics and
not a field on a diary entry. log_exercise writes the step count into the entry
name, so it is visible in the diary but is text — Cronometer cannot total or
chart it. For step trends, read them from wherever they are actually recorded.
Exercise calories must be net of BMR — Cronometer counts BMR separately, so a
fitness tracker's gross session calories double-count rest. log_exercise takes
the burn three ways, best first:
Argument | Use when | Accuracy |
| copying from a tracker (Fitbit | exact — the server nets it against that day's real BMR |
| you already have a net figure | exact, if your figure is |
neither | you only know the duration | a guess (3.5 METs) |
The response reports calories_source so you can always tell which one ran.
Both tools refuse to write a same-day duplicate unless you pass force=true —
if a device integration already syncs walks or sleep, logging on top of it silently
inflates the day's burn or double-counts a night.
Neither has a delete counterpart. This is deliberate, not an oversight: the only
known deletion endpoint for these entry types removes far more than it is asked to.
Remove an exercise or biometric entry in the Cronometer app instead. See CLAUDE.md
§4.
FORK: hardened fork, read/write. This fork ran read-only through its first eight phases; the owner enabled writes on 2026-07-27. Write tools carry
readOnlyHint: Falseandremove_food_entrycarriesdestructiveHint: True, so clients can warn before mutating. Every tool — read and write — is rate-limited and audited. The biometrics tools (list_biometrics,get_biometrics) were restored in49d1263.log_exerciseandlog_sleepwere added on 2026-08-06, putting the surface at exactly 17 — 10 read, 7 write.tests/test_tool_surface.pypins it in both directions.Date ranges are capped at 90 days per call, calls are rate-limited to 60/hour, and every call is logged (shapes and counts only, never contents). See
CLAUDE.mdfor the constraints,AUDIT.mdfor the upstream security review, andRUNBOOK.mdfor operations.
The server supports remote deployment with OAuth 2.1 authorization (PKCE) for use with Claude.ai and other remote MCP clients.
Variable | Required | Description |
| Yes | Cronometer account email |
| Yes | Cronometer account password |
| No | Transport mode: |
| Remote | HMAC key used to sign and verify access tokens |
| Remote | OAuth client ID, verified at |
| Remote | OAuth client secret, verified at |
| Remote | FORK: required to complete |
| Remote | Public base URL; must match the deployed URL exactly |
| No | FORK: allowed OAuth redirect origins (default |
| No | Listen port for remote transports (default 8000) |
FORK: the four variables marked Remote are mandatory whenever
MCP_TRANSPORTissseorstreamable-http— the server refuses to start without them. Upstream treated them as optional and served the diary unauthenticated when they were absent, so a forgotten secret was a silent downgrade to no authentication at all.
The project includes a Procfile and .python-version for direct deployment with the Heroku Python buildpack:
# Create app
dokku apps:create cronometer-api-mcp
# Set environment
dokku config:set cronometer-api-mcp \
MCP_TRANSPORT=streamable-http \
MCP_AUTH_TOKEN=$(openssl rand -hex 32) \
MCP_OAUTH_CLIENT_ID=my-client \
MCP_OAUTH_CLIENT_SECRET=$(openssl rand -hex 32) \
MCP_BASE_URL=https://your-domain.com \
CRONOMETER_USERNAME=your@email.com \
CRONOMETER_PASSWORD=your-password
# Deploy
git push dokku mainWhen deployed remotely with OAuth configured, connect from Claude.ai using:
Server URL: https://your-domain.com/mcp
OAuth Client ID: Value of MCP_OAUTH_CLIENT_ID
OAuth Client Secret: Value of MCP_OAUTH_CLIENT_SECRET
Claude.ai will open a browser tab for authorization. Click Authorize to complete the connection.
For local development, copy .env.example to .env and fill in your credentials:
cp .env.example .env
# edit .env
uv run cronometer-api-mcpThe CLI auto-loads .env on startup (dev convenience only). Real environment variables always win over .env, so production deployments and MCP client env blocks are unaffected.
This server communicates with mobile.cronometer.com -- the same REST API used by the Cronometer Android/Flutter app. The API was reverse-engineered through:
Static analysis of libapp.so (Dart AOT snapshot) from the APK to discover endpoint names
Traffic interception via Frida + mitmproxy to capture exact request/response formats
Trial-and-error against the live API to confirm payload shapes
The API uses two protocols:
v2 (POST /api/v2/*) -- JSON-body auth, used for most operations (food search, diary read/write, nutrition, fasting, macros, biometrics)
v3 (DELETE /api/v3/user/{id}/*) -- Header-based auth (x-crono-session), used for diary entry deletion
You can use the client directly:
from cronometer_api_mcp.client import CronometerClient
from datetime import date
client = CronometerClient()
# Search for foods
results = client.search_food("chicken breast")
# Get food details
food = client.get_food(results[0]["id"])
# Log a serving
client.add_serving(
food_id=food["id"],
measure_id=food["defaultMeasureId"],
grams=200,
)
# Get today's diary
diary = client.get_diary()
# Get nutrition scores
scores = client.get_nutrition_scores()MIT
Create a custom food in Cronometer with specified nutrition.
Nutrient amounts should be for the full serving size specified. After creation, use the returned food_id with add_food_entry to log it.
Args: name: Food name. calories: Calories per serving (kcal). protein_g: Protein per serving (g). fat_g: Fat per serving (g). carbs_g: Carbs per serving (g). fiber_g: Fiber per serving (g, default 0). sugar_g: Sugar per serving (g, default 0). sodium_mg: Sodium per serving (mg, default 0). saturated_fat_g: Saturated fat per serving (g, default 0). serving_name: Name for the serving size (default "1 serving"). serving_grams: Weight of one serving in grams (default 100).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| fat_g | Yes | ||
| carbs_g | Yes | ||
| fiber_g | No | ||
| sugar_g | No | ||
| calories | Yes | ||
| protein_g | Yes | ||
| sodium_mg | No | ||
| serving_name | No | 1 serving | |
| serving_grams | No | ||
| saturated_fat_g | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (write operation), idempotentHint=false (not idempotent), and destructiveHint=false. The description adds that the tool returns a food_id for subsequent logging, which is useful. However, it does not mention what happens if a food with the same name already exists or any other side effects, leaving some behavioral gaps.
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 and well-structured: a one-line summary, two brief usage notes, and a clear bullet list of parameters. 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 tool has 11 parameters and a moderate complexity, the description covers the essential steps (creation and subsequent logging). However, it lacks details on potential errors (e.g., duplicate name validation) and constraints (e.g., value ranges), which would improve completeness. The output schema is present but not relied upon 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?
The input schema has no descriptions (0% coverage), but the tool description provides per-parameter explanations with units, defaults, and units (e.g., 'Calories per serving (kcal)'). This adds significant meaning beyond the schema titles, though some explanations are minimal (e.g., 'Fat per serving (g)').
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 'Create a custom food in Cronometer with specified nutrition', providing a specific verb and resource. It distinguishes itself from sibling tools like 'search_foods' (search) and 'get_food_details' (retrieve) by focusing on creation, and explicitly mentions using the returned food_id with '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?
The description advises that nutrient amounts should be for the full serving size and directs the user to use the returned food_id with 'add_food_entry' after creation. This provides clear context for when to use the tool and what to do next, but does not explicitly mention when not to use it or list alternative tools for cases like duplicate food names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a food entry to the Cronometer diary.
Use search_foods to find food_id and measure_id, then get_food_details to confirm serving sizes and gram weights.
Args: food_id: Numeric food ID from search_foods results. measure_id: Measure/unit ID from get_food_details. grams: Weight of the serving in grams. date: Date to log as YYYY-MM-DD (defaults to today). translation_id: Translation ID from search results (usually 0). diary_group: LEAVE THIS AS "auto" unless the user explicitly named a meal. Do NOT infer it yourself from the time -- you do not know the user's timezone or which meals their account has, and guessing "snacks" at 11pm has repeatedly filed food under Morning Snacks. On "auto" the server reads the user's local clock and their own configured meals and picks correctly.
Only pass a value when the user said one, e.g. "add it to
lunch". Matching is case-insensitive on a substring of
the account's real meal names; the error lists them.The response includes a logged_to block naming the meal it chose, the local time, and the timezone. Tell the user which meal it went to -- that is how a misfiled entry gets caught immediately rather than days later.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| grams | Yes | ||
| food_id | Yes | ||
| measure_id | Yes | ||
| diary_group | No | auto | |
| translation_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint false). Description adds context: response includes logged_to block, warns about misfiling, and explains diary_group behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and front-loaded, but somewhat lengthy due to detailed parameter docs. Every sentence adds value; conciseness is slightly sacrificed for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters, response handling, prerequisites, and edge cases (e.g., meal guessing). With output schema present and good annotations, description is fully sufficient for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description thoroughly explains all 6 parameters, including defaults, usage, and implications (e.g., diary_group auto behavior, translation_id, date format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Add a food entry to the Cronometer diary' with a specific verb and resource. Distinguishes from sibling tools like search_foods and remove_food_entry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use search_foods and get_food_details first. Provides detailed guidance on diary_group, warning against inferring meals and explaining when to override default.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy all diary entries from the previous day to the given date.
Additive -- does not remove existing entries on the destination date.
Args: date: Destination date as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that the operation is additive and non-destructive, which aligns with annotations and provides useful behavioral context.
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: two sentences plus an argument doc. It front-loads the main action, then clarifies the additive nature. 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?
The description is mostly complete but has a slight ambiguity: 'from the previous day' could be interpreted as the day before the destination date or the calendar day before today. Clarifying the source would improve 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 fully compensates by explaining the date parameter format 'YYYY-MM-DD' and default behavior ('defaults to today'), adding essential 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?
The description clearly states 'Copy all diary entries from the previous day to the given date', specifying the action (copy), resource (diary entries), and target (given date). This distinguishes the tool from siblings 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?
The description mentions 'Additive -- does not remove existing entries on the destination date', providing a key usage guideline. It lacks explicit when-to-use or when-not-to-use compared to alternatives, but the context is clear enough.
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?
The description adds value beyond annotations by explaining that null values occur for untracked macros and that nutrients are included only if tracked. It also describes the response structure. Annotations already indicate safety and idempotency, so additional behavioral details are sufficient.
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 and front-loaded with the core purpose. It uses bullet points for the response structure and provides necessary context without extraneous details. 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?
Given the presence of an output schema, the description sufficiently covers the return values and behavior. It explains nutrient inclusion logic and null handling. The tool is simple with one parameter, and the description is complete.
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, but the description compensates with a dedicated 'Args' line specifying the date format (YYYY-MM-DD) and default behavior (today). This fully explains the sole parameter.
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.' It specifies what the tool returns (summary with macros, nutrients list) and distinguishes from siblings like get_macro_targets (targets vs consumed) and get_food_log (log vs summary).
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 and advises setting targets to surface specific nutrients. It provides implicit guidance on when to use (daily consumption) but does not explicitly state when not to use or compare to alternatives.
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 provide readOnlyHint, idempotentHint, and destructiveHint. Description adds details about return fields (status, timestamps, duration) and parameter 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?
Two short sentences plus an Args block. Front-loaded with action and resource. 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?
Adequate for a read-only tool with output schema present. Description covers return fields and parameter defaults. Missing info on pagination or limits, but not critical given annotations.
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's Args section fully explains both parameters with format (YYYY-MM-DD) and defaults (30 days ago for start, today for end). This adds essential 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 clearly states 'Get fasting history from Cronometer' and specifies return content: fasts with status, timestamps, duration. Differentiates from siblings like get_fasting_stats by focusing on history rather than 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?
Implies usage when needing fasting history with date range, but does not explicitly exclude alternatives or state when not to use. However, the purpose is clear enough for an agent to select correctly.
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, non-destructive. Description adds value by specifying the exact return fields and that it returns aggregates. No behavioral traits beyond annotations are hidden, but no disclosure of time range 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?
Two sentences: first states purpose, second lists return values. Extremely concise and front-loaded with no wasted text. 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?
Given no parameters, rich annotations, and existing output schema, description is almost complete. However, missing mention of the time period (e.g., all-time or date range) leaves a minor gap in understanding for the 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?
No parameters, so schema coverage is 100%. Description naturally provides no parameter info beyond schema. Baseline 4 for zero parameters 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?
Clearly states it gets aggregate fasting statistics and explicitly lists the returned fields (total fasting hours, longest fast, average fast duration, completed fast count). This distinguishes it from sibling tools like get_fasting_history which returns detailed logs.
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 usage for aggregate stats vs get_fasting_history for detailed history, but no explicit when-to-use or when-not-to-use guidance. No mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed food information including nutrition and serving sizes.
Use this after search_foods to get the full nutrient profile and the available serving sizes for a food.
Args: food_id: Food ID from search_foods results.
| Name | Required | Description | Default |
|---|---|---|---|
| food_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, which cover safety and idempotence. The description adds that the tool returns nutrition and serving sizes and that food_id comes from search_foods, but does not disclose additional behavioral details such as the response structure or how it handles missing data. With rich annotations, the description's incremental value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus an args section) and well-structured, with each sentence serving a purpose. It front-loads the core action and returns information, then provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return values are already defined), the simple one-parameter tool is fully described. The description covers the tool's purpose, parameter origin, and integration with sibling tools, meeting all needs for a complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that food_id is 'Food ID from search_foods results', which adds critical context beyond the schema's type and title. This effectively guides the agent in providing the correct value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed food information including nutrition and serving sizes. It distinguishes from siblings like search_foods (which provides basic info) and get_food_log (which returns logged entries), making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use this tool after search_foods to obtain full nutrient profiles and serving sizes, providing clear usage context and sequence. It effectively guides the agent on when to apply the tool relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all diary entries for a given date.
Returns every food entry logged for the day. Each "Serving" entry is enriched (best-effort) with the food's name, source, the serving measure (unit name and grams per unit), the number of servings, and that food's own nutrient profile scaled to the amount eaten. Non-food entries (exercise, biometrics) carry their own name.
Note: the per-entry "nutrients" are each food's individual contribution, which is distinct from the day-level nutrition_summary aggregate below.
Also returns a top-level energy_summary field with pre-computed values most relevant to the user:
total_target_kcal: daily calorie target dynamically adjusted for expenditure and weight goal (equivalent to Cronometer's "Total Target" in the Energy Summary screen)
consumed_kcal: total calories consumed
remaining_kcal: calories remaining to stay on target (total_target_kcal - consumed_kcal). Always report this when summarizing the user's day. Prefer this over manually deriving values from the burn breakdown fields.
Also returns a nutrition_summary field with consumed totals for every nutrient the user tracks in Cronometer (macros plus any tracked micronutrients such as saturated fat, cholesterol, or omega-3/6):
macros: flat macro totals (energy, protein, carbs, net_carbs, fat, fiber, alcohol)
nutrients: the full list of tracked nutrients with amounts and units
Args: date: Date as YYYY-MM-DD (defaults to today).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains enrichment behavior ('best-effort'), distinguishes per-entry from day-level summaries, and details the returned fields. Annotations indicate readOnly, openWorld, idempotent, and non-destructive, which align with the description. 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 well-structured with sections for the main purpose, field explanations, and args. It is informative but could be slightly more concise; however, 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?
Given the tool's complexity (food log, energy and nutrition summaries), the description covers all returned fields and their relationships. An output schema exists, reducing the burden, but the description still provides necessary 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?
The schema has 0% coverage, but the description explicitly documents the 'date' parameter with format (YYYY-MM-DD) and default behavior ('defaults to today'), adding significant 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?
The description clearly states 'Get all diary entries for a given date,' specifying the verb and resource. It distinguishes itself from sibling tools like search_foods by focusing on a date's 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 explicit context for when to use the tool (e.g., for a specific date) and gives guidance on using the energy_summary field ('Always report this…'). It lacks explicit when-not or alternative suggestions, 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.
Get current macro targets including weekly schedule and templates.
Returns the weekly macro schedule (which template applies to each day) and all saved macro target templates with their values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. Description adds return content details (schedule and templates), which is useful but not deeply revealing of edge cases or side effects.
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 well-structured sentences with front-loaded purpose. No extraneous words, each sentence serves a clear role.
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?
Output schema exists and description covers what the tool returns. Could mention that it is a read-only operation, but annotations already imply that. Adequate for a zero-parameter 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?
No parameters exist; schema coverage is 100%. Description adds no parameter info but none is needed. 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?
Clearly states it retrieves macro targets including weekly schedule and templates. The verb 'get' combined with specific outputs distinguishes it from sibling tools that handle actual intake or 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?
Implies usage for retrieving target data but provides no explicit guidance on when to prefer this over alternatives like get_daily_nutrition or get_nutrition_scores.
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 indicate readOnlyHint=true and idempotentHint=true, making safety clear. The description adds valuable behavioral context about return format (category scores, consumed amounts, confidence levels) without contradicting 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?
Concise and well-structured: front-loaded with purpose, then details, then usage guidance, then parameter docs. Every sentence provides value with no 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 tool's simplicity (one optional parameter) and presence of an output schema, the description fully explains the return structure and when to use it, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It documents the sole parameter 'date' with format YYYY-MM-DD and default today, which adds meaningful guidance 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 tool retrieves nutrition scores with per-nutrient consumed amounts and category grades. Distinguishes from siblings by calling itself 'the richest nutrition endpoint' and listing specific categories (All Targets, Vitamins, etc.).
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 it when you need to know both how much of each nutrient was consumed AND how close each is to the target', providing clear context for usage. Does not explicitly exclude alternatives, but the context strongly implies when to select this over other nutrition tools.
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 mutability, idempotency, and non-destructive nature. The description adds context that this is a toggle operation. No contradictions exist. It could be improved by noting any error conditions or state dependencies.
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 minimal and efficient: a one-line purpose followed by two concise lines explaining parameters. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameter semantics adequately. Since an output schema exists, return details are not required. A small gap is the lack of mention of behavior for non-existent dates, but the tool is simple enough.
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 specifying the date format (YYYY-MM-DD) and the boolean role for complete. This adds essential meaning beyond the schema's type definitions.
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 'Mark' and the resource 'diary day', and specifies the action as toggling complete/incomplete. It distinguishes itself from sibling tools which are mostly getters or food-related operations.
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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, contextual triggers, or exclusions, leaving the agent without clear decision criteria.
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 indicate destructiveHint=true and idempotentHint=true. The description adds the ability to remove 'one or more' entries and mentions date parameter default. It does not contradict annotations but adds limited behavioral context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single sentence for purpose, followed by a clear hint, then a brief args section. Every sentence is necessary and front-loaded.
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 destructive tool with annotations and an output schema, the description adequately covers prerequisites and parameters. It could mention that removal is permanent or updates the diary, but overall it is complete.
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 compensates by clearly explaining each parameter: 'List of serving/entry IDs to remove' for entry_ids and 'Date the entries belong to as YYYY-MM-DD (defaults to today)' for date. This adds 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?
The description clearly states the verb 'remove' and the resource 'food entries from the Cronometer diary'. It distinguishes from sibling tool 'add_food_entry' by focusing on removal.
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 get_food_log to find entry IDs', providing clear prerequisite and context for when to use this tool. It does not explicitly state when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Cronometer's food database by name.
Returns matching foods with their IDs and source information. Pass a food_id to get_food_details for full nutrition info.
Args: query: Food name or keyword (e.g. "eggs", "chicken breast").
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that it returns matching foods with IDs and source information, and includes the query parameter usage, which provides behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences and a docstring section. Every sentence adds value: purpose, outcome, and usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, single parameter, and comprehensive annotations, the description is complete. It explains what the tool returns, how to use it, and what to do with the results (pass to get_food_details).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description includes a detailed parameter docstring with examples ('e.g. "eggs", "chicken breast"'), adding significant meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search Cronometer's food database by name.' with a specific verb and resource. It also distinguishes from sibling tool get_food_details by explaining the workflow: search then pass food_id to get_food_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains the tool's purpose and links to get_food_details for full nutrition info, providing an implicit usage context. However, it does not explicitly state when not to use this tool or compare to other search or logging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_custom_foodadd_food_entrycopy_dayget_daily_nutritionget_fasting_historyget_fasting_statsget_food_detailsget_food_logget_macro_targetsget_nutrition_scoresmark_day_completeremove_food_entrysearch_foodsTools have distinct primary purposes, but get_food_log, get_daily_nutrition, and get_nutrition_scores provide overlapping nutrition data at different granularities. Descriptions help differentiate, but an agent might still be confused about which to use for a specific need.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., get_macro_targets, search_foods, add_food_entry). The naming is predictable and clear.
With 13 tools, the surface is well-scoped for a nutrition tracking API. Each tool serves a clear function without unnecessary duplication, covering targets, logging, food management, and fasting.
Core CRUD operations are covered (search, add, remove, custom food creation). Day management (copy, mark complete) and multiple read endpoints exist. Missing is an update/editing capability for diary entries, but removal and re-addition can compensate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
MCP server for Cronofy — read calendars, events and free/busy, and create, update or delete events.
Unlock the power of food transparency with our Open Food Facts MCP server. Easily look up any food
MCP server exposing supplements database used by iNutriPlan.com
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/firaskudsy/cronometer-api-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server