fitatu-api

Overview Schema Source Related Servers Discussions Admin

Check progress against goals

get_progress

Read-onlyIdempotent

Track daily calorie and macro progress against goals for one day or up to 62 days, showing logged, target, and remaining amounts plus range totals.

Instructions

Progress against the user's goals, day by day, for one day or a range of up to 62 days: per day and for energy, protein, fat and carbohydrate, logged (every row, planned or eaten; null when nothing is logged that day), the goal (target in kcal for energy; target_min and target_max in g for a macro, which is on target between the two) and left (the goal minus logged, a macro's from target_max; negative when over). totals gives the whole range: logged, eaten (only rows ticked as eaten) and the goal summed over the days. Works on every account; without Fitatu Premium it reads each day on its own, so it covers at most 31 days, and each day has eaten too. Answers 'what is left today', 'did I hit protein' and how each day went; a summary of a week or month with weight and top foods, or of a longer range, is get_report (over 31 days without Fitatu Premium, get_range_summary).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to_date`	Yes	Day as YYYY-MM-DD; when the user says today, yesterday, this week or a weekday, call get_today and count from its date.
`from_date`	Yes	Day as YYYY-MM-DD; when the user says today, yesterday, this week or a weekday, call get_today and count from its date.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes
`data`	No
`error`	No	describe_error() of what went wrong; docs/AGENTS.md, Results and errors.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent and non-destructive, so safety is covered; the description then adds real behavioral context beyond them: the 62-day ceiling, the degraded behavior without Fitatu Premium (per-day reads, max 31 days, plus an eaten value), and that rows are null when nothing is logged. These are operational constraints the 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?

Purpose and scope are front-loaded, and every sentence carries information (null handling, macro target semantics, premium limits, alternatives). It is a dense single paragraph, however, and mixing return-field semantics with routing guidance makes it harder to scan than a short structured form would be.

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 spelled out, yet the description still explains the non-obvious semantics (goal is kcal for energy but target_min/target_max in grams for macros; 'left' for a macro is measured from target_max and goes negative when over). Combined with the range limits and premium caveat, an agent has everything needed to call and interpret this tool 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 both date parameters are documented there, so baseline 3 applies. The description goes beyond that by stating the meaningful bound on the pair (up to 62 days, 31 without Premium), which is genuinely parameter-relevant range semantics rather than a restatement of the schema.

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?

The opening names the exact resource and scope: goal progress per day, over one day or a range of up to 62 days. It also explicitly distinguishes itself from the two nearest siblings (get_report, get_range_summary) including the conditions under which each applies, so an agent can route without opening any 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?

Concrete example questions ('what is left today', 'did I hit protein') are given, plus an explicit alternative with its trigger condition: weekly/monthly summaries with weight and top foods go to get_report, and ranges over 31 days without Fitatu Premium go to get_range_summary. When-to-use and when-to-use-something-else are both covered.

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