get_nutrition_summaryCalculate evidence-aware calorie and macro totals for today, the last seven days, or the previous calendar week to review your nutrition intake.
Calculate evidence-aware calorie and macro totals for today, the last seven days, or the previous calendar week.
| Name | Required | Description | Default |
|---|---|---|---|
| period | Yes | ||
| timezone_offset_minutes | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint false, so the safety and mutability profile is covered. The description adds the phrase 'evidence-aware,' which hints at a calculation methodology but does not explain data sources, freshness, or failure modes, so additional behavioral value is limited.
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 a single, front-loaded sentence with no filler. Every word contributes to identifying the calculation and its supported periods.
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 two-parameter read-only tool, the description gives the core purpose and the period options. However, it omits any explanation of the timezone offset parameter and leaves 'evidence-aware' undefined, so it is only minimally sufficient.
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 carry parameter meaning. It lists the three period enum values, but those are already present in the schema and it says nothing about the optional timezone_offset_minutes parameter or its effect on the calculation. This leaves a meaningful input undocumented.
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 states a specific verb (Calculate), resource (calorie and macro totals), and scope (today, last seven days, previous calendar week). It is clear enough for an agent to understand the tool without opening the schema, but it does not explicitly differentiate itself from any sibling tools.
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 that the tool should be used to obtain nutrition summaries over the listed periods, but it does not state when to use it versus alternatives, nor does it provide any exclusions or prerequisites. Usage is only inferable from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.