Skip to main content
Glama

IZeat

Day summary

day_summary
Read-only

Returns the daily summary: everything recorded for one date — each meal with its items (quantity, calories, macros, source per item), the day's totals, the target in force that day, and the signed difference (target − total) per nutrient. Use it for any single day — today's summary, yesterday's, one date: when the customer asks for their daily summary, their day, their balance for the day, what they ate, where they stand, or how much is left. Omit date for today; otherwise pass their word (yesterday, 3 days ago, Tuesday) or YYYY-MM-DD only when they said the full date — never compute one yourself. Reads one day only. For several days or a period ('last four weeks', 'this month', 'day by day'), use period_summary. Totals are computed from recorded meals. Each meal says whether its values came from a label, the customer, or an estimate; only llm_estimate is estimated. Relay over and under neutrally. When interactive reports are enabled for the account, the result is accompanied by a complete IZeat day component containing totals, macros, every meal and its items. Text-only clients receive the same typed nutrition data. A narrow question does not require the complete report unless the customer requests it. Returns a typed public day report without storage identifiers. Example: day_summary { "date": "2026-09-03" }. 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
dateNoOmit for today. Otherwise the customer's own word — yesterday, 3 days ago, a weekday — or YYYY-MM-DD only when they said the full date

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish a safe read (readOnlyHint true, destructiveHint false, openWorldHint false), and the description adds real behavioral context on top: totals are computed from recorded meals, per-item source attribution where only llm_estimate is estimated, a neutrality instruction for over/under, and the interactive-component vs text-only rendering difference. No contradictions with the 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?

Front-loaded and mostly information-dense (purpose, date handling, alternative, behavior), but the closing paragraph about 'statement' being the customer-facing IZeat message — including write-operation behavior — is generic boilerplate unrelated to this read-only, one-param tool and does not earn its place. The surrounding verbosity is tolerable but not tight.

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 no explanation, yet the description still signals the report is typed and free of storage identifiers. Combined with full annotation coverage and complete parameter documentation, an agent has everything needed to call this correctly.

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% and the single date param is already documented there. The description reinforces the accepted formats and adds a rule not in the schema — 'never compute one yourself' — telling the agent to pass the customer's own wording rather than derive a date, which materially reduces malformed calls.

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?

Opens with a specific verb and resource — 'Returns the daily summary: everything recorded for one date' — and then enumerates the exact payload (meals+items with macros/source, day totals, target in force, signed per-nutrient difference). It explicitly differentiates itself from the period_summary sibling for multi-day requests, so the agent can pick it 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 trigger phrases ('daily summary', 'their day', 'how much is left'), the today-case (omit date), and the named alternative for multi-day/period requests ('use period_summary'). It also adds a conditional rule — 'A narrow question does not require the complete report unless the customer requests it' — which is genuine when/how guidance.

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