Loading ToolBench
Unofficial local-first Google Health API v4 MCP server for AI health, sleep and activity agents.
Mixed quality across 26 tools. Naming is consistent (all start with google_health_ prefix), descriptions are present for all tools and generally substantive (100-300 chars typical), but parameter schemas lack depth and consistency. Many tools accept only 'response_format' enum plus domain-specific params, but lack descriptions for those domain params (data_type, date, time windows). Output schemas are not documented, LLMs cannot predict what these tools return. Error handling and recovery guidance are absent. Destructive operations (revoke_access, profile_update) lack confirmation gates. No clear indication of which tools are idempotent vs. which have side effects, making agent retry logic unsafe. Strong points: tools are well-scoped (one concern per tool), naming is clear and verb-driven, and the server includes thoughtful operational tools (capabilities, inventory, privacy_audit). Weak points: parameter descriptions are often missing or minimal, response structures are undocumented, and the README-style descriptions (e.g., 'Machine-readable install, runtime and client guidance') don't explain LLM-relevant behavior.
Machine-readable install, runtime and client guidance for AI agents. Does not call Google Health or expose secrets.
Check cache status and configuration
Explain supported Google Health data, privacy boundaries, beta status and recommended agent workflow.
Check OAuth connection status, environment configuration, and readiness for Google Health API calls.
Get daily rollup of a specific health data type
Get a daily summary of health and activity metrics from Google Health
Output schemas are not documented anywhere. LLMs cannot predict what data structures tools return, forcing them to reason blindly or make unsafe assumptions. This violates the fundamental pattern:tool contract and breaks tool chaining, e.g., daily_summary returns some structure, but what fields? Can downstream tools rely on 'date', 'steps', 'heart_rate'? Unknown.
Domain-specific parameters (data_type, date, start_time, end_time, window_size, privacy_mode) lack descriptions. LLMs cannot determine what format a 'date' parameter accepts (ISO 8601? Natural language? Unix timestamp?), whether 'window_size' expects 'daily' or a number of hours, or what privacy_mode values mean. This violates pattern:tool-description and forces agents to guess or fail.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | 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.
Generate synthetic demo data for testing without a real Google Health account
Exchange an OAuth authorization code for access and refresh tokens
Get the OAuth authorization URL for user to grant access to Google Health data
Get the identity and account information of the authenticated user
Retrieve user profile from local storage
Retrieve user settings and preferences
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 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.
Interactive onboarding flow for first-time setup
Audit privacy configuration and redaction behavior
Get user profile information
Update user profile information
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?'
Reconcile conflicting data points from multiple sources
Revoke OAuth access tokens and remove locally stored credentials
Get rollup of health data points over a time window
Get a weekly summary of health and activity metrics
Get comprehensive wellness context including sleep, activity, and metrics for AI wellness agents
Destructive operations (google_health_revoke_access: DESTRUCTIVE, google_health_profile_update: WRITE) lack confirmation gates, dry-run modes, or recovery guidance. An agent might accidentally revoke access without understanding it has cleared all cached credentials. No pattern:confirmation-request or pattern:recovery-guide present.
No error handling or recovery guidance visible in tool descriptions. What happens if OAuth exchange fails? If a date parameter is invalid? If the user has no health data? Tools return nothing but a description, agents cannot self-correct or know what to try next. This violates pattern:recovery-guide.
No idempotency guarantees documented. If an agent retries google_health_exchange_code or google_health_profile_update due to a timeout, will it create duplicate records or overwrite safely? Lack of idempotent-operation pattern declaration makes agent retry logic unsafe.
Many tools accept only 'response_format' and one or two domain params, but the domain params are not validated. E.g., google_health_daily_summary accepts 'date' with no format constraint documented. No JSON Schema pattern, minLength, or enum to guide LLM input or server validation. This violates pattern:constrained-input.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the FEATURES list but not visible in the tool definitions shown. Smoke test verifies their presence, but the definitions provided do not expose them, this suggests they may be added dynamically at registration time, not in the source schema. Verify they are properly included in tool output to clients.
Parameter 'profile' in google_health_profile_update is typed as 'object' with no description and no schema of what fields are allowed. LLMs cannot know what to pass, is it { name: string }? { birthDate: string }? { all fields mutable }? Violates pattern:tool-description and pattern:constrained-input.