google-health-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HTTP_TOKEN | Yes | Secret your AI apps send to reach your data (32+ characters). | |
| PUBLIC_BASE_URL | No | Public https address used for the Google redirect; only needed for custom domains. | |
| GOOGLE_CLIENT_ID | Yes | Your Google OAuth web client ID. | |
| GOOGLE_CLIENT_SECRET | Yes | Your Google OAuth web client secret. | |
| GOOGLE_HEALTH_SCOPES | No | Extra Google Health scopes, e.g. activity,metrics,sleep,profile,settings,ecg,irn. | |
| GOOGLE_REFRESH_TOKEN | No | Refresh token from elsewhere to use instead of signing in at /auth. | |
| BLOB_READ_WRITE_TOKEN | No | Vercel Blob store token; required on Vercel and added automatically when connecting a private Blob store. |
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_data_typesA | Lists every readable Google Health / Fitbit data type, which tools support it, and the maximum rollup range. |
| get_daily_summaryA | One-call overview of a single day: steps, distance, calories, active zone minutes, floors, resting heart rate, HRV, sleep that ended that day, and exercise sessions. Start here for questions like 'how did I do today/yesterday'. |
| get_daily_rollupA | Aggregated values per day (or per N days) for a data type, e.g. steps per day this week, average heart rate per day, weekly distance. Best tool for trends. Max range is 14 days for heart-rate, active-minutes, total-calories and calories-in-heart-rate-zone, 90 days otherwise. |
| get_rollupA | Aggregated values over physical-time windows (e.g. heart rate per 60 minutes during a workout, steps per hour today). Use get_daily_rollup for per-day values. |
| get_data_pointsA | Raw records for a data type, newest first: sleep sessions with stages, exercise sessions, weight entries, daily resting heart rate, HRV, SpO2, ECG and so on. Heart-rate and steps produce many points per day, so prefer the rollup tools for those. Pass nextPageToken back as pageToken to read more. For electrocardiogram the API only filters by start, treated as UTC, and end is ignored. |
| get_user_infoC | The user's Google Health identity (user IDs), profile (age, height, stride, etc.) and settings (units, time zone, goals). |
| list_paired_devicesA | Devices paired to the account (e.g. Fitbit Air, Pixel Watch), with battery and last sync time when 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 7 tools
Each tool targets a distinct granularity or resource: catalog (list_data_types), one-day overview (get_daily_summary), per-day aggregation (get_daily_rollup), time-window aggregation (get_rollup), raw records (get_data_points), identity (get_user_info), and hardware (list_paired_devices). The only near-overlap, get_daily_rollup vs get_rollup, is explicitly disambiguated in both descriptions ('per-day' vs 'per 60 minutes/hourly').
All seven names follow a clean verb_noun snake_case pattern (list_data_types, get_daily_summary, get_rollup, get_user_info, etc.). Verbs are used consistently and predictably: 'list' for enumerations, 'get' for retrieval.
Seven tools is well-scoped for a read-oriented health data server, with each tool earning its place at a distinct layer (catalog, summary, two rollup granularities, raw points, identity, devices). No redundant or filler tools.
The read surface is thorough: data-type discovery, high-level summary, both rollup granularities, paginated raw points, profile, and paired devices cover the typical query lifecycle. Gaps are minor and likely API-imposed (read-only — no goal/profile updates) and there is no dedicated sleep or heart-rate-zone helper, though get_data_points and get_rollup can reach those.