Loading ToolBench
Google Health API MCP server for AI health, sleep and activity agents — reads Fitbit, Pixel Watch and partner data locally over OAuth.
The server implements 29 tools with consistent naming patterns (google_health_* prefix), all with descriptions and input schemas. However, there are significant gaps in output schema documentation, parameter descriptions lack depth, and error handling guidance is minimal. Most tools follow verb_noun conventions well, but descriptions are often generic and lack actionable context for LLM decision-making. The server has good baseline structure but falls short of production-grade tool design standards.
Machine-readable install, runtime and client guidance for AI agents. Does not call Google Health or expose secrets.
Inspect the status of the local SQLite read cache: how many bytes of data are cached, how many cache hits and misses, and whether the cache is enabled.
Explain supported Google Health data, privacy boundaries, beta status and recommended agent workflow.
Check whether the MCP server has valid OAuth credentials, required environment variables, and can reach Google Health APIs. Helps diagnose auth setup issues without requiring a real data request.
Fetch daily aggregated metrics as a simple rollup (one row per day with totals like stepCount, durationMs, etc.) for a specific date range and data type.
Fetch daily aggregated summaries (bucketed totals and statistics) for a given date and data type. More efficient than querying raw data points when you only need daily totals.
Output schemas not documented. Tools lack explicit return type declarations, forcing LLMs to infer result structure. This violates the critical check that 100% of A+ tools have documented return types.
Parameter descriptions are minimal and lack actionable format constraints. Examples: 'Optional date for coverage check' does not specify ISO 8601 format; 'Optional page size for results' lacks min/max bounds (1-100). LLMs cannot infer constraints from sparse descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
Inventory supported Google Health data types, auth scopes, privacy modes and recommended first calls without calling Google APIs.
Build a data-type coverage plan from the official Google Health API data-type table, or run explicit live read-only checks against a real OAuth account. Live mode returns only redacted status and point-count buckets, never raw health payloads.
Run a demonstration of the Google Health MCP server: fetch sample data and show what the agent can do without requiring real user data.
Exchange an OAuth 2.0 authorization code (from the redirect callback) for access and refresh tokens. Stores tokens locally and enables subsequent data reads.
Get the OAuth 2.0 authorization URL to redirect the user to for the setup flow.
Fetch a specific Google Health data point by its ID.
Get the OAuth subject ID (sub) that uniquely identifies the user across Google services. Useful for linking health data to external databases.
Fetch the user's Intelligent Routine Notifications (IRN) profile and settings from Google Health.
Fetch the user's Google Health profile (name, bio, profile photo, birthday, gender, and other public identity fields).
Fetch the user's Google Health application settings (units preference, notifications, etc.).
Fetch raw Google Health data points for a specific data type (e.g., 'sleep', 'steps', 'heart-rate'). Returns paginated results with optional date/time filtering and privacy mode support.
List the canonical kebab-case data_type slugs accepted by the data point, reconcile and rollup tools, with each slug's unit, OAuth scope family, and which endpoint verbs (list/reconcile/rollup) support it. Call this before list_data_points, reconcile_data_points, daily_rollup or rollup to choose a valid data_type instead of guessing a slug. Static metadata; does not call Google APIs.
List wearable devices (Fitbit, Pixel Watch, etc.) paired with the user's Google Health account.
Check if the user has completed the Google Health onboarding setup. Returns onboarding status and next steps.
List all privacy filtering modes, what they redact, and which data leaks are blocked by each mode. Useful for understanding privacy guarantees before calling a tool.
Read local profile document: stored user settings, tracking preferences, contact info and any agent-set fields.
Write or patch the local profile document: store user settings, tracking preferences, contact info and agent-controlled fields.
Personalized 3-step setup walkthrough for the human user. Adapts to current state (env vars set? token present? what's next?). Call this first when the user asks 'how do I connect Google Health?'
Submit a list of raw data point updates to Google Health (create, update, or delete operations). Used to sync data from external sources into Google Health.
Revoke the stored OAuth access and refresh tokens, disconnecting the user from Google Health. Does not delete local profile data.
Fetch aggregated metrics as a single rollup across an arbitrary time range (totals like stepCount, durationMs, etc.) for a specific data type.
Fetch weekly aggregated summaries (bucketed totals and statistics) for a given week and data type.
Summarize the user's recent health, sleep, activity and stress data (7-day rollup) and infer wellness context (rested? active? stressed?) for agent decision-making.
No error handling guidance in tool descriptions. Tools like 'google_health_exchange_code' (WRITE risk) do not document what happens on auth failure, invalid code, or network errors. LLMs have no recovery strategy.
Pagination not explicitly documented. 'google_health_list_data_points' accepts page_size but lacks documentation of total count, next_cursor, or pagination strategy. Large result sets risk context window exhaustion.
Response_format parameter repeated across all 29 tools (markdown|json). This adds cognitive overhead and is a code smell, consider returning structured JSON by default and optional markdown formatting as a separate presentation layer.
No confirmation or dry-run support for destructive operations. 'google_health_reconcile_data_points' (WRITE, deletes data) and 'google_health_revoke_access' lack a --dry-run or confirmation-request pattern. Agents could accidentally delete health data.
Tool descriptions do not clearly state which tools are safe to retry vs. which have irreversible side effects. 'google_health_exchange_code' and 'google_health_profile_update' lack explicit (WRITE) risk labeling in the description text itself.