google-health-mcp

Overview Schema Source Related Servers Discussions Admin

health_sync

Pull Google Health data into a local SQLite cache for offline queries. Sync all or selected data types incrementally, with optional date-range backfill to repair gaps.

Instructions

Sync health data to the local cache.

Fetches data from the Google Health API and stores it in SQLite for fast offline queries. Run this before using other health_get_* tools.

Syncs incrementally: only fetches data newer than the most recent entry in each table. First sync fetches the specified number of days.

Args: data_types: What to sync. Options: "all", "heart_rate", "activity", "exercises", "sleep", "weight", "spo2", "hrv", "azm", "breathing_rate", "skin_temperature", "core_temperature", "cardio_fitness", "food_log", "ecg", "irn", "account", "height", "exercise_routes", "sleep_sessions", "weight_readings", "body_fat_readings". Comma-separated for multiple, e.g. "sleep,hrv". Default: "all". days: Days of history for first sync (default: 30). Ignored on subsequent syncs (uses last synced date). since: Optional "YYYY-MM-DD" backfill date. When set, fetches from this date regardless of what is already cached - use to pull history older than the current cache. Overrides incremental resume and days. until: Optional "YYYY-MM-DD" inclusive end date; requires since. Together they re-fetch and upsert exactly the since..until window - use to repair a gap in the middle of the cache without re-pulling everything from the gap to today.

Returns summary of records synced per data type. Not for querying data - use health_get_heart_rate, health_get_activity, health_get_sleep, etc. instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "health_sync"
  }
}

Input Schema

Name	Required	Default
`days`	No
`since`	No
`until`	No
`data_types`	No	all

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.12.0Nov 7, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "health_syncOutput",
-  "type": "object"
-}New value: +null

First observedv1.0.0Aug 20, 2026

TDQS

A4.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does most of it well: it discloses that the operation writes/upserts into SQLite, that sync is incremental against the newest row per table, that days is ignored after the first sync, and the precedence rules among since/until/days. It does not disclose Google Health API auth requirements, rate limits, partial-failure behavior, or whether existing rows are overwritten versus merged (only 'upsert' is implied).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and prerequisite are front-loaded in the first lines, then behavior, then per-argument detail, then the return value and the anti-use case. The long data_types enumeration is unavoidable since the schema carries no enum, and there is no filler sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-parameter, zero-annotation sync tool with no output schema, the description covers the write target, incremental logic, argument precedence, return shape ('summary of records synced per data type'), and the correct alternative tools. Nothing essential to calling it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does: every one of the four parameters is documented with default, accepted format (integer days, 'YYYY-MM-DD' for since/until), the full enumerable set of data_types values with a comma-separated multi-value example, and interaction rules (until requires since; since overrides incremental resume and days). This far exceeds what the bare schema conveys.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Sync health data to the local cache') and immediately explains the mechanism: fetch from Google Health API, store in SQLite for offline queries. It is unmistakably distinct from the health_get_* siblings, which read from that cache rather than populate it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit ordering guidance ('Run this before using other health_get_* tools') and an explicit exclusion with named alternatives: 'Not for querying data - use health_get_heart_rate, health_get_activity, health_get_sleep, etc. instead.' It also names the concrete situations for since/until (backfill older history, repair a mid-cache gap), so no inference is required.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.