Google Health Fitbit Mcp

io.github.BerkKilicoglu由 GitHub 账号 BerkKilicoglu 发布v1.0.2更新于 Oct 24, 2026

Privacy-first Google Health API MCP server for health, sleep, activity and HR agents

已验证STDIO仅桌面位置与生活数据与分析

概览

AI 生成的概览

本地运行的 MCP 服务器，通过 OAuth 让 AI 助手以只读方式访问你自己的 Google Health API 数据（Fitbit、Pixel Watch）。

可以做什么
  • 检查配置、连接状态、授权范围与支持的数据类型目录
  • 读取身份、个人资料、设置、已配对设备与心律不齐通知状态
  • 列出、获取并跨来源整合日内数据点
  • 计算按自然日与物理时间的汇总，以及每日和每周健康摘要
  • 查看隐私、缓存与覆盖率等元数据，并使用内置资源与提示词
适用场景
适合让助手查看你自己来自 Fitbit 或 Pixel Watch 的步数、睡眠、心率、心率变异性、体重或运动数据，或基于真实 Google Health 账户生成健康摘要与趋势背景。
运行要求
通过 npx（Node.js）以 stdio 在本地运行。需要一个类型为 Desktop 的 Google Cloud OAuth 客户端并启用 Google Health API，配置 GOOGLE_HEALTH_CLIENT_ID、GOOGLE_HEALTH_CLIENT_SECRET 和 GOOGLE_HEALTH_REDIRECT_URI（或使用引导式 setup 命令），并完成一次浏览器授权。需要访问 Google 的网络连接。
安装前请注意
涉及敏感健康数据与 OAuth 凭据：客户端密钥和令牌保存在本地，请勿放入共享配置或公开 issue。当同意屏幕处于 Testing 状态时，Google 会在 7 天后撤销刷新令牌，服务器可能自动打开浏览器重新授权。撤销访问是破坏性操作；nutrition-write 授权预设是唯一带写入能力的预设，但目前尚未提供写入工具。属于 Beta 软件，非医疗设备。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Google Health Fitbit Mcp，将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only，通过 STDIO。 STDIO 服务会启动本地进程，因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

Google Health Fitbit MCP

Query your own Google Health API data — Fitbit, Pixel Watch and connected partner sources — over local OAuth. Beta.
Everything runs on your own machine — your credentials never leave your device.

[npm version] [npm downloads] [License MIT] [Built for MCP] [GitHub stars]

An MCP server that runs locally and hands your AI agent your own Google Health API data — from Fitbit trackers, Pixel Watch and supported partner sources — through OAuth.

  • Install in one command — npx -y google-health-fitbit-mcp setup
  • Run it in Claude Desktop · Claude Code · Cursor · Windsurf · Hermes · OpenClaw — see client examples.
  • On your machine — OAuth tokens are stored locally with 0600 permissions and are never returned by any tool (privacy).
  • Read-only by default — every shipped data tool is a read. Writes are a gated, opt-in, dry-run-first design that is not enabled.

Beta status: Google Health API is available to developers but the surface is still moving. Because Google's release notes keep listing scope and data-type changes after launch, this connector remains in beta and steers testers toward safe read-only validation before any production use.

Independent, community-built connector — no affiliation with, endorsement from or support by Google, Fitbit or Alphabet. Not a medical device or medical advice; treat the data as trend context only.

⚡ Quick Connect

Prerequisite: a Google Cloud OAuth client (type: Desktop) with the Google Health API enabled and the redirect http://127.0.0.1:3000/callback registered — details in Install.

Step 1 — Install & authorize (once):

bash
npx -y google-health-fitbit-mcp setup     # guided: Google Cloud OAuth client + scopesnpx -y google-health-fitbit-mcp auth      # browser OAuth — tokens stay on your machinenpx -y google-health-fitbit-mcp checkup   # ✓ verifies everything is ready
🔑 First time? Get your Google Client ID & Secret (~2 min)

setup asks for a Client ID and Client Secret. You create these once, for free, in Google Cloud:

  1. New project — open console.cloud.google.com/projectcreate, name it (e.g. health-mcp), click Create, then select it.
  2. Enable the API — open the Google Health API page and click Enable.
  3. Consent screen — go to OAuth consent screen, choose External, and fill in the required app name / email fields. Under Test users, add your own Google account — skip this and sign-in fails with 403: access_denied.
  4. Create the client — go to Credentials → + Create credentials → OAuth client ID → Application type: Desktop app → Create.
  5. Copy the Client ID (ends in …apps.googleusercontent.com) and the Client secret, then paste each one when setup prompts you.

Redirect URI: Desktop-app clients allow the http://127.0.0.1:3000/callback loopback automatically — you don't register it anywhere. Just press Enter to accept the default when setup asks. For every other setup prompt (scope preset, privacy mode), pressing Enter picks a sensible default.

Heads-up — the 7-day rule: while the consent screen sits in Testing publishing status, Google revokes refresh tokens after 7 days. Around once a week the next request fails with invalid_grant, which is normal and not a bug in this server. It reopens the consent flow for you (see Staying connected); approving takes a couple of seconds. Publishing the app removes the expiry entirely — check what your scopes require on the consent screen before switching.

Step 2 — Connect your app:

Claude Code
bash
claude mcp add google-health -- npx -y google-health-fitbit-mcp
Claude Desktop

Settings → Developer → Edit Config, then add to claude_desktop_config.json:

json
{  "mcpServers": {    "google_health": {      "command": "npx",      "args": ["-y", "google-health-fitbit-mcp"]    }  }}

Restart Claude Desktop — the tools appear under the 🔌 connectors menu.

Cursor

Add the same mcpServers block to .cursor/mcp.json (per-project) or ~/.cursor/mcp.json (global), or use Settings → MCP → Add new server.

json
{  "mcpServers": {    "google_health": {      "command": "npx",      "args": ["-y", "google-health-fitbit-mcp"]    }  }}
Windsurf

Add the same mcpServers block to ~/.codeium/windsurf/mcp_config.json.

Hermes
bash
npx -y google-health-fitbit-mcp setup --client hermes   # writes the Hermes config for you

Then reload with /reload-mcp or hermes mcp test google_health.

Step 3 — Test it. Ask your agent:

text
Run google_health_connection_status and tell me if I'm connected.

Why this exists

The Google Health API is the successor to the Fitbit Web API: new OAuth, new base URL (https://health.googleapis.com), a streamlined endpoint schema, standardized kebab-case data types, reconciled cross-source streams and daily/physical-time rollups.

It gives agents a clean path to explore the API, verify their setup, sign in locally and pull data — with no need to paste tokens into prompts or agent configs.

Try it with your agent

Three good opening prompts, built around tools this connector genuinely ships:

text
Check my setup with google_health_connection_status, then callgoogle_health_data_inventory and tell me which Google Healthdomains and scopes I've granted.
text
Pull today's google_health_daily_summary, then google_health_weekly_summary.Keep observed data separate from any suggestions, and stay non-medical.
text
List my paired devices with google_health_list_paired_devices and tell mewhich device is producing my sleep and heart-rate data.

Tools

29 tools, all read-only except the two explicitly gated local-profile/auth actions noted below.

Start here

ToolWhat it does
google_health_connection_statusLocal config, token, scope and MCP-client readiness — no Google call
google_health_quickstartPersonalized 3-step setup walkthrough that adapts to your current state
google_health_data_inventorySupported domains, scopes, data-type naming and recommended agent flow
google_health_list_data_typesThe 39 kebab-case data-type slugs with units, scopes and supported verbs
google_health_demoRealistic synthetic payloads so agents see the contract before real calls

Data reads (Google Health API)

ToolEndpoint
google_health_get_identity/v4/users/me/identity — Google Health + legacy Fitbit identity mapping
google_health_get_profile/v4/users/me/profile
google_health_get_settings/v4/users/me/settings — units, timezone
google_health_list_paired_devices/v4/users/me/pairedDevices — your Fitbit trackers and Pixel Watches, and which device produces which data
google_health_get_irn_profile/v4/users/me/irnProfile — irregular-rhythm (AFib) notification engagement status
google_health_list_data_points/v4/.../dataPoints — intraday detail for any data type
google_health_get_data_point/v4/.../dataPoints/{id} — one specific sleep session, exercise or measurement
google_health_reconcile_data_points/v4/.../dataPoints:reconcile — one clean stream across sources (all-sources, google-wearables, google-sources)
google_health_daily_rollup/v4/.../dataPoints:dailyRollUp — civil-day aggregates
google_health_rollup/v4/.../dataPoints:rollUp — physical-time window aggregates

Summaries & wellness context

ToolWhat it does
google_health_daily_summarySteps, distance, calories, active-zone minutes, sleep, resting HR, HRV and weight for one day, with data-quality flags
google_health_weekly_summaryWeekly scorecard with optional prior-window comparison, load classification and bottlenecks
google_health_wellness_contextNormalized activity/sleep context for recommendation engines

Auth, diagnostics & metadata

google_health_get_auth_url · google_health_exchange_code (gated: requires explicit user intent) · google_health_revoke_access (gated + destructive: disconnects Google Health) · google_health_privacy_audit · google_health_cache_status · google_health_data_type_coverage · google_health_capabilities · google_health_agent_manifest · google_health_onboarding · google_health_profile_get · google_health_profile_update (local file only, requires explicit_user_intent=true)

Resources & prompts

MCP resources: google-health://agent-manifest, google-health://capabilities, google-health://inventory, google-health://latest/steps, google-health://profile, google-health://summary/daily, google-health://summary/weekly.

MCP prompts: google_health_daily_checkin, google_health_weekly_review, google_health_data_type_investigation.

Data types

39 data types from the official Google Health table, including steps, sleep, heart-rate, heart-rate-variability, daily-resting-heart-rate, active-zone-minutes, distance, total-calories, weight, body-fat, blood-glucose, oxygen-saturation, vo2-max, electrocardiogram, irregular-rhythm-notification, exercise, floors, swim-lengths-data, nutrition-log and hydration-log.

Naming rules agents need:

  • Endpoints use kebab-case data types: steps, daily-resting-heart-rate.
  • Filters use snake_case field paths: sleep.interval.civil_start_time, heart_rate.sample_time.physical_time.
  • Source families: all-sources, google-wearables, google-sources.

Call google_health_list_data_types for the full catalog with units, scopes and which verbs (list/reconcile/rollup) each type supports.

Privacy & what runs offline

  • OAuth tokens live on disk at ~/.google-health-mcp/tokens.json, locked down to 0600 permissions.
  • Client secrets go in ~/.google-health-mcp/config.json or the GOOGLE_HEALTH_* environment variables.
  • No tool ever hands back an access token, refresh token or client secret; error output is redacted too.
  • The default privacy mode is GOOGLE_HEALTH_PRIVACY_MODE=structured; summary strips identifiers further, and raw is an explicit opt-in for debugging.
  • GPS/route data is treated as sensitive and redacted unless explicitly requested.
  • support prints a copy-paste support bundle for GitHub issues — always redacted, never contains tokens, secrets, local paths or health measurements.
  • support --feedback --json prints an anonymous setup-feedback bundle for beta testers (guide).
  • coverage --live --json prints only redacted data-type status and point-count buckets — never raw Google Health payloads (guide).

Install

Set up a Google Cloud OAuth client (type: Desktop), turn on the Google Health API, and register the local redirect:

text
http://127.0.0.1:3000/callback

Then run:

bash
npx -y google-health-fitbit-mcp setup --scope-preset fullnpx -y google-health-fitbit-mcp authnpx -y google-health-fitbit-mcp checkup

Scope presets

Presets keep OAuth consent easy to reason about — request only what your use case needs:

PresetGrants
basicprofile + settings
activitybasic + activity/fitness + health metrics
sleepbasic + sleep
heartbasic + health metrics + ECG + irregular-rhythm notifications
fullall recommended read-only scopes (default)
nutrition-writeopt-in nutrition write scope — the only preset with any write capability; no write tool ships yet

Advanced users can pass --scopes with an explicit space/comma-separated scope list.

If setup gets stuck

bash
npx -y google-health-fitbit-mcp checkup --fix        # repairs local config/token permissions (chmod 600 where supported)npx -y google-health-fitbit-mcp checkup --live       # hits read-only identity/profile/settings endpoints to confirm the API respondsnpx -y google-health-fitbit-mcp coverage --live --json  # redacted read-only data-type coverage reportnpx -y google-health-fitbit-mcp support             # shareable support bundle, stripped of tokens/secrets/measurementsnpx -y google-health-fitbit-mcp support --feedback --json  # anonymous setup feedback bundle

Staying connected

Access tokens refresh silently in the background. The refresh token behind them is what expires — Google revokes it after 7 days while the consent screen is in Testing publishing status, and the next call comes back as invalid_grant. Retrying cannot fix that: the grant is gone, and only a fresh authorization brings it back.

So the server does the authorization for you. On the first call that hits a revoked grant it opens your browser at Google's consent screen; approve, and the original request finishes on its own — no command to run, nothing to diagnose. If you take longer than GOOGLE_HEALTH_REAUTH_WAIT_MS (45s by default), the call returns the URL instead and the listener stays up, so approving still works and the next request goes through.

This only runs on the local stdio transport, where the browser and the server are on the same machine. Under the HTTP transport — where the server may be remote, and its default port collides with the loopback redirect — the call fails with an explicit instruction to run auth instead. Set GOOGLE_HEALTH_AUTO_REAUTH=0 to always handle re-authorization yourself, or GOOGLE_HEALTH_AUTH_NO_BROWSER=1 on headless hosts to get the URL without a browser launch.

MCP client config

Claude Desktop / Cursor / Windsurf (see examples/):

json
{  "mcpServers": {    "google_health": {      "command": "npx",      "args": ["-y", "google-health-fitbit-mcp"]    }  }}

Hermes

bash
npx -y google-health-fitbit-mcp setup --client hermes --no-authnpx -y google-health-fitbit-mcp authnpx -y google-health-fitbit-mcp checkup --client hermes

Once the config changes, run /reload-mcp or hermes mcp test google_health — there's no need to restart the gateway just to read data.

HTTP transport (optional)

The default transport is stdio. A local Streamable-HTTP transport is available for clients that need it:

bash
npx -y google-health-fitbit-mcp --http   # serves http://127.0.0.1:3000/mcp (+ /health)

Configuration

Environment variablePurposeDefault
GOOGLE_HEALTH_CLIENT_IDGoogle Cloud OAuth client ID— (or local config)
GOOGLE_HEALTH_CLIENT_SECRETOAuth client secret (prefer local config over MCP client config)— (or local config)
GOOGLE_HEALTH_REDIRECT_URIRegistered redirect URI— (or local config)
GOOGLE_HEALTH_TOKEN_PATHToken file location~/.google-health-mcp/tokens.json
GOOGLE_HEALTH_PRIVACY_MODEsummary | structured | rawstructured
GOOGLE_HEALTH_CACHEOptional SQLite response cache (true/sqlite)disabled
GOOGLE_HEALTH_CACHE_PATHSQLite cache location~/.google-health-mcp/cache.sqlite
GOOGLE_HEALTH_NO_CACHEBypass the in-memory HTTP cache (60s TTL, GET-only)unset
GOOGLE_HEALTH_MCP_TRANSPORTstdio | httpstdio
GOOGLE_HEALTH_MCP_HOST / GOOGLE_HEALTH_MCP_PORTHTTP transport bind address127.0.0.1 / 3000
GOOGLE_HEALTH_AUTO_REAUTHReopen the consent flow automatically when the grant is revoked (0/false to disable)enabled
GOOGLE_HEALTH_REAUTH_WAIT_MSHow long a tool call waits for you to approve before returning the URL instead45000
GOOGLE_HEALTH_AUTH_NO_BROWSERNever launch a browser; print/return the URL only (headless hosts)unset

Reliability built in: every Google call goes through retry middleware (exponential backoff + jitter, honors Retry-After, retries 408/429/5xx) and a 60-second GET-only response cache. Multi-day summaries limit request concurrency to stay under rate limits.

CLI commands

All commands run via npx -y google-health-fitbit-mcp <command> (installed binary: google-health-fitbit-mcp-server).

CommandWhat it doesKey flags
(none)Start the MCP server on stdio--http — local Streamable-HTTP on 127.0.0.1:3000/mcp
setupGuided setup: writes local config + MCP client config--scope-preset <basic|activity|sleep|heart|full|nutrition-write> · --scopes "<url …>" · --client <generic|claude|cursor|windsurf|hermes|openclaw> · --no-auth · --json
authBrowser OAuth with local callback; saves tokens with 0600 permissions--no-open — print the auth URL instead of opening the browser
checkupSetup diagnosis with ✓/✗ checks and next steps (aliases: doctor, status)--json · --client <name> · --fix — repair file permissions · --live — prove API reachability · --live-write — dry-run the write path, never POSTs
coverageData-type coverage report across list/reconcile/rollup--json · --live — redacted read-only checks against your real account
supportRedacted support bundle for GitHub issues--json · --feedback — anonymous setup-feedback bundle
onboardingShared wellness onboarding flow as JSON--pt-BR
version / helpPrint version / full usage

Beta testers wanted

Right now the most valuable thing you can contribute is hands-on setup feedback from real Fitbit, Pixel Watch, Android and Google Health API accounts.

If you have a real account to test with:

  • Run npx -y google-health-fitbit-mcp checkup and let us know whether the OAuth flow reads clearly.
  • Run npx -y google-health-fitbit-mcp support --feedback --json and drop the anonymous bundle into a GitHub issue.
  • Once OAuth is done, run npx -y google-health-fitbit-mcp coverage --live --json and post the redacted coverage report after you've reviewed it.
  • Exercise google_health_connection_status, google_health_data_inventory and google_health_daily_summary from inside your MCP client.
  • File an issue if you hit missing data types, unclear setup steps, client-specific friction or privacy concerns.
  • Please keep OAuth tokens, client secrets, local paths and personal health measurements out of public issues.

Development

bash
git clone https://github.com/BerkKilicoglu/google-health-fitbit-mcp.gitcd google-health-fitbit-mcpnpm installnpm test

npm test runs typecheck, build, MCP smoke tests (stdio + HTTP), summary fixtures, privacy/cache/retry suites, CLI UX checks and metadata validation. See CONTRIBUTING.md for guidelines and SECURITY.md for the security policy.

Links

Contact & support

License

MIT — see LICENSE.

来源：README.md，提交 f215341

工具

0
SourceWeft 尚未在沙箱中启动过该软件包，因此其工具未知。

版本历史

1
  1. v1.0.2最新Sep 16, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度，依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价，也不表示服务器安全或当前可用：可连通性是带日期的检查结果，评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手；SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头，或保持端点能够响应探测，以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list，或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分