Wellness Project

get_nutrient_contributors

Read-onlyIdempotent

Top logged foods and supplements contributing to ONE nutrient over a day or short range, highest amount first. Use for "what gave me most of my sodium today" or "what's driving my potassium this week".

INFER -- do not ask:

date: default to today (resolved in the user's own timezone)
days: default to 1 (just date); set higher for a range ending on date
limit: default to 10

nutrient is required and accepts common aliases (e.g. "b12", "carbs", "fibre").

FORMAT: default 'compact' replies with id (this nutrient's number in get_nutrient_summary's nutrient dictionary, whose unit then applies) instead of key/unit, and drops the per-contributor unit field it would otherwise repeat on every row. A nutrient outside that dictionary has no id, so key/unit are used regardless of format. 'verbose' always uses key/unit and keeps unit on every contributor, as before.

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.
`limit`	No	Max contributors to return. Optional -- default 10.
`format`	No	compact (default) packs values by nutrient id, see FORMAT above. verbose spells out each nutrient's name and unit.
`nutrient`	Yes	Nutrient name or alias, e.g. "vitamin_d", "calcium", "b12". Required.

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.6/5.0

Behavior5/5

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

Annotations already declare the safe read-only/idempotent profile, and the description adds substantial behavior beyond them: default resolution rules, the compact-vs-verbose output contract, coverage semantics ('based on foods with X data'), and the non-obvious rule that an active daily supplement counts on every day unless marked not taken. These are exactly the traits an agent cannot infer from structured fields.

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

Conciseness4/5

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

Front-loads the core purpose and is clearly sectioned (INFER / FORMAT / DATA COMPLETENESS), so scanning is easy. It is on the long side and the FORMAT block partially restates the schema's format field, but the detail is load-bearing rather than filler.

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 shape need not be re-explained, and the description nonetheless covers defaults, alias handling, output-format tradeoffs, and the statistical caveats (coverage, not a lab result, supplement-vs-food split). Nothing an agent needs to invoke this correctly is missing.

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%, so baseline is 3, but the description adds real meaning: nutrient accepts common aliases (b12, carbs, fibre), format semantics explain how output changes per value, and default/omission behavior for date, days, and limit is spelled out. This exceeds what the schema alone conveys.

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+resource+scope: top logged foods/supplements contributing to ONE nutrient over a day or range, ordered highest first. This clearly differentiates it from aggregation siblings like get_nutrient_summary and get_nutrient_history, and the example phrasings ('what gave me most of my sodium today') remove any ambiguity about what it returns.

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 usage triggers via quoted example questions, and the defaults section tells the agent how to proceed without asking. However it never explicitly names alternatives (get_nutrient_summary, get_nutrient_history) or states when NOT to use this tool, so the routing guidance is context-only rather than explicit.

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.