google-health-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OBSIDIAN_VAULT_PATH | No | Optional path to Obsidian vault for syncing health data. | |
| GOOGLE_HEALTH_TOKENS_PATH | Yes | Path to the tokens JSON file. Required for reading client ID/secret and tokens. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
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 |
|---|---|
| get_daily_summaryA | Daily health metrics (steps, distance, active calories, active-zone minutes, floors, resting heart rate, and avg/max heart rate) across all connected Google Health sources (Apple Watch import, Fitbit Air, Pixel Watch). Returns a per-day table plus the raw points. Use start_date/end_date for an explicit range, or |
| list_data_pointsA | Fetch raw (un-rolled-up) data points for a single Google Health dataType — use when you need finer-than-daily granularity (e.g. intraday heart rate samples, individual sleep stages) or a dataType not covered by get_daily_summary. Accepts a friendly key (steps, sleep, heartRate, ...) or a raw API dataType string, plus an optional date range or raw filter. Prefer get_daily_summary for trend/summary questions — it is far cheaper. |
| list_paired_devicesA | List devices paired to the Google Health account (e.g. Apple Watch import source, Fitbit Air, Pixel Watch) with manufacturer/model/type. Useful to confirm a new device has connected. |
| connection_statusA | Health-check the Google Health connection: confirms the OAuth token works, reports granted vs recommended scopes, and probes which metrics actually return data over the last 7 days. Run this first when setting up or after a new device syncs to confirm data is flowing. |
| sync_health_to_obsidianA | Export daily health summaries to Obsidian as per-day markdown notes under {vault}/Lifestyle/Health/ (frontmatter: steps, distance_km, calories, active_minutes, resting_hr, sleep_hours for Dataview), and refresh {vault}/Lifestyle/Health-Dashboard.md with rolling 7/30-day aggregates. Runs incrementally from the last sync by default; set full_sync=true to re-render the whole window. Requires OBSIDIAN_VAULT_PATH to be set. |
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 5 tools
Tools are mostly distinct: connection_status is a health-check, get_daily_summary and list_data_points differ by granularity and scope, but get_daily_summary also returns raw points, causing potential overlap. Descriptions help guide selection.
Naming is inconsistent: 'connection_status' uses noun_noun while others use verb_noun patterns (get_, list_, sync_). Mixed styles like 'daily_summary' and 'paired_devices' also break pattern.
Five tools are well-scoped for a Google Health MCP server: connection check, daily summary, raw data points, device listing, and Obsidian export. No redundancy or excess.
Covers core data retrieval and export, but lacks tools for updating or managing health data, which are less common in this domain. Minor gap in querying specific data types beyond the summary.