Skip to main content
Glama

query_metrics

Read-only

Fetch health data for specific metrics by name. Metric names are provider-specific and follow each provider's own field-name conventions (e.g. activity_* / wellness_* for Intervals.icu, polar_* for Polar, workout_* for Hevy, sleep_summary_* for Withings). They are NOT common English words. Always call list_metrics first in a session to discover the exact names available for this user — names that aren't in that list return zero rows. Returns scalar values grouped by date. The window is ONE contiguous range (days, or start+end), so to compare specific non-adjacent dates make one call per date with start and end both set to that date — a single wide range spanning them returns newest-first and can truncate the older date away, which is not the same as that date having no data. When include_raw is true, also returns the full JSON payload for each record (per-exercise sets, hypnograms, intra-day sample arrays). Non-sample raw is capped at 50 records per request. For intra-workout sample metrics (names ending in _samples), include_raw returns a downsampled overview by default (tighter record cap — narrow the range if asked to); pass raw_resolution: "full" for every sample of a single workout, or sample_window: { from_sec, to_sec } to zoom a segment of a long workout at full resolution. Each sample row shows 'id: <…>' — pass that as source_id to select one of several same-day workouts for a full or windowed read. When you present Garmin data to the user, attribute it as "Garmin [device model]" (or just "Garmin" when no device is shown), per Garmin's brand requirements.

Input Schema

NameRequiredDescriptionDefault
endNoEnd date (inclusive) as YYYY-MM-DD. Defaults to today. Only used when `start` is set.
daysNoNumber of days to look back (default: 7, max: 365). For ranges beyond 1 year, use `start` and `end` instead.
rangeNoWith granularity: also return, per bucket, the share of readings below, inside and above this range (bounds inclusive), computed by freddy at the time of the call and not stored. Pass the range the user gives as their own target, in the metric's unit as list_metrics shows it; if the user has not given one, ask. The range applies only to rows in that unit.
startNoStart date (inclusive) as YYYY-MM-DD. When set, overrides `days`. Pair with `end` to bound the window. Useful for historical questions ('how was my training in Q1 2024') and for ranges longer than 1 year.
deviceNoFilter to a single source device. Device identifiers and per-device record counts are shown by list_metrics. Omit to return all devices. Also useful to reduce result volume for multi-device providers.
metricsYesMetric names to fetch (e.g. ['sleep_duration', 'hrv', 'steps']). For an Apple Health or Health Connect daily total prefer the `<metric>_total` twin (device "Merged") over the per-app rows of the bare metric.
source_idNoSelect ONE specific workout/record by its source id (shown in sample results as 'id: <…>'). This is how you pick one of several same-day workouts for a full-resolution or windowed sample read — date filters alone can't disambiguate two workouts on the same day.
granularityNoReturn one figure per local day, week (Monday start) or calendar month instead of individual rows: avg/min/max/sum/count per metric, computed by freddy from the stored readings at the time of the call and not stored. Use "day" for a daily figure of a per-reading metric (glucose, SpO2, heart rate), and "week" or "month" for multi-month or multi-year questions. Cannot be combined with include_raw.
include_rawNoInclude the full raw JSON payload for each record (per-exercise sets for workouts, per-stage hypnogram for sleep, per-sample arrays for continuous HR). Off by default. Raw payloads can be 5 to 30 KB each, so prefer narrower windows when enabling this.
sample_windowNoFor sample metrics with include_raw: return full-resolution samples only for the [from_sec, to_sec] window (seconds from workout start). Use to inspect a segment of a long workout at full fidelity.
raw_resolutionNoFor intra-workout sample metrics (names ending in _samples) with include_raw: 'overview' (default) returns a peak-preserving downsample (~240 points/stream) — best for 'how did my heart rate change through the session'. 'full' returns every sample but is capped to ONE workout; for a long workout use sample_window to zoom a segment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover readOnly/openWorld/non-destructive, but the description adds substantial non-obvious behavior: newest-first ordering can truncate older dates within a wide range, a 50-record raw cap on non-sample payloads, downsampling to ~240 points for `_samples` metrics by default, a one-workout cap for `full` resolution, and a Garmin attribution requirement.

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 purpose, then constraints, then advanced raw/sample behavior — a sensible ordering with essentially no redundant sentences. It is still a dense wall of text covering many edge cases, and would read better as short bullets, which keeps it below 5.

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?

Eleven parameters, nested objects, and no output schema — the description compensates by stating what is returned ('scalar values grouped by date'), how granularity changes the shape, and what raw payloads contain. Nothing an agent needs to call this correctly appears absent.

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 description coverage is 100%, so the baseline is 3, but the description adds meaning not in the schema: the `activity_*`/`wellness_*`/`polar_*`/`workout_*`/`sleep_summary_*` naming conventions, the `start`+`end` pairing trick to isolate a single date, and how `source_id` disambiguates same-day workouts. It does not add much to `range` or `device`, hence 4 rather than 5.

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+resource ('Fetch health data for specific metrics by name') and immediately constrains scope: metric names are provider-specific field names, not English words. This cleanly separates it from the sibling `list_metrics`, which exists purely for discovery.

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?

Explicitly states 'Always call `list_metrics` first in a session' and warns that unlisted names return zero rows. It also gives concrete when-to-use routing: one call per date for non-adjacent comparisons, `granularity` for multi-month questions, `include_raw` + `raw_resolution`/`sample_window`/`source_id` for intra-workout samples.

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