Skip to main content
Glama
partymola

google-health-mcp

Related Servers

Alternatives to google-health-mcp

No user-submitted related servers found.

    Related Servers

    • A
      license
      A
      quality
      C
      maintenance
      MCP server to read daily activity, sleep, heart rate, and body metrics from Google Health API, allowing AI assistants like Claude to access your health data. Optionally syncs health metrics to an Obsidian vault.
      5
      MIT
    • A
      license
      B
      quality
      A
      maintenance
      A local-first MCP server that enables AI agents to read user-authorized Google Health API v4 data from Fitbit, Pixel Watch, and partners via OAuth, with tokens never leaving the machine.
      26
      210 npm
      53
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      Self-hosted MCP server that aggregates personal health data from Google Health, Oura, and Withings into a single, provider-attributed interface with configurable source of truth preferences.
      MIT
    • A
      license
      Not graded
      quality
      B
      maintenance
      Self-hosted multi-user Google Health OAuth broker and read-only Agent API with remote MCP support. Enables users to connect their Google account and grant agents secure access to activity, sleep, heart, HRV, SpO2, and other health metrics via revocable per-token authentication.
      3
      MIT
    • A
      license
      A
      quality
      A
      maintenance
      MCP server that reads Zepp/Amazfit health and workout data, exposing tools for daily summaries, sleep, heart rate, and workout details to any MCP client.
      8
      3
      MIT

    TDQS

    A4.6/5.0

    Scored across 19 tools

    Disambiguation5/5

    Each tool maps to a distinct resource or action: one sync tool, one trends aggregator, one device listing, a lifetime stats tool, and one getter per health metric. Potentially confusable pairs (skin vs core temperature, ECG vs irregular rhythm, HRV vs heart rate) are explicitly cross-referenced and differentiated in their descriptions.

    Naming Consistency5/5

    All data retrieval tools follow the consistent health_get_<metric> pattern, with health_sync and health_trends as clear verb-based operations sharing the same health_ prefix. The naming scheme is uniform and predictable across the entire set.

    Tool Count4/5

    At 19 tools, the set is slightly above the typical well-scoped range, but the breadth of the health domain justifies one getter per metric plus sync/trends/devices/lifetime support tools. No tool feels redundant; a few metrics could theoretically be combined but separate getters genuinely aid discoverability.

    Completeness5/5

    The tool surface covers all data types mentioned in health_sync and health_trends, providing per-metric getters, aggregation via trends, lifetime records, device context, and cache management. As a read-only health data server, the lifecycle is inherently covered; no obvious gap such as a missing metric or dead-end workflow exists.

    Maintenance

    ActivityMaintained
    ResponsivenessNo issues