io.github.partymola/google-health-mcp
PYPI · GOOGLE-HEALTH-MCP
MCP server for the Google Health API, with a local SQLite cache and trend analysis.
Available components
Last scanned (1 hour ago)
Scores higher than 71% of PyPI servers
Category Health and Science
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security50
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs setuptools.build_meta at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
- 1 of 28 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to partymola/google-health-mcp). View diagnostics → Pass
- Clear OSI-approved license (GPL-3.0-or-later).Pass
- Actively maintained (last published 3 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability61
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 5654 tokens (~235/item across 24 items; 24 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage71
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 0% of tool parameters carry a description.Fail
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 24 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 24 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a current MCP spec version (2026-07-28).Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 21 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- 20 Oct 26 +15
- Malware scan: unverified → pass ▲ security
- Package version: 1.8.0 → 1.9.0 functional
- 17 Oct 26 +2
- Stability: 0.87 → pass security
- 15 Oct 26 +39
- Injection markers: unverified → pass ▲ security
- Tool coverage: unverified → 100 ▲ functional
- Stability: unverified → 0.83 ▲ functional
- MCP protocol: unverified → pass ▲ functional
- Package version: 1.7.0 → 1.8.0 functional
- 14 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- Package version: 1.7.0 → 1.8.0 functional
- 12 Oct 26 +15
- Malware scan: unverified → pass ▲ security
- Package version: 1.7.0 → 1.8.0 functional
- 5 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- Stability: Stability not yet verified: this package installed, but its server did not start, so we have no schema to compare. security
- Tool safety: Tool safety not yet verified: this package installed, but its server did not start, so we have no tool text to scan. security
- Schema quality: Schema quality not yet verified: this package installed, but its server did not start, so we have no schema to assess. functional
- Capabilities: Protocol version not yet verified: this package installed, but its server did not start, so we never saw its MCP handshake. functional
- Tool coverage: Tool coverage not yet verified: this package installed, but its server did not start, so we have no tool definitions to assess. functional
- Package version: 1.7.0 → 1.8.0 functional
- 4 Oct 26 −40
- Stability: 0.90 → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Malware scan: pass → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Package version: 1.7.0 → 1.8.0 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 24 Oct 2026 · Analysed pypi/google-health-mcp@1.9.0
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | pypi |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | partymola/google-health-mcp |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/partymola/google-health-mcp/.github/workflows/publish.yml@refs/tags/v1.9.0 |
| Rekor log index | 3338738220 |
| Predicate type | PyPI publish attestation https://docs.pypi.org/attestations/publish/v1 |
| Subject digest | sha256:d2a9fae0512e4079b38875c4273ec59da4e7ccc5983b1b7f2ec645128bd3158b |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | setuptools.build_meta |
Background: Why install scripts are a supply-chain risk →
Dependencies 28 packages
| Packages resolved | 28 |
|---|---|
| No linked repository | 1 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
health_get_activity ~190
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. Returns one entry per day with steps, calories, active minutes, distance. active_minutes = very_active + fairly_active (excludes lightly active).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_azm ~225
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_breathing_rate ~190
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_cardio_fitness ~277
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_core_temperature ~268
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_devices ~92
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_ecg ~302
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: last 30 days. end_date: End date as "YYYY-MM-DD". 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).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| include_waveform | boolean | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_exercise_route ~165
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.
| Name | Type | Req | Description |
|---|---|---|---|
| include_tcx | boolean | – | – |
| log_id | string | yes | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_exercises ~410
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: last 30 days. end_date: End date as "YYYY-MM-DD". 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).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| exercise_type | – | – | – |
| include_detail | boolean | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_food_log ~164
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. Returns one entry per day with calories_in and water_ml. Days with no logging are omitted.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_heart_rate ~214
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_height ~147
Get height readings, in millimetres as Google reports them. Height is usually logged once, often years back, so the default window is the last 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. end_date: End date as "YYYY-MM-DD". 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_hrv ~218
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_irregular_rhythm ~190
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. Returns one entry per notification with start_time, end_time and alert_windows (the periods that triggered it).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_lifetime_stats ~125
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.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_profile ~148
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.
| Name | Type | Req | Description |
|---|---|---|---|
| live | boolean | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_skin_temperature ~232
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_sleep ~189
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. Returns one entry per night with total_minutes, efficiency, start/end times, and stage breakdown (deep, light, REM, wake minutes).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_sleep_sessions ~328
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: last 30 days. end_date: End date as "YYYY-MM-DD". 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).
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| include_stages | boolean | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_spo2 ~286
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_weight ~176
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. Returns one entry per day with weight_kg, bmi, fat_pct. Every individual weigh-in is in health_get_weight_readings.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_get_weight_readings ~197
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. Args: start_date: Start date as "YYYY-MM-DD", "YYYY-MM", or "30d". Default: last 30 days. end_date: End date as "YYYY-MM-DD". Default: today. live: If true, re-fetch this window from the API before reading the cache. 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.
| Name | Type | Req | Description |
|---|---|---|---|
| end_date | – | – | – |
| live | boolean | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_sync ~393
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.
| Name | Type | Req | Description |
|---|---|---|---|
| data_types | string | – | – |
| days | integer | – | – |
| since | – | – | – |
| until | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
health_trends ~528
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" or "365d". Default: last 12 months. end_date: End date as "YYYY-MM-DD". 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.
| Name | Type | Req | Description |
|---|---|---|---|
| compare | – | – | – |
| data_type | string | – | – |
| end_date | – | – | – |
| period | string | – | – |
| start_date | – | – | – |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
How do I install the io.github.partymola/google-health-mcp server?
io.github.partymola/google-health-mcp runs locally as a PyPI package, launched with uvx google-health-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · google-health-mcp
claude mcp add partymola-google-health-mcp -- uvx google-health-mcp
What is the io.github.partymola/google-health-mcp server?
io.github.partymola/google-health-mcp is listed in the public MCP registry as io.github.partymola/google-health-mcp. MCP server for the Google Health API, with a local SQLite cache and trend analysis. This page covers its PyPI package (google-health-mcp).
Is the io.github.partymola/google-health-mcp server safe to use?
io.github.partymola/google-health-mcp scores 75 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 24 October 2026. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.partymola/google-health-mcp server expose?
io.github.partymola/google-health-mcp exposes 24 tools: health_sync, health_get_activity, health_trends, health_get_azm, health_get_breathing_rate, and 19 more. Their descriptions and schemas cost roughly 5,654 tokens of context every time the server is loaded.
Is the io.github.partymola/google-health-mcp server still maintained?
io.github.partymola/google-health-mcp is still listed as active in the MCP registry. We last reached this channel on 24 October 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the io.github.partymola/google-health-mcp server under?
io.github.partymola/google-health-mcp declares the GPL-3.0-or-later licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.