Skip to main content
Glama

IZeat

Period summary

period_summary
Read-only

Returns what was recorded between two dates, inclusive: coverage, totals, the average per recorded day, the target timeline, and public day, week, month or meal rows. Use it when the customer asks about more than one day: a week, a month, 'the last four weeks', 'day by day', 'what did I eat last week'. from and to are their local dates (YYYY-MM-DD). Never for a single day: if from would equal to — today, yesterday, one date — call day_summary instead. It returns each meal and its items, which this tool does not, and this tool refuses the call. granularity: 'total' for an overall answer; 'days' (default) for daily values through 31 days; 'meals' for every meal through 31 days. Longer visual ranges use weekly averages through one year and monthly averages after that. Every aggregate is per recorded day. Missing days have null values, never zero. At most the latest two years are returned in one answer; requested_range and effective_range make that limit explicit. history_available_from is the first available IZeat history, not necessarily the account creation date. When interactive reports are enabled for the account, the result is accompanied by a complete IZeat period component containing coverage, averages and the appropriate time series. Text-only clients receive the same typed nutrition data. Do not rank days unless the customer asks. Returns a typed public period report without storage identifiers. Example: period_summary { "from": "2026-08-08", "to": "2026-09-04" }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam (review@izeat.app)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesThe customer's day as they said it — today, yesterday, 3 days ago, a weekday — or YYYY-MM-DD, last day included; must differ from from — one day is day_summary
fromYesThe customer's day as they said it — today, yesterday, 3 days ago, a weekday — or YYYY-MM-DD, first day included; must differ from to — one day is day_summary
granularityNototal: averages only · days (default): one line per recorded day · meals: every meal

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
dataYes
statementYesCustomer-visible IZeat receipt. Its value begins with "IZeat ·".

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/openWorldHint=false/destructiveHint=false, and the description adds substantial behavior beyond that: missing days are null not zero, a hard two-year cap surfaced via requested_range/effective_range, history_available_from semantics, default granularity, 'do not rank days unless asked', and even that the tool refuses a single-day call. This is unusually rich disclosure.

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-loaded with the core answer and the sibling exclusion, and most sentences earn their place. However, it runs long and the closing 'statement is the customer-facing IZeat message' paragraph explains a return field despite an output schema existing, which is tangential to tool selection.

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?

For a 3-parameter read tool with an output schema, the description covers the routing decision, range limits, null-vs-zero semantics, granularity degradation, and report components. Nothing an agent needs in order to call it 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 the baseline is 3, but the description adds genuinely new semantics: local-date format for from/to, inclusive bounds, and the range-length thresholds that silently change granularity behavior (31 days, one year). It stops short of restating enum semantics, leaving that to the schema, which is appropriate.

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 ('Returns what was recorded between two dates') and enumerates the returned content: coverage, totals, per-recorded-day average, target timeline, and day/week/month/meal rows. It explicitly names the sibling it is not (day_summary) and the condition that separates them, so an agent can route without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use triggers in customer phrasing ('a week', 'the last four weeks', 'day by day', 'what did I eat last week'), an explicit exclusion ('Never for a single day... call day_summary instead'), and granularity-selection guidance tied to range length (days/meals through 31 days, weekly averages through a year, monthly after). Alternatives and conditions are fully spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources