Connect your wearables, rings and training apps, then ask your AI about your own health data.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 9 tools
The core tools (connect_source, disconnect_source, sync_source, list_metrics, query_metrics, get_profile, accept_terms) each target a distinct action, and descriptions explicitly disambiguate list vs query and connect vs accept. The one weak spot is the pair connection_status and resume_question, which carry near-identical descriptions ('Private MCP Apps connection-card helper. Models must never call this tool directly') and are indistinguishable from each other.
Seven of nine tools follow a clean verb_noun snake_case pattern (connect_source, disconnect_source, sync_source, list_metrics, query_metrics, get_profile, accept_terms). The two outliers, connection_status and resume_question, are noun_phrase names, but that deviation is readable and consistent with them being non-model-facing app helpers.
Nine tools is a sensible scope for a health-data aggregation server and avoids bloat. Two of the nine are explicitly forbidden to the model, so the effective surface is really seven tools, which is still reasonable but means part of the count is padding rather than capability.
The lifecycle is largely covered: consent, connection CRUD (connect/disconnect with optional data deletion), sync, profile read, and metric discovery plus retrieval with raw/sample options. Minor gaps remain — there is no tool to update profile or preferences (language, plan) and no standalone data-deletion operation outside the disconnect flag, so an agent asked to change settings hits a dead end.
Record the user's acceptance of freddy's current Terms of Service and Privacy Policy. ONLY call this tool AFTER the user has explicitly stated they agree to the updated terms — for example, after they have said 'I agree', 'accept', 'yes, accept the new terms', or similar. Do not call this tool automatically or on the user's behalf. If the user has not seen the policy summary yet, show them the gate message from the previous tool call's response (or fetch https://freddy.coach/terms) BEFORE asking for their consent. If the user is unsure or wants to read the full text, do not call this tool — point them at the dashboard URL or the public Terms/Privacy pages. If the user has explicitly agreed to BOTH the Terms/Privacy AND to freddy collecting and processing their health data, also pass health_data: true. Otherwise omit health_data or pass false, and tell the user the separate health-data consent is still outstanding: freddy asks for it the next time they connect a data source, and some features stay off until they give it. Do NOT tell them the dashboard will prompt them for it, because it will not.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be literal `true`. The presence of this field is a syntactic guard against the LLM calling this tool reflexively. | |
| version | Yes | The exact policyVersion string the user is accepting, e.g. "2026-11-06". Must match the version returned in the consent-required error. Including the version explicitly prevents accidentally accepting a future bump. | |
| health_data | No | Optional. Set to `true` only if the user has separately and explicitly consented to freddy collecting and processing health data from the providers they choose to connect. This consent is distinct from Terms/Privacy acceptance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-read-only, non-destructive, closed-world write, so the description's job is to add consent-specific behavior, which it does: consent must be explicit, the gate message must precede the ask, and the health-data flag is a separate consent that is requested later at data-source connection time. It even corrects a likely wrong assumption ('Do NOT tell them the dashboard will prompt them for it, because it will not'). It stops short of describing what the recorded acceptance triggers or how failure/version mismatch surfaces.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action, then the gating conditions, then the health_data branch — a logical order for an agent to follow. Every sentence is operational rather than filler, though the consent prohibition is stated twice ('ONLY call this tool AFTER...' and 'Do not call this tool automatically') and the health-data paragraph is dense enough to be harder to scan than the rest.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A consent-recording mutation with three params, full schema coverage, and no output schema. The description covers the precondition (user saw the policy summary), the exact consent language required, the separate health-data branch with its downstream consequence, and the user-facing follow-up message — everything an agent needs to call it correctly and not over-call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already explains confirm, version, and health_data thoroughly, so the baseline is 3. The description adds procedural meaning the schema does not: pass health_data true only on separate explicit health-data consent, otherwise omit or pass false, and in that case tell the user the consent is still outstanding and that some features stay off. It does not restate the version-matching requirement, but the schema covers that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Record the user's acceptance of freddy's current Terms of Service and Privacy Policy.' No sibling tool (connection_status, connect_source, get_profile, etc.) covers consent, so the boundary is unambiguous from the name plus this sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives the when: only after the user has stated agreement, with quoted examples ('I agree', 'accept', 'yes, accept the new terms'). Explicitly gives the when-not: do not call automatically or on the user's behalf, do not call if the user is unsure or wants the full text, and instead point them at the dashboard or public Terms/Privacy pages. It also names a prerequisite (show the gate message or fetch the terms URL first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Private MCP Apps connection-card helper. Models must never call this tool directly.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | ||
| resume_token | No |
| Name | Required | Description |
|---|---|---|
| connection | Yes | |
| sourceLimit | Yes | |
| resumeAvailable | Yes | |
| selectedProvider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, non-destructive, and closed-world, so safety is covered structurally. The description adds the useful behavioral fact that this is a UI-internal helper, but it says nothing about what the call returns or why provider/resume_token exist, and an output schema exists so return detail is partly excused.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, and the most important constraint (do not call) is stated immediately after the one-line identity. Nothing needs trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deliberately non-agent-facing helper the description does the minimum: it warns the model away and an output schema exists. However, it leaves the agent with no fallback instruction about which sibling to use for connection checks, which matters given the crowded sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two parameters (provider, resume_token), so the description carries the full burden and adds nothing at all about either. The agent cannot tell what values are valid or how resume_token relates to provider.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"Private MCP Apps connection-card helper" identifies a resource area and hints at a UI-side role, but it never says what the tool actually does (check a provider connection? return a card?), so the verb is missing. The critical scoping line, that models must not call it, is clear, but the operational purpose is only implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit and unambiguous when-not: "Models must never call this tool directly." That is strong routing guidance. It does not name what an agent should use instead among the siblings (connect_source, disconnect_source, resume_question), which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect a wearable, ring, CGM, training platform, gym log, Apple Health, or Health Connect. Returns an interactive source picker plus a complete text fallback. OAuth approval and credentials always happen on freddy or the provider, never inside chat. When a health question triggered this tool, pass original_question so the card can restore it after the first sync.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider slug of the source to connect (uppercase enum, e.g. 'GARMIN'; lowercase + dashes like 'intervals-icu' also accepted). OAuth sources return an authorization URL to open; API-key and phone sources return instructions to finish on the freddy dashboard or app. An unknown slug returns the full list of connectable sources. | |
| original_question | No | When this connection interrupted a health-data question, pass the user's exact original question so the private connection card can restore it after first sync. Omit for a standalone connect request. This field deliberately has no schema maximum: questions over 2,000 characters are ignored so an oversized question never blocks the connection itself. The question is never written to analytics or logs. |
| Name | Required | Description |
|---|---|---|
| action | No | |
| providers | Yes | |
| connection | Yes | |
| sourceLimit | Yes | |
| resumeAvailable | Yes | |
| selectedProvider | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavioral context beyond the annotations: it returns an interactive picker plus a text fallback, and OAuth approval and credentials happen on freddy or the provider rather than in chat. That credential-handling disclosure is exactly the kind of thing annotations (readOnlyHint false, openWorldHint true, destructiveHint false) cannot convey on their own.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with what the tool connects, then return shape, then auth behavior, then the one parameter caveat. Little waste, though the original_question sentence duplicates schema text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what the tool does, what it returns, where the credential hand-off occurs, and the one conditional parameter. With an output schema present, return values need no further explanation, leaving nothing an agent needs in order to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters in depth (including the oversized-question and no-logging behavior). The description mostly restates the original_question guidance rather than adding new semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb ('Connect') plus an enumerated resource set (wearable, ring, CGM, training platform, gym log, Apple Health, Health Connect), which is far more concrete than a generic 'connect a source'. The connect verb separates it from siblings like sync_source, disconnect_source, and connection_status, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives conditional guidance for one parameter ('When a health question triggered this tool, pass original_question'), which implies the standalone-connect case by contrast. There is no explicit when-not guidance and no pointer to connection_status or sync_source for adjacent needs, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect a data source: freddy stops syncing it and removes the connection. Its stored data stays. With delete_data: true, freddy also deletes all of the source's data permanently. Confirm with the user before calling. To connect the source again, the user signs in to it again.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider slug of a connected source (uppercase enum, e.g. 'GARMIN'; lowercase + dashes also accepted). An unknown slug returns the full list of valid sources. | |
| delete_data | No | true also deletes all of this source's stored data permanently. Leave it out to keep the data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds genuinely useful nuance beyond that: data is retained by default, irreversible deletion happens only with delete_data: true, and reconnection requires the user to sign in again. That is solid added context, though there's no mention of whether in-flight syncs are cancelled or what happens on partial failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the action and its effects, followed by the destructive variant, the confirmation warning, and the recovery path. Each sentence carries information; the only mild redundancy is repeating the delete_data behavior already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive mutation with no output schema, the description covers the required confirmation, default-retention behavior, the permanent-deletion branch, and the reconnection story. Nothing an agent needs to call this safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 in the input schema, including the delete_data default. The description restates the delete_data consequence in slightly stronger terms ('deletes all of the source's data permanently') but adds no provider-slug format or validation guidance beyond what the schema says. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Disconnect a data source') and immediately distinguishes itself from connect_source by naming the inverse operation. It also spells out the two-part effect (stops syncing, removes connection) so the agent knows exactly what the operation means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear when-to-use cue plus a confirmation requirement ('Confirm with the user before calling') and a reversal path ('To connect the source again, the user signs in to it again'), which implicitly points at connect_source. It stops short of explicitly naming connect_source or stating when not to disconnect (e.g., mid-sync).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return this user's freddy account profile: name and email address, account id, signup date, language preference, plan tier and billing status, query-window and source-slot entitlements, accepted policy versions, and one line per connected data source with its status, connection date, last sync, last data received, error state and stored-data date range. Call it once at the start of a conversation to learn who the user is and what data exists; use list_metrics to discover metric names and query_metrics to read values.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| account | Yes | |
| consent | Yes | |
| sources | Yes | |
| activeSyncs | Yes | |
| dataCoverage | Yes | |
| entitlements | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered structurally; the description adds the non-obvious behavioral rule that this should be called once per conversation rather than repeatedly. It says nothing about authentication requirements, rate limits, or whether the data is cached or live, which is the remaining gap for an open-world read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads verb and resource before the field list, the second carries the routing guidance. The long enumeration of returned fields is partly redundant given a rich output schema exists, which costs it a point, but there is no filler or hedging.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only introspection tool with a full output schema, the description supplies everything an agent needs: what it returns, when to call it, and which siblings handle the follow-up questions. No operational detail required to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly avoids inventing options and instead spends its words on scope and timing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Return this user's freddy account profile') and then enumerates exactly what comes back: identity fields, plan tier and billing status, entitlements, accepted policy versions, and per-source status. It is immediately distinguishable from siblings like connection_status (which covers a single source) and list_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit timing instruction ('Call it once at the start of a conversation') plus the reason ('to learn who the user is and what data exists'), then names the two alternatives (list_metrics, query_metrics) with the condition that selects them. Nothing about when to reach for this tool is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Continue 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`. | |
| provider | No | List 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. |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | End date (inclusive) as YYYY-MM-DD. Defaults to today. Only used when `start` is set. | |
| days | No | Number of days to look back (default: 7, max: 365). For ranges beyond 1 year, use `start` and `end` instead. | |
| range | No | With 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. | |
| start | No | Start 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. | |
| device | No | Filter 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. | |
| metrics | Yes | Metric 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_id | No | Select 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. | |
| granularity | No | Return 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_raw | No | Include 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_window | No | For 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_resolution | No | For 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. |
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.
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.
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.
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.
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.
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.
Private MCP Apps connection-card helper. Models must never call this tool directly.
| Name | Required | Description | Default |
|---|---|---|---|
| resume_token | Yes |
| Name | Required | Description |
|---|---|---|
| restored | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false with destructiveHint=false and openWorldHint=false, and nothing in the description contradicts that. The description adds that this is a private, connection-card-internal operation, which is useful behavioral framing, but it doesn't disclose what state the restore mutates or what the resume_token is bound to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the most important constraint (never call directly) placed second but unmistakably. No filler, though the first sentence could carry slightly more concrete purpose information in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explained, and the tool is simple with a single string parameter. For a tool agents are forbidden to call, the description is nearly sufficient, but a reader still cannot say what 'resume' does beyond the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one required parameter, resume_token, with 0% schema description coverage and no enum, and the description says nothing about it. The only hint is the tool name implying a token from a prior suspension, which is inference rather than documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool's role as a 'Private MCP Apps connection-card helper' and the title adds 'Restore original question', so the domain is clear. However, it never states what 'resume' actually restores or returns, so the verb+resource pairing is only inferable from the title, not the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an unambiguous exclusion: 'Models must never call this tool directly.' That is exactly the routing signal an agent needs for this tool, so misuse is prevented. It stops short of 5 because it doesn't say who does invoke it or which sibling handles the agent-facing equivalent of resuming a question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trigger an incremental sync for a connected provider. Returns immediately; the sync runs in the background. Use this if the user wants the latest data fetched right now (e.g. after a workout) instead of waiting for the daily sync.
| Name | Required | Description | Default |
|---|---|---|---|
| provider | Yes | Provider slug of a connected source (uppercase enum, e.g. 'GARMIN'; lowercase + dashes also accepted). An unknown slug returns the full list of valid sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, open-world behavior; the description adds the critical async contract that the call returns immediately and work continues in the background. That is exactly the kind of fact annotations cannot express. It stops short of covering repeated-call behavior, concurrency, or any throttling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and the async behavior before the usage hint. No filler or restated title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter trigger tool with no output schema, the definition covers action, timing, and motivation. It could have said what the immediate response contains (e.g. confirmation or job handle), which is the one remaining gap given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the provider slug format, enum casing, and unknown-slug fallback are all documented in the schema. The description adds nothing about the parameter, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource ("trigger an incremental sync for a connected provider") and makes the scope explicit as incremental rather than full. An agent can distinguish it from connect_source, connection_status, and the read-oriented query tools without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete when-to-use condition: the user wants fresh data now, e.g. after a workout, rather than waiting for the daily sync. It implicitly contrasts with the scheduled sync but does not name any sibling tool or state when not to call it (e.g. already-syncing state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
accept_terms1 field changedInput schema / properties / version / descriptionPrevious value: -"The exact policyVersion string the user is accepting, e.g. \"2026-10-31\". Must match the version returned in the consent-required error. Including the version explicitly prevents accidentally accepting a future bump."New value: +"The exact policyVersion string the user is accepting, e.g. \"2026-11-06\". Must match the version returned in the consent-required error. Including the version explicitly prevents accidentally accepting a future bump."disconnect_source1 field changedInput schema / properties / delete_dataAdded value: +{
+ "description": "true also deletes all of this source's stored data permanently. Leave it out to keep the data.",
+ "type": "boolean"
+}accept_termsconnect_sourceconnection_statusdisconnect_sourceget_profilelist_metricsquery_metricsresume_questionsync_sourceYour Garmin, Oura, WHOOP, Hevy and 35 more fitness apps, queryable from your own AI.
Connect your health, fitness, nutrition, sleep, and wearable data to your AI assistant.
Ask your AI about your fitness: activities and data from Garmin, COROS, Strava, GPX and more
Your labs, wearables, DNA and notes as one health record your AI agent can read (OAuth 2.1).
Add one secure layer between your agents and this server.
