Wellness Project

list_wearable_data

Read-onlyIdempotent

List daily wearable data (steps, RHR, HRV, Zone Minutes / AZM including the vigorous-intensity breakdown, VO2max, calories eaten / dietary energy, calories burned / active energy / total energy expenditure, maintenance calories / TDEE, stress, and physiological vital signs reported by connected sources or manual overrides) within a date range. Use when the user asks about their step count, heart rate, HRV trends, vigorous minutes, calories eaten / dietary energy, calories burned, active or total energy expenditure, maintenance calories, TDEE, cardio fitness, blood glucose, vital signs, or any wearable metrics over time.

Zone Minutes (a.k.a. Active Zone Minutes) are shown as a daily total plus, when the per-zone breakdown is available, a moderate (1 pt/min) vs vigorous (2 pts/min — Cardio + Peak zones) split. The zone boundaries are personalized to the user's own resting and maximum heart rate, so they are not a fixed BPM.

Calories burned per day shows active + resting where both are known; when a device reports active energy with no resting figure, a resting estimate is derived from the user's profile BMR and labelled an estimate, never shown as measured. A trailing Maintenance (TDEE) line reports current maintenance calories and which method produced it (formula estimate vs. logged weight trend), or names the missing profile fields when TDEE can't be computed.

Maximum range: 31 days per call. For longer periods, make multiple calls with sequential date ranges.

INFER — do not ask:

start_date: default to 14 days ago
end_date: default to today

ROUTING: Exact daily values: list_wearable_data. Broad visual: show_health_overview. RHR/HRV: show_recovery. Steps: show_week_steps.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`end_date`	No	End of date range. Format: YYYY-MM-DD. Default: today.
`start_date`	No	Start of date range. Format: YYYY-MM-DD. Default: 14 days ago.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Human-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already mark it read-only and idempotent, and the description adds meaningful behavioral context: the 31-day maximum, sequential date-range calls, Zone Minutes scoring details, and the explicit rule that derived resting calories are 'labelled an estimate, never shown as measured.' It also explains how TDEE method or missing profile fields are surfaced. No contradiction with annotations.

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?

The description is long but tightly structured: opening scope, expansion of ambiguous metric semantics, operational limit, inference defaults, and routing rules. Each section adds information an agent needs, and the key verb/resource is front-loaded.

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?

Given the output schema exists and annotations cover safety, the description covers everything needed to call correctly: metric coverage, date-range limits, batching, estimation caveats, default inference, and sibling routing. No critical behavioral or usage element 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?

Although the schema already documents both parameters with defaults and formats, the description adds the actionable instruction 'INFER — do not ask', the default values, and the operational constraint that maximum range is 31 days per call with sequential calls for longer periods. This goes beyond the schema's structured parameter documentation.

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 description opens with a specific verb and resource: 'List daily wearable data' within a date range, and enumerates the exact metrics covered. The ROUTING section further distinguishes it from show_health_overview, show_recovery, and show_week_steps, so an agent can tell siblings apart.

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?

It provides explicit routing ('Exact daily values: list_wearable_data. Broad visual: show_health_overview. RHR/HRV: show_recovery. Steps: show_week_steps') and a 31-day call batching rule. However, the earlier 'Use when the user asks about ... HRV trends' is not fully reconciled with the ROUTING line that sends RHR/HRV to show_recovery, creating a minor ambiguity for that query type.

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

All Wellness Project tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.