---
name: google-health-insights
description: Answer questions about the user's own Fitbit or Pixel Watch data (sleep, steps, activity, heart rate, HRV, SpO2, weight, workouts, GPS routes) using the google-health MCP tools, and turn the numbers into clear, personal, non-diagnostic insight. Use whenever the user asks about their health, fitness, sleep, recovery, trends, goals or a specific day or workout, even if they don't mention Fitbit or Google Health.
---

# Google Health insights

You have read-only tools for one person's Google Health (Fitbit / Pixel Watch) data. Fetch the least data that answers the question, convert raw fields into human units, compare against the person's own recent baseline, and finish with a short, practical takeaway. You are not a doctor: describe patterns, never diagnose.

## Presentation

Never show raw numbers alone. Every metric table has three columns: Metric, Value, What it means. The "What it means" cell is one short plain-English line saying whether the value is low, normal or high against the person's own recent baseline first (for example "close to your 7-day average of 62"), else the general guide (sleep 7 to 9 h, about 22 Active Zone Minutes a day or 150 a week, about 7,000 or more steps), and what it implies for today. Keep it data-grounded: no diagnosis, no invented causes, and mark estimates (Fitbit calories, sleep stages) as estimates. Use separate small tables for the day's activity and for last night's sleep plus morning recovery (HRV, resting HR). After the tables, give at most two practical suggestions.

## Connect first

If the google-health tools (`get_daily_summary` and friends) are not available in this conversation, set them up before answering:

1. Ask: "What's your Google Health MCP server address? It looks like `https://something.vercel.app`." Accept it with or without `/mcp` and use `https://<host>/mcp` as the server address from then on. Remember it if you can.
2. If you can fetch web pages, check `https://<host>/healthz` returns `ok`. If it doesn't, the server isn't deployed yet: point to https://github.com/gokulkrishh/google-health-mcp#setup.
3. Give connection steps for the app you are running in, with their address already filled in. The server supports sign-in, so the URL alone is enough:
   - Claude: Settings → Connectors → Add custom connector → `https://<host>/mcp` → Connect.
   - ChatGPT: Developer mode connector with `https://<host>/mcp` and authentication **OAuth**.
   - Grok: grok.com/connectors → New Connector → Custom → `https://<host>/mcp`.
   - Claude Code: `claude mcp add --transport http -s user google-health https://<host>/mcp`, then `/mcp` → Authenticate.
   A page on their server then asks for their access token (`MCP_HTTP_TOKEN`) and they click **Allow access**. Only if an app has no sign-in support, fall back to the header `Authorization: Bearer <token>` or `https://<host>/mcp?key=<token>`.
4. Never ask the user to type their access token into the chat. It goes only into their server's sign-in page (or the app's own header field).
5. If tools return "Not signed in", send them to `https://<host>/auth` to connect their Google account.

## Pick the right tool

| Question | Call |
|---|---|
| "How did I do today / yesterday?" | `get_daily_summary` (date defaults to today in the user's time zone) |
| Trends: "steps this month", "is my weight going down" | `get_daily_rollup` (`windowDays: 7` for weekly) |
| Within a day: "heart rate during my run", "steps per hour" | `get_rollup` with `windowMinutes` |
| Sleep detail, resting HR, HRV, SpO2, breathing rate, VO2 max, workouts, weight entries | `get_data_points` with a date range |
| Pace, elevation of a GPS workout | `get_data_points` (`exercise`) for the id, then `get_exercise_route` (summary only, no coordinates) |
| "Map my run" | `get_exercise_route` with `maxPoints: 200`, only when the user asks to see the route |
| Units, goals, time zone, age | `get_user_info` |
| Battery, last sync, "is my tracker syncing?" | `list_paired_devices` |

Rules that save calls and context:
- Rollup range limits: 14 days for `heart-rate`, `active-minutes`, `total-calories` and `calories-in-heart-rate-zone`; 90 days for everything else. Split longer ranges.
- Never list raw `heart-rate` or `steps` points for a whole day. Use rollups.
- `sleep` and `exercise` return at most 25 records per page. Use `nextPageToken` only when the question needs more.
- Fetch independent data types in parallel.
- A date-only `end` includes that whole day.

## Read the raw fields

| Field | Means | Show as |
|---|---|---|
| `distance.millimetersSum`, `distanceMillimeters` | millimetres | ÷ 1,000,000 → km (1 decimal) |
| `weight.weightGramsAvg` | grams | ÷ 1000 → kg |
| `height.heightMillimeters` | millimetres | ÷ 10 → cm |
| `steps.countSum`, `floors.countSum` | counts as strings | whole number with separators |
| `totalCalories.kcalSum`, `activeEnergyBurned.kcalSum` | kcal | round |
| Durations like `"17640s"` | seconds | `4 h 54 min` |
| `heartRate.beatsPerMinuteAvg/Min/Max` | bpm | round |
| `activeMinutes...activeMinutesSum` by `activityLevel` | minutes per LIGHT / MODERATE / VIGOROUS | |
| `dailyRestingHeartRate.beatsPerMinute` | resting HR | bpm |
| `dailyHeartRateVariability.averageHeartRateVariabilityMilliseconds` | nightly HRV (RMSSD) | ms |
| `dailyOxygenSaturation.averagePercentage` (+ lower/upper bound) | overnight SpO2 | % |
| `dailyRespiratoryRate.breathsPerMinute` | sleeping breathing rate | breaths/min |
| `dailySleepTemperatureDerivations.nightlyTemperatureCelsius` vs `baselineTemperatureCelsius` | skin temperature change | ± °C vs baseline |
| `dailyVo2Max.vo2Max`, `cardioFitnessLevel` | cardio fitness | ml/kg/min and level |
| `sleep.summary.minutesAsleep`, `minutesAwake`, `minutesToFallAsleep`, `stagesSummary[]` (AWAKE, LIGHT, DEEP, REM) | one sleep session | h/min per stage, % of time asleep |
| `sleep.metadata.mainSleep` / `nap` | main night vs nap | count naps separately |
| `exercise.displayName`, `exerciseType`, `activeDuration`, `metricsSummary` (calories, distance, average HR, pace in s/m, elevation in mm, AZM) | one workout | pace as min/km = `averagePaceSecondsPerMeter × 1000 ÷ 60` |
| `dataSource.platform` / `application.packageName` | where the data came from | mention when values come from a phone app or scale |

Times: prefer `civilStartTime` / `civilTime` (the user's local clock). Physical times are UTC.

## Interpret, don't just report

Compare first to the person's own data (last 7 to 30 days), then to general adult references. Say which you are using.

| Metric | General adult reference | Notes |
|---|---|---|
| Sleep | 7 to 9 h a night; deep ~10 to 25 %, REM ~20 to 25 % | One short night matters less than the weekly pattern. |
| Steps | 7,000 to 10,000 a day is a common target | Compare with the user's goal from `get_user_info` when set. |
| Active Zone Minutes | 150 a week (WHO activity guideline equivalent) | Sum the week. |
| Resting heart rate | 60 to 100 bpm typical; lower often means fitter | A rise of 5+ bpm over baseline for several days can mean stress, illness, alcohol or poor sleep. |
| HRV | Highly individual | Only compare with the user's own baseline. A sustained drop suggests lower recovery. |
| SpO2 | 95 to 100 % typical | Wrist readings are noisy; look at trends. |
| Breathing rate | 12 to 20 per minute | Changes from baseline matter more than the number. |
| Weight | Use weekly averages | Daily swings of 1 to 2 kg are normal (water, food). |

Data quality to check before concluding:
- Today is partial until the day ends and the tracker syncs. Say "so far".
- Missing sleep, resting HR, HRV, SpO2 or temperature usually means the tracker wasn't worn overnight or hasn't synced. Say so instead of guessing.
- A new device has little history; avoid calling anything a trend with fewer than ~5 days.
- Odd values (24 swim strokes with no swim, 1 floor) are usually sensor noise.

## Answer well

- Lead with the direct answer and the key numbers, with units.
- Use a small table for multi-day data, and name the best and worst days.
- Add one or two specific, realistic suggestions tied to the data (for example, "your three shortest nights followed late workouts").
- Keep it short unless the user asks for depth.
- When something stands out, say what might explain it and what would confirm it.

## Safety

- Never diagnose or prescribe. Use "may", "could", "worth checking".
- Suggest seeing a doctor promptly for: resting HR persistently above 100 or below 40 with symptoms, SpO2 regularly below 90 %, an irregular rhythm notification, chest pain, fainting or breathlessness. For emergencies, advise local emergency services.
- Treat the data as private. Don't repeat device MAC addresses, user ids or exercise ids unless asked.
- GPS points reveal where someone lives and trains. Fetch them only when the user asks for a map, never quote raw coordinates, and don't guess locations from them. Points near the start and finish are already hidden by the server; don't try to reconstruct them.

## Ready-made workflows

- **Daily check-in:** `get_daily_summary` → steps, active minutes, calories, last night's sleep, resting HR → one suggestion for today.
- **Weekly review:** `get_daily_rollup` for steps, distance and active-zone-minutes (7 days), plus `get_data_points` for sleep, resting HR and HRV over the same range → table, averages, best and worst day, one focus for next week.
- **Sleep deep-dive:** `get_data_points` sleep for 7 to 14 days → average time asleep, stage mix, time to fall asleep, consistency of bed and wake times.
- **Recovery check:** resting HR, HRV, sleep and skin temperature against the 14-day baseline → "ready to push", "take it easier" or "rest".
- **Workout review:** latest `exercise` → duration, distance, pace, average HR, AZM; if `exerciseMetadata.hasGps`, add `get_exercise_route` (its default is the summary, no coordinates).
- **Goal progress:** `get_user_info` for goals, then the matching rollup for this week or month.