Wellness Project

get_nutrient_summary

Read-onlyIdempotent

Summarize logged micronutrient (and macro) intake for one day or a short range, with each nutrient's target and coverage. Use for "how's my vitamin D / sodium / iron this week", or a general "how are my micronutrients looking" (default: every tracked nutrient except amino acids, for today).

INFER -- do not ask:

date: default to today (resolved in the user's own timezone)
days: default to 1 (just date); for a range, set days to the number of days ending on date (e.g. "this week" -> days=7)
nutrients: default to every nutrient with logged data this period, excluding amino acids (those are rarely tracked and would crowd out the rest). Ask for specific nutrients by name (aliases like "b12", "carbs", "fibre" resolve) only to see amino acids or a nutrient with no data yet.

Returns up to 60 nutrients. days=1 reports that day's totals; days>1 reports the range average per nutrient plus how many days were complete.

FORMAT: default 'compact' packs each panel (known/food/supplement/target_value/target_upper_limit/target_percent) as one "id:value;id:value" string, ids ascending, values to at most 3 significant digits, units are the dictionary's below -- never repeat a nutrient's name or unit back to the user from these strings, resolve the id first. coverage/items_total/items_with_value/estimated_items/target_source/target_kind stay small id-keyed records. A nutrient outside the dictionary (amino acids, Cronometer extras) has no id, so its value is dropped and its name listed once under omitted; call again with format:'verbose' to see it. 'verbose' returns one full object per nutrient instead, as before.

NUTRIENT ID DICTIONARY (id=name, unit per the id; also used by get_nutrient_history/get_nutrient_contributors's id field): 1=fiber_g 2=sugar_g 3=saturated_fat_g 4=monounsaturated_fat_g 5=polyunsaturated_fat_g 6=trans_fat_g 7=cholesterol_mg 8=sodium_mg 9=potassium_mg 10=calcium_mg 11=iron_mg 12=magnesium_mg 13=phosphorus_mg 14=zinc_mg 15=copper_mg 16=manganese_mg 17=selenium_ug 18=chloride_mg 19=chromium_ug 20=iodine_ug 21=molybdenum_ug 22=vitamin_a_ug 23=vitamin_c_mg 24=vitamin_d_ug 25=vitamin_e_mg 26=vitamin_k_ug 27=thiamin_b1_mg 28=riboflavin_b2_mg 29=niacin_b3_mg 30=pantothenic_acid_b5_mg 31=vitamin_b6_mg 32=biotin_b7_ug 33=folate_b9_ug 34=folic_acid_ug 35=vitamin_b12_ug 36=choline_mg 37=omega3_g 38=omega6_g 39=caffeine_mg 40=water_g 41=starch_g 42=added_sugar_g 43=total_unsaturated_fat_g 44=fluoride_mg

DATA COMPLETENESS: totals are sums over the logged items that carry a value for that nutrient; coverage tells how many did. Say "based on foods with X data" when coverage is partial; never call a low intake a deficiency; intake is not a lab result; supplement vs food split is reported separately. A daily supplement counts on every day it's active by default -- the user isn't expected to check it off -- unless a day was explicitly marked not taken, so its share of a total can include days with no check-in.

Input Schema

TableJSON Schema

Name	Required	Description
`date`	No	End date (or the only date if days=1). Format: YYYY-MM-DD. Optional -- omit for today.
`days`	No	How many days, ending on date. Optional -- default 1.
`format`	No	compact (default) packs values by nutrient id, see FORMAT above. verbose spells out each nutrient's name and unit.
`nutrients`	No	Nutrient names or aliases to restrict to (e.g. ["vitamin_d","calcium"]). Optional -- default is every nutrient with data except amino acids.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Human-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial extra behavior: coverage semantics ('totals are sums over items that carry a value'), the instruction never to call low intake a deficiency, food-vs-supplement split reporting, and the subtle default that an active supplement counts on every day unless explicitly marked not taken. These are genuine behavioral facts not derivable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded (purpose first, then INFER/FORMAT/DICTIONARY/DATA sections) and everything is labeled, but the 44-entry ID dictionary dominates the length and is payload reference data that inflates the definition. Defensible because compact output is unreadable without it, but it is a lot of text for a tool definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, yet the description still documents the two format modes and what each returns. Combined with the completeness caveats and default rules, an agent has everything needed to call this correctly and interpret the results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (baseline 3), and the description goes further by spelling out resolution rules: timezone-local 'today', 'this week' -> days=7, alias handling ('b12', 'carbs', 'fibre'), and that days>1 returns a range average. Much of the date/days/format meaning still overlaps the schema text, so it is strong rather than exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: 'Summarize logged micronutrient (and macro) intake for one day or a short range, with each nutrient's target and coverage.' It also distinguishes itself from the related history/contributor tools by referencing them in the ID dictionary context, so an agent can tell what this tool uniquely returns (a period summary with targets) versus a history or contributor breakdown.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering phrases ('how's my vitamin D / sodium / iron this week', 'how are my micronutrients looking') and resolves the common inference cases (date=today, days=1, nutrients=all-but-amino-acids) with explicit 'do not ask' instructions. It does not, however, explicitly route against the sibling get_nutrient_history/get_nutrient_contributors for when a summary is preferable to a trend or breakdown, leaving one routing decision to inference.

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

All Wellness Project tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.