Google Health MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| list_available_metricsA | List Google Health API v4 data types available through this Fitbit-synced Google Health integration. This is not a direct Fitbit Web API catalog. |
| get_data_source_infoA | Explain exactly where this server gets health data, which API it uses, its read-only boundaries, and known availability limitations. Call this before interpreting metric results. |
| get_metricsA | Read one or more Google Health API v4 metric types for a date/time range. Use list_available_metrics for supported names. Returns raw normalized API records and source metadata. |
| get_recent_metricsB | Read recent Fitbit metrics with a safe default 7-day range. Each metric is isolated so unsupported or unavailable types do not fail the whole response. |
| get_health_snapshotB | Return a compact current-day Fitbit snapshot including activity, heart rate, body composition, sleep, freshness, and unavailable metrics. |
| get_trendsB | Calculate numeric trend summaries for recent Fitbit metrics: count, average, minimum, maximum, first value, last value, and percent change where possible. |
| get_sleep_summaryB | Return normalized sleep sessions and stage totals for a recent date range. |
| compare_periodsB | Compare a recent period with the immediately preceding period using daily numeric values and percent changes. |
| get_data_qualityA | Diagnose recent Fitbit data coverage, missing records, source provenance, and API-limited metrics without treating missing data as zero. |
| get_activity_summaryB | Summarize recent movement, distance, calories, floors, and heart-rate-zone activity. |
| get_recovery_summaryB | Summarize sleep, heart rate, HRV, oxygen saturation, and respiratory-rate data for informational recovery context. |
| get_body_metricsB | Summarize recent weight, body-fat, temperature, height, and blood-glucose records with normalized units and source metadata. |
| get_sync_statusB | Check connected Fitbit/Google Health account metadata, paired devices, and whether core metrics have recent data. |
| get_profileA | Read the connected Google Health/Fitbit profile and identity metadata. |
| get_devicesA | List devices paired with the connected Google Health account, including the Fitbit Air when exposed by the account. |
| get_settingsA | Read connected Fitbit/Google Health settings and configured preferences. |
| get_daily_summaryB | Read the most useful daily Fitbit metrics in one call: steps, calories, distance, active minutes, active zone minutes, resting heart rate, HRV, oxygen saturation, respiratory rate, sleep, and weight where available. |
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 17 tools
Several tools are hard to tell apart: get_health_snapshot, get_daily_summary, get_activity_summary, and get_recovery_summary all return overlapping subsets of the same daily Fitbit metrics, and get_metrics vs get_recent_metrics vs get_trends vs compare_periods all read numeric ranges with different wrappers. get_data_source_info, get_data_quality, and get_sync_status also sit close together (provenance vs coverage vs account state) even though descriptions attempt to differentiate them. The list/get primitives (profile, devices, settings, sleep) are clearly distinct.
Every tool follows a snake_case verb_noun pattern (get_*, list_*, compare_*), with no camelCase or stylistic drift. Names map predictably onto the returned resource, making the surface easy to scan.
17 tools is at the heavy end for a read-only metrics server, and much of that count comes from summary variants (snapshot, daily, activity, recovery, body) that largely recombine the same underlying metrics. The count is defensible given the breadth of health domains, but a few tools feel redundant rather than earning their place.
For an explicitly read-only integration, coverage is solid: discovery, raw metric reads, trends, period comparison, data-quality diagnostics, sleep, body, activity, recovery, plus account/device/profile/settings context. Gaps remain in nutrition/water intake, exercise/activity session logs, and intraday heart-rate resolution, which agents may need to work around.