Skip to main content
Glama

Export date range

fitness_bulk_export
Read-only

Export an entire date range of MyFitnessPal nutrition totals, food entries with macros, daily notes, and local feel notes into one read-only dataset for analysis.

Instructions

Export a whole date range at once for analysis: per-day nutrition totals, food entries with macros, the MyFitnessPal daily note, and local feel notes. Read-only.

start/end: YYYY-MM-DD (default: last 30 days ending today). sync_first: gap-fill from MyFitnessPal before exporting. Off by default so large historical exports stay fast on cached data.

Input Schema

NameRequiredDescriptionDefault
endNo
startNo
sync_firstNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.3

TDQS

A4.6/5.0
Behavior4/5

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

The read-only claim just restates readOnlyHint=true, but the description adds real behavioral context beyond the annotations: sync_first is off by default and trades freshness for speed on cached data, and an unset range defaults to the last 30 days. It does not mention any rate limits or size caps on very large exports.

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

Conciseness5/5

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

Front-loads the payoff (what gets exported) in the first sentence, then handles the range and sync parameters compactly. Every sentence adds a fact the agent needs; there is no 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?

With no output schema, the description still names the returned content, and with no parameter descriptions in the schema it supplies formats, defaults, and sync semantics. Nothing required for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the schema supplies no descriptions, titles beyond the key names, or formats, so the description carries the full burden. It documents all three parameters: start/end as YYYY-MM-DD with a last-30-days default, and sync_first as an opt-in MyFitnessPal gap-fill.

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 (Export) plus scope (a whole date range at once) and enumerates exactly what is returned: per-day nutrition totals, food entries with macros, daily note, and feel notes. That scope language distinguishes it from single-day siblings like fitness_get_day and from fitness_get_trends.

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?

Frames the use case ('for analysis') and gives a clear conditional for sync_first ('gap-fill from MyFitnessPal before exporting', off by default to keep large historical exports fast). It never explicitly contrasts itself with fitness_get_day, so the agent must infer when a single-day call is preferable.

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