freddy

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.

accept_terms

Private MCP Apps connection-card helper. Models must never call this tool directly.

connection_status

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.

connect_source

Disconnect a data source and wipe synced data for it. Confirm with the user before calling — this is destructive and the user must re-authorize to reconnect.

disconnect_source

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.

get_profile

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. Daily aggregates of per-reading data are available as `_avg`/`_min`/`_max` metrics. 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: <name>" (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.

list_metrics

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.

query_metrics

Private MCP Apps connection-card helper. Models must never call this tool directly.

resume_question

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.

sync_source