Skip to main content
Glama

list_metrics

Read-only

List health metrics available for this user. Metrics are grouped under a Source: <name> header per connected source; each line gives the metric name, record count, date range, unit, and the devices that wrote it. Metrics flagged [raw available] carry a full JSON payload (per-exercise sets, hypnograms) that can be fetched via query_metrics with include_raw: true. Metrics flagged [raw-only — fetch with include_raw] are intra-day sample bundles (e.g. activity_HR_samples for Suunto); the data lives in the raw payload, not in numValue. For these, request include_raw to get the ts/v arrays. For a daily figure of per-reading data, pass granularity to query_metrics: freddy computes it from the readings on request. Older days can also hold _avg/_min/_max rows that freddy stored before. For Apple Health cumulative metrics (steps, energy, distance, …) and Health Connect activity metrics (steps, distance, energy, floors, elevation, wheelchair pushes) the <metric>_total twin under device "Merged" is the hub's own de-duplicated daily total across every app that writes into it; it is NOT the sum of the per-app rows. Prefer it for a daily figure, and never add the per-app rows of the bare metric together. Health Connect does not de-duplicate hydration or nutrition, so those have no twin. (Suunto's _total names are plain daily sums.) Lines may show "device: " (or "devices: …" with per-device counts) when a source reports data from more than one device; pass that device to query_metrics to filter. Pass provider to list one source only — worth doing when the response says a source was not fully listed, or to keep the response small on an account with many sources. 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
afterNoContinue a truncated listing: return only metrics after this name. Pass the value the previous response's continuation hint gave you, together with the same `provider`.
providerNoList only this source (e.g. 'garmin', 'oura', 'apple-health'). Omit to list every connected source. Use it to follow up when a response reports that a source was not fully listed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, openWorld, non-destructive), and the description adds substantial behavior: the per-source grouped output format, what each line contains, the meaning of `[raw available]` vs `[raw-only — fetch with include_raw]` flags, legacy `_avg`/`_min`/`_max` rows, device-line formatting, and truncation. The `_total` de-duplication warning ('NOT the sum of the per-app rows ... never add the per-app rows of the bare metric together') is exactly the kind of correctness-critical trait annotations cannot express.

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?

Purpose is front-loaded in the first sentence, but the body is a dense, unstructured block mixing output format, flag semantics, dedup rules, pagination, and brand attribution with no headings or ordering by importance. There is mild redundancy, e.g. the raw-payload guidance is stated twice ('can be fetched via query_metrics with include_raw: true' then 'For these, request include_raw to get the ts/v arrays').

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?

Covers everything an agent needs to call this tool correctly: no required params, how the response is organized, how to interpret flags, how to continue a truncated listing, how to narrow by provider, and which follow-up tool/params to use. With no output schema, the description carries the output-format burden and does so thoroughly.

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%, so both parameters are already documented, and the description still earns credit by explaining the motive for `provider` (response may report a source was not fully listed; keep responses small) and echoing the continuation contract of `after` with the same provider. It does not add value-format or enumeration detail beyond the schema's own examples, so it sits just above the baseline.

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+resource ('List health metrics available for this user') and immediately frames the downstream relationship to query_metrics, which is the sibling that actually fetches values. An agent can distinguish discovery (this tool) from retrieval (query_metrics) 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides strong conditional routing: pass `provider` when a response says a source was not fully listed or to shrink responses on multi-source accounts; request `include_raw` for `[raw available]` and `[raw-only]` metrics; pass `granularity` to query_metrics for daily figures from per-reading data. It never states a case where this tool should NOT be used, and the guidance is buried rather than structured, so it falls short of a clean 5.

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