mcp-google-health
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GOOGLE_HEALTH_CREDENTIALS | No | Path of the credentials file. | |
| GOOGLE_APPLICATION_CREDENTIALS | No | Used when GOOGLE_HEALTH_CREDENTIALS is unset. Any Google authorized_user file with Google Health scopes works. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Reads and writes Google Health (Fitbit, Pixel Watch) data through the Google Health API v4. Start with list_data_types, then list_data_points, reconcile_data_points, or the roll-up tools. Use describe_schema before a write.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_data_typesA | List every Google Health data type with its kind, scope family, supported operations, and whether it needs v4beta. |
| describe_schemaA | Show the JSON schema of a data type payload (such as weight or sleep) or an API schema (such as Profile, Settings, PairedDevice, DataPoint). |
| get_identityA | Get the user's Google Health identity and numeric health user ID. |
| get_profileB | Get the user's health profile: age, stride lengths, membership start. |
| get_settingsB | Get the user's settings, such as units and time zone. |
| get_irn_profileB | Get the user's irregular rhythm notification (IRN) enrollment profile. |
| update_profileC | Update profile fields. Name each changed field in updateMask. |
| update_settingsC | Update settings fields. Name each changed field in updateMask. |
| list_paired_devicesB | List the user's paired devices with battery level, battery status, firmware version, features, and last sync time. |
| get_paired_deviceC | Get one paired device. |
| list_data_pointsA | List raw data points of one data type, newest first. Filter with AIP-160 on the type's time field, for example steps.interval.civil_start_time >= "2026-11-01", weight.sample_time.physical_time >= "2026-11-01T00:00:00Z", daily_resting_heart_rate.date >= "2026-11-01", or sleep.interval.civil_end_time >= "2026-11-01". Use snake case in filters. |
| get_data_pointB | Get one identifiable data point, such as an exercise, sleep session, weight, or log entry. |
| reconcile_data_pointsA | List data points merged across sources into one de-duplicated stream, as the Google Health app shows them. Takes the same filters as list_data_points. Use this for sleep across sources. |
| roll_up_data_pointsA | Aggregate a data type into fixed physical-time windows, such as hourly steps or 5-minute heart rate. Range is closed-open; at most 14 days for heart-rate, active-minutes, total-calories, and calories-in-heart-rate-zone, 90 days otherwise. |
| daily_roll_up_data_pointsA | Aggregate a data type into civil-day windows in the user's time zone, such as daily steps or calories. endDate is exclusive. At most 14 days for heart-rate, active-minutes, total-calories, and calories-in-heart-rate-zone, 90 days otherwise. |
| export_exercise_tcxA | Export one exercise as TCX with GPS track, heart rate, and laps. Needs the location scope. Give outputPath to save the file instead of returning the TCX text. |
| create_data_pointB | Write a new data point, such as a weight, body fat, height, sleep, exercise, hydration or nutrition log, mood, symptom, menstrual period, or ovulation test. Needs the matching write scope. |
| update_data_pointB | Replace a data point that this client wrote. |
| delete_data_pointsA | Delete up to 10000 data points of one data type that this client wrote. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 19 tools
Most tools target a clearly distinct resource+action (identity, profile, settings, paired devices, data points), and the four data-point readers (list, reconcile, roll_up, daily_roll_up) are separated by explicit description cues about raw vs. merged vs. aggregated. The main residual ambiguity is between list_data_points, reconcile_data_points, and the two roll-up tools, which an agent could still misselect when it just wants 'steps over time'.
Almost everything follows a predictable snake_case verb_noun pattern (list_data_types, get_profile, update_settings, create_data_point, delete_data_points). Minor deviations: daily_roll_up_data_points is adjective-first rather than verb-first, and describe_schema breaks the verb_noun family used elsewhere.
19 tools is on the heavy side but each maps to a real capability of a broad health API: metadata, identity, profile/settings, devices, raw and aggregated data reads, writes, deletion, and TCX export. No tool appears redundant enough to drop without losing a distinct operation.
Full lifecycle coverage for data points (create, get, list, update, delete) plus aggregation, cross-source reconciliation, and export, with read/update parity on profile and settings. Gaps: paired devices are read-only, IRN enrollment can only be read (no enroll/update), and there is no batch/multi-type create path, though these are minor workarounds for an agent.