健康同步 MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GOOGLE_HEALTH_STORAGE_KEY | No | Required on Linux/macOS to encrypt OAuth client, tokens, and write results. Provide via secret management tool. Not needed on Windows (DPAPI CurrentUser is used). |
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 |
|---|---|
| health_statusA | 查看 OAuth 授權狀態與權限，不回傳憑證或權杖。 |
| health_catalogA | 列出官方支援的全部可寫入資料類型、欄位、操作與所需權限。 |
| health_schemaC | 取得特定資料類型的官方 Discovery 欄位與所有引用 schema。 |
| health_listC | 查詢此 OAuth 用戶端寫入的資料；保留分頁，不自動擷取整個健康歷史。 |
| health_getC | 依完整 Google Health 資源名稱讀回資料點。 |
| health_log_mealB | 寫入飲食紀錄。營養數值可省略，缺少的數值不會補零；匿名食物新增後不可直接更新。 |
| health_log_workoutA | 寫入運動或重訓場次。逐組重量、次數和動作可保存在 notes；需要實際開始與結束時間。 |
| health_createA | 新增任何官方支援寫入的健康資料類型。先用 health_schema 檢查欄位；record 只填該類型內容，不含外層 DataPoint。 |
| health_updateB | 依完整資源名稱更新可更新資料點。匿名飲食不可更新。record 填完整類型內容。 |
| health_deleteB | 明確刪除指定資料點。先預覽並取得使用者對這些資料的刪除指示。 |
| health_write_statusA | 查詢指定 idempotency_key 的本機寫入結果，避免重送。 |
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 11 tools
Most tools target distinct actions (status, catalog, schema, list, get, create, update, delete), but health_create's generic 'create any supported type' purpose overlaps with the specialized health_log_meal and health_log_workout writers. Descriptions clarify that the log_* tools are convenience wrappers for specific domains, so misselection is possible but manageable.
All 11 tools use a strict snake_case health_<verb>_<noun> pattern (health_write_status, health_log_meal, health_create, health_delete). Naming is highly predictable and consistent across the set.
11 tools is well within the ideal 3-15 range and each tool has a clear role: CRUD operations plus discovery (catalog, schema) and operational helpers (status, write_status). No redundancy that inflates the count.
Full lifecycle coverage is present: read (health_get, health_list), create (health_create plus domain-specific log_*), update (health_update), delete (health_delete), plus introspection (catalog, schema), auth status, and idempotent write verification. No obvious dead ends for a Google Health sync server.