What can you do with this server?

Summary: An MCP server that syncs your Google Health data into a local SQLite cache so an MCP client (e.g. Claude Code) can query it fast, offline, and without spending API quota. * Sync data — pull all or selected data types incrementally, backfill history with since/until, or repair gaps in the cache. * Query daily metrics — steps, calories, distance, floors; resting heart rate and zones; HRV; SpO2; breathing rate; active zone minutes; skin and core temperature; VO2 max; weight/body fat/BMI; height; food and water logs. * Inspect workouts — exercise sessions with duration, calories, heart rate, Google's metrics summary, splits, and GPS routes as TCX. * Examine sleep in detail — nightly totals and stages, or each session as Google recorded it with per-stage segments. * Review cardiac data — ECG classifications with optional raw waveforms, and irregular-rhythm notifications with triggering windows. * Analyze trends — weekly/monthly/quarterly aggregates and two-period comparisons (e.g. last_30d vs previous_30d). * Get lifetime stats — all-time totals and personal best days, with a coverage block bounding what's cached. * Check account state — profile, settings, irregular-rhythm enrolment, and paired devices with battery and last sync. * Control freshness — serve from cache by default, re-fetch a window with live=True, or run fully offline/cache-only with no credentials or network.

Which integrations are available for this server?

Provides access to Google Health data (heart rate, activity, sleep, weight, and more) with a local SQLite cache and query tools for health metrics.

de en es ko zh

google-health-mcp

by partymola

Overview Schema Source Related Servers Discussions Admin

Python

Local

google-health-mcp

MCP server for the Google Health API, with a local SQLite cache and trend analysis.

Designed for Claude Code and other MCP clients. Your data syncs to a database on your own machine, so queries are fast, work offline, and cost no API quota.

Features

Local SQLite cache - sync once, query instantly
Incremental sync - each run fetches only what is new, resuming from where the last one stopped
Offline mode - serve the cache with no credentials and no network at all
Trends - weekly, monthly or quarterly aggregates, and two-period comparisons
ECG - readings stored whole, waveform included, returned only when asked for
doctor - diagnoses a setup offline and read-only, without spending quota

Related MCP server: google-health-mcp-server

Data types

Tool	Data
`health_get_heart_rate`	Resting heart rate
`health_get_activity`	Steps, calories, distance, floors
`health_get_exercises`	Workouts: name, duration, heart rate, calories, Google's metrics summary, and splits on request
`health_get_exercise_route`	One workout's GPS route, as the TCX file Google exports
`health_get_sleep`	Duration, stages, sleep period
`health_get_sleep_sessions`	Each session as Google recorded it: metadata, summary, and every stage segment on request
`health_get_weight`	Weight, body fat %, one row a day
`health_get_weight_readings`	Every weigh-in and body-fat reading, as Google recorded each one
`health_get_height`	Height readings
`health_get_spo2`	Nightly blood oxygen saturation
`health_get_hrv`	Heart rate variability (RMSSD)
`health_get_azm`	Active zone minutes, with the per-zone breakdown
`health_get_breathing_rate`	Nightly breaths per minute
`health_get_skin_temperature`	Nightly variation from your baseline, and the absolutes behind it
`health_get_core_temperature`	Body temperature readings you logged by hand
`health_get_cardio_fitness`	VO2 max, where the device reports it
`health_get_food_log`	Food calories and water, where logged
`health_get_ecg`	Electrocardiograms: classification, average rate, duration, waveform on request
`health_get_irregular_rhythm`	Irregular-rhythm notifications and the windows that triggered them
`health_get_devices`	Paired devices, battery level, last sync
`health_get_profile`	Your profile, settings and irregular-rhythm enrolment, as Google returns them
`health_get_lifetime_stats`	Totals and best days over the cached history, with its coverage
`health_trends`	Aggregated averages and period comparisons

Requirements

Python 3.13+ (tested on 3.13, 3.14 and 3.15, on Linux, macOS and Windows, in CI)
A Google account with health data, and a Google Cloud project to authorise against. No billing account is needed - the console offers a free trial throughout setup and you can decline all of it.

Setup

1. Install

pip install google-health-mcp

Or run it without installing, in which case every google-health-mcp ... command you run below becomes uvx google-health-mcp ...:

uvx google-health-mcp --version

2. Create the Google Cloud project

Every user registers their own OAuth client. This is seven console steps, and the page names are Google's as of August 2026.

Google's own setup page will send you somewhere else - follow the steps below instead. Its quick-start builds a Web client with https://www.google.com as the redirect URI, which suits the OAuth Playground rather than a program running on your machine; this server refuses that file and says so. Use that page only to check whether one of the pages below has been renamed.

Project. Create a project at console.cloud.google.com/projectcreate and select it.
API. Enable Google Health API on the API Enablement page.
Get started. Open Google Auth Platform and complete Get started - app name, support email, External audience, contact email. A new project has no Audience, Data Access or Clients page until this is done.
Audience. Under Test users, add your own Google account. Skipping this fails sign-in with 403: access_denied.
Data Access. Click Add or remove scopes, search for "Google Health API", and tick the read-only scopes listed under OAuth scopes below.
Clients. Create an OAuth client of type Desktop app and download its JSON. A Desktop client permits the loopback redirect automatically, so there is nothing to register; a Web client does not, and fails at consent instead.
Publish. Back on the Audience page, click Publish app.

Step 7 is the one that bites, and it is worth checking rather than assuming. While an app's publishing status is Testing, Google issues refresh tokens that expire seven days after consent - so everything works, and then syncing stops a week later with nothing pointing back to this moment. The Audience page can read "In production" while the token server disagrees. Two readings that do not: the verification-status line on the Branding page, and google-health-mcp doctor, which fails loudly when the stored token records a short expiry.

3. Authorise

Put the downloaded client JSON where the server looks for it, unedited:

mkdir -p ~/.config/google-health-mcp
cp ~/Downloads/client_secret_*.json ~/.config/google-health-mcp/google_client.json
google-health-mcp auth

Your browser will warn that Google hasn't verified this app. That is expected, and the app is your own: these health scopes are classified restricted, and verification only matters above 100 users. Click Advanced, then Go to google-health-mcp (unsafe), and grant the scopes.

If you have more than one Google account, pick the one your health data is in. auth checks the account once the tokens are saved, and if Google reports it is not linked to Google Health, it says so and exits 1; run it again and choose the other account.

The flow listens on localhost:8081 for the callback, so that port must be free. It saves tokens to ~/.config/google-health-mcp/google_tokens.json, created 0600 on POSIX. Windows keeps only the owner-write bit, as its read-only attribute, and governs access by ACLs - so there the file is not restricted to your account, and what it grants is whatever its directory's ACLs pass down. Access tokens last an hour and refresh automatically. Refresh tokens do not rotate, so a token minted on a machine with a browser can be copied to a headless one.

If you authorised before publishing the app, re-run google-health-mcp auth afterwards: publishing does not extend a token already granted, and that one still expires after seven days.

4. Register with your MCP client

claude mcp add -s user google-health -- google-health-mcp

Running it with uvx instead: claude mcp add -s user google-health -- uvx google-health-mcp.

5. Check it

google-health-mcp doctor

Worth running before step 3 (Authorise) as well as after: it reports whether port 8081 can be bound and whether this host can open a browser, which are the two ways auth fails before it starts.

Offline and read-only: it reports which paths resolved where, whether the credential files are the right shape, whether the token is short-lived, whether the grant holds every permission this version reads, and whether the cache is being kept up to date.

doctor --json reports the same findings for a monitor to act on:

{
  "version": "1.12.0",
  "findings": [
    {
      "check": "stopped-series",
      "name": "hrv series",
      "severity": "warn",
      "detail": "No hrv since 2026-03-30, after rows on 28 of the 30 days before that.",
      "fix": "Re-sync that type alone (...)"
    }
  ],
  "counts": {"ok": 7, "warn": 1, "fail": 0}
}

The payload goes to stdout; logging goes to stderr, so a subprocess consumer should read the two separately.

Match on check, never on name or detail: the first is a stable identifier, the other two are prose and carry the data type. check is null for findings nothing consumes programmatically yet.

The exit code is 1 only when something is graded fail, in both formats - a warning never changes it, which is the reason this flag exists: a stopped data series is a warning, so the exit code alone cannot tell you about the one failure most worth watching for.

Check version before trusting an absent finding. A build older than a check does not report it, so "no series-never-filled finding" and "this build cannot report one" look identical without it. A release before 1.1.0 rejects --json and exits 2. version is itself null when the package is run from a source tree with no installed distribution metadata - the payload is still emitted, since a diagnostic that dies on a half-configured install is worthless exactly when it is needed.

The payload names the resolved config, database and credential paths, the same way the text report does. That is deliberate - it is what makes a wrong-path setup diagnosable - but a consumer that forwards the payload off the machine is disclosing them. No credential values appear in either format.

6. First sync (optional)

Query tools sync on first use each day, so you can skip this. To pre-populate the cache, or to pull history older than it:

google-health-mcp sync --days 30
google-health-mcp sync --since 2023-10-01     # backfill

CLI usage

google-health-mcp                Start the MCP server (stdio transport)
google-health-mcp -V, --version  Print the installed package version
google-health-mcp auth           Interactive OAuth setup
google-health-mcp doctor         Check the setup and report what needs fixing
  --json                Emit the findings as JSON, for a monitor rather than
                        a person. Each finding carries a stable `check` name
                        to match on; the exit code is the same either way.
google-health-mcp sync           Sync data to the local cache
  --days N              Days of history for a first sync (default: 30)
  --types TYPE,...      Data types to sync (default: all). One or more of:
                        heart_rate, activity, exercises, sleep, weight, spo2,
                        hrv, azm, breathing_rate, skin_temperature,
                        core_temperature, cardio_fitness, food_log, ecg, irn,
                        account, height, exercise_routes, sleep_sessions,
                        weight_readings, body_fat_readings
  --since YYYY-MM-DD    Fetch from this date, ignoring the incremental cursor
  --until YYYY-MM-DD    Inclusive end date for a --since window; together they
                        re-fetch exactly that window, to repair a gap in the
                        middle of the cache
google-health-mcp import         Import exported JSON data files
  --data-dir PATH       Directory containing the JSON files

MCP tool reference

Query tools sync on the first query of each day per data type, then read the cache.

All query tools except health_get_devices, health_get_lifetime_stats, health_get_profile and health_get_exercise_route accept:

start_date - YYYY-MM-DD, YYYY-MM, or 30d (relative). Default: 30 days back from the end date or today, whichever is earlier, except health_get_height, which goes back ten years.
end_date - YYYY-MM-DD, YYYY-MM (its last day), or 30d. Default: today.
live - if true, re-fetch this window from the API before reading the cache. A failed refresh is reported rather than silently answered from the cache.

A start after the end, or a date of the right shape that does not exist, such as 2026-13, is refused with a message rather than answered as a period with no data.

health_get_profile takes only live.

health_get_exercises also takes exercise_type, a case-insensitive substring match on the workout name. Google names the workouts, so a value matching no workout name in your cache is refused with the cached names listed and the live=True hint, rather than answered as a period you did not train in. It also takes include_detail: without it each workout carries how many exercise events, splits and split summaries it has, rather than every one. health_get_ecg also takes include_waveform: a trace is thousands of voltages, so the default response carries the classification, average rate, duration and a sample count instead. health_get_sleep_sessions also takes include_stages, for the same reason: without it each session carries how many stage segments, short awakenings and out-of-bed segments it has, rather than every one.

health_get_exercise_route takes a workout's log_id. The route text comes back only with include_tcx, since it can run to hundreds of kilobytes. Only workouts recorded with GPS have a route, and a sync fetches routes for the workouts in its own window, so an older one needs health_sync with data_types="exercise_routes" and since. A route holds every position you recorded, start and end included: it is cached on disk like the rest, and reaches the model only when include_tcx is set.

If your authorisation lacks a permission this version reads, every successful tool response carries an authorisation note naming it, doctor reports it under the check missing-scopes, and sync prints it. The data types read under it are skipped rather than failed, so sync still exits 0. A grant does not gain permissions on refresh, so this is what an upgrade that adds one looks like until you run google-health-mcp auth again. doctor on the syncing host sees the new grant straight away; the tool note, and doctor on a cache-only host, catch up once the next sync has run. Run google-health-mcp sync after authorising to fetch the newly granted data at once; a query tool otherwise waits for the next day, since a skipped type counts as synced for that day.

health_sync

data_types - all, or a comma-separated subset of the names listed under CLI usage above (irn is the irregular-rhythm notifications, and account is the profile, settings and irregular-rhythm enrolment). Default: all.
days - days of history for a first sync (default: 30). Later syncs are incremental.
since / until - fetch an exact window regardless of what is cached.

A sync adds and corrects, and never removes. An entry deleted in the app it was logged in simply stops appearing in the API, with nothing to say it was deleted, so a re-sync of that window leaves the cached row as it was. The API offers no tombstone, no change feed and no modified-since filter, so there is nothing to detect it by. In practice this reaches only the types you fill in by hand, since a device series is not deleted after the fact. Re-creating the cache is the way to clear one.

health_trends

data_type - any cached type with a daily series; ECG readings and rhythm alerts are episodes, and sleep sessions and individual readings are records, so they have no trend. Default: activity.
period - weekly, monthly, quarterly. Default: monthly.
start_date / end_date - default: 365 days back from the end date or today, whichever is earlier.
compare - two periods, e.g. last_30d vs previous_30d, 2026-03 vs 2026-02, 2026-Q1 vs 2025-Q4. When set, period, start_date and end_date are ignored. A period that names no dates, such as 2026-13 or last_0d, is refused.

OAuth scopes

Tick these read-only scopes on the Data Access page. All are under https://www.googleapis.com/auth/googlehealth.:

Scope	Data accessed
`activity_and_fitness.readonly`	Steps, distance, floors, calories, workouts, active zone minutes
`health_metrics_and_measurements.readonly`	Heart rate, HRV, SpO2, breathing rate, weight, body fat, height, temperature, VO2 max
`sleep.readonly`	Sleep sessions and stages
`nutrition.readonly`	Food and water logs
`ecg.readonly`	Electrocardiograms
`irn.readonly`	Irregular-rhythm notifications and enrolment
`settings.readonly`	Paired devices, units and time zone
`profile.readonly`	Age, membership start, stride lengths
`location.readonly`	GPS routes of workouts

The console also offers reproductive_health.readonly, logged_symptoms.readonly and mindfulness.readonly, which this package does not request. As of September 2026 the cycle, ovulation-test, symptom and mood data types can be written but not read, and the API has no mindfulness data type, so there is nothing to read under them.

Read the list off the console, not off the published scope page - read-only scopes exist that appear in neither Google's documentation nor the API's own discovery document, and the discovery document omits nutrition.readonly outright. To request fewer, tick fewer on the Data Access page and remove them from GOOGLE_SCOPE_READERS in config.py before authorising, which needs a source checkout rather than a pip or uvx install; the data types under a scope you leave out are skipped by every sync. A grant does not gain scopes on refresh, so widening the list later means running auth again.

Configuration

Variable	Default	Description
`GOOGLE_HEALTH_MCP_CONFIG_DIR`	`~/.config/google-health-mcp/`	Directory holding the OAuth client and tokens
`GOOGLE_HEALTH_MCP_DB_PATH`	`~/.local/share/google-health-mcp/google_health.db`	SQLite cache
`GOOGLE_HEALTH_MCP_OFFLINE`	unset	If truthy (`1`, `true`, `yes`, `on`), run as a cache-only reader

Offline / cache-only mode

By default the server syncs on demand, so no cron job is needed. Set GOOGLE_HEALTH_MCP_OFFLINE=1 to run as a pure reader instead:

No credentials are required - the server never opens the token file.
No network call is made. Auto-sync is off, and live=True, health_get_devices and health_sync return a clear "offline mode" message rather than reaching the API.
Query tools serve the cache, tagged "offline_mode": true.

Typical uses:

Several machines, one cache - one host runs google-health-mcp sync from cron or systemd against a shared database; the others set GOOGLE_HEALTH_MCP_OFFLINE=1, point GOOGLE_HEALTH_MCP_DB_PATH at the same file, and only read.
CI and privacy - run queries with no network access and no credentials.

Rate limits

Google applies a per-user request quota, documented at developers.google.com/health/rate-limits. Ordinary syncing is nowhere near it: a day's update is a handful of requests, and a measured three-year backfill of every data type was around 250. If a sync is cut short, that data type is recorded as a partial sync and the next run resumes from its cursor rather than starting over.

Querying from the cache - the default - costs no quota at all.

Data safety

Your health data stays on your machine: this server has no backend, sends nothing anywhere, and talks only to Google's API with your own credentials.

The repository ships a pre-commit hook that refuses to commit database files, anything under config/, and large files; CONTRIBUTING.md says how to install it.

Importing existing data

If you already have health data as JSON files, from an export or a script of your own:

google-health-mcp import --data-dir /path/to/json/files/

Expected file names: heart_rate.json, activity.json, exercises.json, sleep.json, weight.json, spo2.json, hrv.json. See src/google_health_mcp/importer.py for the shape each one expects. Import covers those seven types; everything else arrives by sync.

Contributing

See CONTRIBUTING.md for development setup, the test workflow, and the pre-commit hook. Changes are tracked in CHANGELOG.md.

License

GPL-3.0-or-later

Available Tools

24 tools

health_get_activityA

Get daily activity summaries (steps, calories, active minutes, distance).

Returns data from the local cache by default. Use live=True to fetch from the API. Run health_sync first to populate the cache.

Note: live=True fetches one API call per day - avoid large ranges to stay within the 150 requests/hour rate limit.

Returns one entry per day with steps, calories, active minutes, distance. active_minutes = very_active + fairly_active (excludes lightly active).

Inputs: live, end_date, start_date.

health_get_azmA

Get daily Active Zone Minutes (AZM), the headline cardio metric.

AZM counts minutes spent in heart rate zones at or above Fat Burn intensity. total_minutes is the plain sum of the three zone columns as reported, not a weighted one. Returns from local cache by default, auto-syncing if stale.

Returns one entry per day with total_minutes plus per-zone breakdown (fat_burn_minutes, cardio_minutes, peak_minutes). Distinct from active_minutes in health_get_activity, which counts wall-clock minutes regardless of intensity - and which has no source in this API, so it is present only for days that arrived by import.

Inputs: live, end_date, start_date.

health_get_breathing_rateA

Get nightly breathing rate (avg breaths per minute during sleep).

Sourced during sleep tracking. Useful as an illness/recovery signal: sustained increases of 2-3 bpm above personal baseline can indicate incipient infection or strain. Returns from cache by default, auto-syncing if stale.

Returns one entry per night with breaths_per_min and data_source (the device and platform Google says recorded it). Typical adult range: 12-20 bpm at rest.

Inputs: live, end_date, start_date.

health_get_cardio_fitnessA

Get Cardio Fitness Score (VO2 Max estimate).

Estimated from resting HR, HR during walks and runs, and demographics. Updates roughly weekly. Returns from cache by default, auto-syncing if stale.

A reading usually carries a range or a single value; one re-synced across the switchover between providers can hold both. They are different measurements - do not average them together or fill one from the other. vo2_max_low and vo2_max_high are a reported band (e.g. 39-43); vo2_max is a single figure. All in mL/kg/min, higher being better cardiorespiratory fitness. Beside a single figure Google may report cardio_fitness_level (POOR to EXCELLENT), estimated (1 or 0), vo2_max_covariance and data_source (the device and platform it says recorded it).

Inputs: live, end_date, start_date.

health_get_core_temperatureA

Get manually-logged core (body) temperature readings (degrees Celsius).

These are absolute body temperatures the user enters by hand - a thermometer reading logged in an app - and are the right source for fever / body-temperature questions. They are NOT the device-derived nightly skin-temperature variation from health_get_skin_temperature. A single day can hold several readings (each timestamped), useful for tracking a fever over time.

Returns one entry per logged reading with datetime (YYYY-MM-DDThh:mm:ss), temp_celsius, measurement_location (where it was taken, e.g. "MOUTH" or "EAR", as logged), reading_id and data_source. A reading whose value is changed in the app is kept beside its earlier value rather than replacing it, so two readings logged at the same datetime may be one reading, edited.

Inputs: live, end_date, start_date.

health_get_devicesA

List paired devices with battery level and last sync time.

Live-only (no caching) - reflects current device state. Useful for monitoring tracker health, knowing which device produced data, and spotting sync gaps.

Returns one entry per paired device with id, type, device_version, battery (e.g. "High"), battery_level (0-100), last_sync_time, mac, and features list.

Inputs: no named parameters.

health_get_ecgA

Get electrocardiogram (ECG) readings taken on the watch.

Each reading is a single-lead trace the user started by hand, with a rhythm classification - NORMAL_SINUS_RHYTHM, ATRIAL_FIBRILLATION, or one of several inconclusive results (low or high heart rate, poor reading, unclassified). Use it for questions about heart rhythm or AFib checks; for resting rate over time use health_get_heart_rate instead.

Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: 30 days back from the end date or today, whichever is earlier. end_date: End date as "YYYY-MM-DD", "YYYY-MM" (its last day), or "Nd". Default: today. live: If true, re-fetch this window from the API before reading the cache. include_waveform: If true, include the raw voltage samples. These are thousands of integers per reading - ask for them only to analyse the trace itself. Multiply by scaling_factor for millivolts, and read them at sampling_hz samples per second.

Returns one entry per reading with classification, avg_bpm, duration_sec, sampling_hz, scaling_factor and waveform_samples (null where no trace was stored, or where the stored one cannot be read).

Inputs: live, end_date, start_date, include_waveform.

health_get_exercise_routeA

Get the GPS route of one exercise, as the TCX file Google exports.

Only exercises recorded with GPS have a route, and a sync fetches routes for the workouts in its own window. The TCX text carries every trackpoint (time, position, altitude, distance, heart rate) and can run to hundreds of kilobytes, so it is returned only when asked for.

Args: log_id: The exercise's log_id, as health_get_exercises returns it. include_tcx: If true, include the TCX text itself.

Returns the exercise's log_id, date and provider, and the TCX text when asked for.

Inputs: log_id (required), include_tcx.

health_get_exercisesA

Get exercise log entries (individual tracked activities).

Returns exercise sessions from the local cache by default. Use live=True to fetch from the API. Run health_sync first to populate the cache.

Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: 30 days back from the end date or today, whichever is earlier. end_date: End date as "YYYY-MM-DD", "YYYY-MM" (its last day), or "Nd". Default: today. exercise_type: Filter by activity name (case-insensitive substring match), e.g. "cycling", "walk", "run". Default: all types. A value matching no workout name the cache holds is refused, naming those, rather than answered as a period with no workouts. live: If true, re-fetch this window from the API before reading the cache. include_detail: If true, include every exercise event (start, pause, stop), split and split summary. Without it each entry carries only how many there are (detail_counts), null where none is stored: an imported workout, one Google sent none for, one synced before these were fetched, or a stored value that cannot be read.

Returns exercise entries with name, duration, calories, avg heart rate, distance, and source (for a synced workout the recording device's name, and data_source.recordingMethod says whether it was logged by hand; for an imported one whatever the import carried), and for a synced workout also start and end times with their UTC offsets, active_seconds, notes, Google's metrics_summary whole (pace, speed, elevation, heart-rate zone durations, mobility), exercise_metadata (hasGps, pool length) and data_source. Note: HR data from cycling may be unreliable (optical sensor vs handlebar grip).

Inputs: live, end_date, start_date, exercise_type, +1 more.

health_get_food_logA

Get daily food and water log summary.

Returns calories consumed and water intake (in mL) per day. Only populated where the user logs food or water by hand in a connected app. Returns from cache by default, auto-syncing if stale.

Returns one entry per day with calories_in and water_ml. Days with no logging are omitted.

Inputs: live, end_date, start_date.

health_get_heart_rateA

Get daily resting heart rate and heart rate zones.

Returns resting HR and zone breakdown (Out of Range, Fat Burn, Cardio, Peak) from the local cache by default, auto-syncing if stale.

Returns one entry per day with resting_hr, zones array, calculation_method (Google's WITH_SLEEP or ONLY_WITH_AWAKE_DATA) and data_source (the device and platform Google says recorded it). Zone data: name, minutes, caloriesOut, max/min HR for each zone. Zones are present only on days that arrived by import; a sync does not write them.

Inputs: live, end_date, start_date.

health_get_heightA

Get height readings, in millimetres as Google reports them.

Height is usually logged once, often years back, so the default window is ten years. Returns data from the local cache by default.

Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "Nd". Default: ten years back from the end date or today, whichever is earlier. end_date: End date as "YYYY-MM-DD", "YYYY-MM" (its last day), or "Nd". Default: today. live: If true, re-fetch height from the API before reading the cache.

Returns one entry per reading with datetime, date, height_mm and provider.

Inputs: live, end_date, start_date.

health_get_hrvA

Get nightly HRV (heart rate variability) data.

Returns data from the local cache by default. Use live=True to fetch from the API. Run health_sync first to populate the cache.

HRV data is sparse: only nights with on-wrist sleep tracking produce readings.

Returns one entry per night with daily_rmssd and deep_rmssd (ms), entropy, non_rem_hr (non-REM heart rate, bpm) and data_source (the device and platform Google says recorded it). RMSSD = root mean square of successive RR interval differences. Higher values generally indicate better recovery and parasympathetic activity.

Inputs: live, end_date, start_date.

health_get_irregular_rhythmA

Get irregular heart rhythm notifications raised by the watch.

These are background checks the watch runs while the user is still - an alert means it saw a rhythm consistent with atrial fibrillation over one or more windows, not a diagnosis. Most accounts never have one. For a deliberate reading with a trace behind it, use health_get_ecg.

Returns one entry per notification with start_time, end_time and alert_windows (the periods that triggered it).

Inputs: live, end_date, start_date.

health_get_lifetime_statsA

Get all-time activity totals and personal best records.

Totals for steps, floors, distance and calories over every day held in the cache, plus the best single day for steps, floors and distance with the date each record was set.

The answer is bounded by what has been synced, so it is returned with a coverage block giving the first and last dates and the number of days counted - read it before quoting a total as all-time. There is no tracker-versus-total split and no "active score"; neither has a source.

Inputs: no named parameters.

health_get_profileA

Get the account's profile, settings and irregular-rhythm enrolment.

Each is the record Google returns, kept whole: the profile carries age, membership start and stride lengths, the settings carry units, time zone and locale, and the enrolment says whether irregular-rhythm notifications are on. Returns data from the local cache by default.

Args: live: If true, re-fetch the records from the API before reading the cache.

Returns profile, settings and irn_profile, and when each was fetched (UTC). A record is null when it has never been fetched, which includes one whose permission the grant lacks.

Inputs: live.

health_get_skin_temperatureA

Get nightly skin temperature variation (degrees Celsius from personal baseline).

This is the device-derived RELATIVE deviation recorded during sleep, NOT an absolute body temperature - for fever / body-temperature readings use health_get_core_temperature instead. A baseline takes about three nights to establish before values appear. Useful as an illness/cycle/recovery signal.

Returns one entry per night with nightly_relative (degrees C, can be negative), the absolutes behind it (nightly_absolute, baseline), nightly_stddev_30d (the 30-day standard deviation of the relative value), log_type (e.g. "dermal") and data_source (the device and platform Google says recorded it).

Inputs: live, end_date, start_date.

health_get_sleepA

Get nightly sleep data (duration, stages, efficiency).

Returns sleep data from the local cache by default. Use live=True to fetch from the API. Run health_sync first to populate the cache.

Sleep data is sparse: only nights with watch-tracked sleep are present. Travel, off-wrist nights, or manual logs may be missing.

Returns one entry per night with total_minutes, efficiency, start/end times, and stage breakdown (deep, light, REM, wake minutes).

Inputs: live, end_date, start_date.

health_get_sleep_sessionsA

Get each sleep session as Google recorded it, rather than the nightly total.

A night can be several sessions (a wake-and-resume, a nap); health_get_sleep sums them per night, while this returns each one whole: its interval, type (CLASSIC or STAGES), Google's metadata (mainSleep, nap, processed, manuallyEdited, stagesStatus), its summary (minutesAsleep, minutesAwake, minutesInSleepPeriod, minutesToFallAsleep, minutesAfterWakeUp, and the per-stage minutes and counts), and the device that recorded it.

Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: 30 days back from the end date or today, whichever is earlier. end_date: End date as "YYYY-MM-DD", "YYYY-MM" (its last day), or "Nd". Default: today. live: If true, re-fetch this window from the API before reading the cache. include_stages: If true, include every stage segment, short awakening and out-of-bed segment. Without it each session carries only how many there are, since a night runs to dozens.

Returns one entry per session with session_id, date (the local day it ended), start_time, end_time, provider, record (the session as Google sent it, less the segment arrays unless include_stages) and segment_counts (how many of each; absent where the stored record cannot be read).

Inputs: live, end_date, start_date, include_stages.

health_get_spo2A

Get nightly SpO2 (blood oxygen saturation) data.

Returns data from the local cache by default. Run health_sync first to populate it.

SpO2 data is sparse: only nights with on-wrist sleep tracking produce readings.

Returns one entry per night: avg SpO2 percentage and up to two pairs of bounds. avg_ci_low/avg_ci_high come from this API, which Google describes as the lower and upper bound of the confidence interval of oxygen saturation samples during sleep. min/max hold whatever an import carried; on the history checked, they matched avg_ci_low/avg_ci_high on every night carrying both. std_dev is Google's standard deviation of the daily SpO2 averages over the past 7-30 days, not of this night's samples, and data_source the device and platform Google says recorded it. Normal range: 95-100%. Below 90% may indicate sleep apnea.

Inputs: live, end_date, start_date.

health_get_weightA

Get weight log entries (weight, BMI, body fat percentage).

Returns data from the local cache by default. Use live=True to fetch from the API. Run health_sync first to populate the cache.

Weight data is sparse: only days with weigh-in entries are present.

Returns one entry per day with weight_kg, bmi, fat_pct. Every individual weigh-in is in health_get_weight_readings.

Inputs: live, end_date, start_date.

health_get_weight_readingsA

Get every weigh-in and body-fat reading, as Google recorded each one.

health_get_weight keeps one row a day; this returns every reading: its value in Google's own unit (weightGrams, percentage), when it was taken, and the device or app that recorded it.

Returns weight_readings and body_fat_readings, each entry with reading_id, datetime (local), date, provider and record (the reading as Google sent it), and count, the number of readings of both kinds.

Inputs: live, end_date, start_date.

health_syncA

Sync health data to the local cache.

Fetches data from the Google Health API and stores it in SQLite for fast offline queries. Run this before using other health_get_* tools.

Syncs incrementally: only fetches data newer than the most recent entry in each table. First sync fetches the specified number of days.

Args: data_types: What to sync. Options: "all", "heart_rate", "activity", "exercises", "sleep", "weight", "spo2", "hrv", "azm", "breathing_rate", "skin_temperature", "core_temperature", "cardio_fitness", "food_log", "ecg", "irn", "account", "height", "exercise_routes", "sleep_sessions", "weight_readings", "body_fat_readings". Comma-separated for multiple, e.g. "sleep,hrv". Default: "all". days: Days of history for first sync (default: 30). Ignored on subsequent syncs (uses last synced date). since: Optional "YYYY-MM-DD" backfill date. When set, fetches from this date regardless of what is already cached - use to pull history older than the current cache. Overrides incremental resume and days. until: Optional "YYYY-MM-DD" inclusive end date; requires since. Together they re-fetch and upsert exactly the since..until window - use to repair a gap in the middle of the cache without re-pulling everything from the gap to today.

Returns summary of records synced per data type. Not for querying data - use health_get_heart_rate, health_get_activity, health_get_sleep, etc. instead.

Inputs: days, since, until, data_types.

health_trendsA

Analyse trends in cached health data.

Computes averages and totals over time from the local cache, auto-syncing if stale.

Args: data_type: What to analyse. Options: "heart_rate", "activity", "exercises", "sleep", "weight", "spo2", "hrv", "azm", "breathing_rate", "skin_temperature", "core_temperature", "cardio_fitness", "food_log". Default: "activity". period: Aggregation period. Options: "weekly", "monthly", "quarterly". Default: "monthly". start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "365d". Default: 365 days back from the end date or today, whichever is earlier. end_date: End date as "YYYY-MM-DD", "YYYY-MM" (its last day), or "Nd". Default: today. compare: Compare two periods. Format: "last_30d vs previous_30d", "2026-03 vs 2026-02", "2026-Q1 vs 2025-Q4". When set, period/start_date/end_date are ignored.

Returns aggregated averages per period. For activity: steps, distance, active minutes. For exercises: sessions, duration, calories. For sleep: duration, efficiency, stage breakdown. For heart_rate: resting HR min/avg/max. For weight: weight, fat%, BMI. For hrv: daily and deep RMSSD.

For cardio_fitness, avg_vo2_max_low/high average a reported band while avg_vo2_max averages a single value: two definitions, each with the count of readings behind it, never one series.

For spo2, min_spo2/max_spo2 are the lowest and highest bound among imported nights (counted by nights_observed_extremes), and avg_nightly_ci_low/avg_nightly_ci_high the mean of the nightly bounds this API reports (counted by nights_confidence_interval).

These fields and their counts appear in the period form only. compare= reports spo2 as avg_spo2 alone, and carries both cardio_fitness definitions.

For core_temperature, a reading whose value was changed in the app is counted as well as its earlier value, in both forms: check a high max_temp_celsius or readings_ge_38c with health_get_core_temperature.

Not for raw data - use health_get_* tools instead.

Inputs: period, compare, end_date, data_type, +1 more.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-11-07 06:35 across 24 tools

Disambiguation4/5

There are several deliberate near-pairs (health_get_sleep vs health_get_sleep_sessions, health_get_weight vs health_get_weight_readings, health_get_skin_temperature vs health_get_core_temperature, health_trends vs the raw health_get_* tools), but each description explicitly states how it differs from its sibling and points to the right alternative. An agent can pick correctly without guessing, though it must read the descriptions carefully rather than infer from names alone.

Naming Consistency4/5

Nearly everything follows the health_<verb>_<noun> snake_case pattern (health_get_heart_rate, health_sync), and related tools form clear families. The only deviation is health_trends, which omits a verb, making its action ('analyse') less predictable than the rest.

Tool Count4/5

24 tools is on the heavy side, but the Google Health surface genuinely spans ~15 distinct metric types plus sync, aggregation, profile and device state, and each tool maps to one resource. The granularity variants (sleep sessions, weigh-ins, routes, lifetime stats) each add real capability rather than duplicating.

Completeness5/5

The set covers the full read lifecycle: cache sync/backfill, raw per-type reads for every metric the API exposes, aggregates (health_trends), lifetime totals, profile/settings, devices, ECG waveforms and exercise GPS routes. It is read-only, but that reflects the underlying API rather than a gap in the surface.

Maintenance

ActivityActive

ResponsivenessNo recent community issues

Resources

Related MCP Connectors

Withings Health Data
io.github.akutishevsky
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Health & Wellness Research & Data
245
https://withings-mcp.com/mcp
MCP for Oura
link.smirnov
Multi-tenant hosted MCP server for Oura Ring — 21 read-only tools, OAuth per user.
Health & Wellness Fitness Tracking
2
https://mcp-oura.smirnov.link/mcp
Toolforest
io.toolforest
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Workplace & Productivity Health & Wellness Finance
2
https://mcp.toolforest.io/mcp
P.R.O. Apple Health MCPA
io.github.runwithfun
Hosted Apple Health MCP: workouts, sleep and HRV in ChatGPT, Claude, Gemini, Grok. Free, no export.
Fitness Tracking Health & Wellness
151
https://mcp.proapp.uk

Related MCP Servers

Google Health MCP
Health & Wellness Fitness Tracking
davidmosiah
A
license
B
quality
A
maintenance
A local-first MCP server that enables AI agents to read user-authorized Google Health API v4 data from Fitbit, Pixel Watch, and partners via OAuth, with tokens never leaving the machine.
Updated 6 days ago (2026-11-05 16:40 UTC)
26
850 npm
81
MIT
google-health-mcp-server
Health & Wellness Fitness Tracking
madfreakz
A
license
A
quality
D
maintenance
MCP server to read daily activity, sleep, heart rate, and body metrics from Google Health API, allowing AI assistants like Claude to access your health data. Optionally syncs health metrics to an Obsidian vault.
Updated 4 months ago (2026-06-30 02:21 UTC)
5
MIT
personal-health-mcp
Health & Wellness Fitness Tracking
adamconde
A
license
Not graded
quality
D
maintenance
Self-hosted MCP server that aggregates personal health data from Google Health, Oura, and Withings into a single, provider-attributed interface with configurable source of truth preferences.
Updated 5 months ago (2026-06-18 22:46 UTC)
MIT
Google Health Fitbit MCP
Health & Wellness Fitness Tracking
BerkKilicoglu
A
license
A
quality
D
maintenance
An MCP server that locally authenticates with Google Health API v4 and provides read-only access to Fitbit, Pixel Watch, and other health data for AI agents.
Updated 3 months ago (2026-08-04 09:03 UTC)
29
119 npm
19
MIT

google-health-mcp

Features

Data types

Requirements

Setup

1. Install

2. Create the Google Cloud project

3. Authorise

4. Register with your MCP client

5. Check it

6. First sync (optional)

CLI usage

MCP tool reference

health_sync

health_trends

OAuth scopes

Configuration

Offline / cache-only mode

Rate limits

Data safety

Importing existing data

Contributing

License

Available Tools

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Google Health MCP

google-health-mcp-server

personal-health-mcp

Google Health Fitbit MCP