Skip to main content
Glama
Sign In
Google Health MCP

Google Health MCP

by davidmosiah
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Google Health Daily Rollup

google_health_daily_rollup
Read-onlyIdempotent

Aggregate daily Google Health metrics such as steps, distance, calories, active minutes, weight, and heart summaries over civil days to retrieve per-day rollups.

Instructions

Aggregate a data type over civil days using Google Health dailyRollUp. Useful for steps, distance, calories, active minutes, weight and heart summaries.

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": "google_health_daily_rollup"
  }
}

Input Schema

NameRequiredDescriptionDefault
end_dateNoExclusive end date as YYYY-MM-DD. Defaults to the next day.today
data_typeNoGoogle Health data type in kebab case. Supported slugs (call google_health_list_data_types for units and which verbs each supports): active-energy-burned, active-minutes, active-zone-minutes, activity-level, altitude, blood-glucose, body-fat, calories-in-heart-rate-zone, core-body-temperature, daily-heart-rate-variability, daily-heart-rate-zones, daily-oxygen-saturation, daily-respiratory-rate, daily-resting-heart-rate, daily-sleep-temperature-derivations, daily-vo2-max, distance, electrocardiogram, exercise, floors, food, food-measurement-unit, heart-rate, heart-rate-variability, height, hydration-log, irregular-rhythm-notification, nutrition-log, oxygen-saturation, respiratory-rate-sleep-summary, run-vo2-max, sedentary-period, sleep, steps, swim-lengths-data, time-in-heart-rate-zone, total-calories, vo2-max, weight. Other valid v4 kebab-case slugs are also accepted.steps
page_sizeNoPage size for daily rollup windows. Must satisfy window_size_days * page_size <= the data type's max rollup duration (90 days for nutrition-log).
page_tokenNo
start_dateNotoday
privacy_modeNoOptional per-call privacy override. Defaults to GOOGLE_HEALTH_PRIVACY_MODE or structured. raw returns upstream Google Health JSON.
response_formatNomarkdown
window_size_daysNo
data_source_familyNo
explicit_user_intentNoRequired true when privacy_mode=raw (agent escalation of redaction).

Output Schema

NameRequiredDescriptionDefault
dataYes
endpointYes
privacy_modeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.7.7
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • changedOutput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. Addedv0.7.3
  3. Removedv0.5.3
  4. Changed1 schema field changedv0.5.1
    • changedInput schema / properties / data_type / description
      Previous value: -"Google Health data type in kebab case, e.g. steps, sleep, heart-rate, daily-resting-heart-rate."New value: +"Google Health data type in kebab case. Supported slugs (call google_health_list_data_types for units and which verbs each supports): active-energy-burned, active-minutes, active-zone-minutes, activity-level, altitude, blood-glucose, body-fat, calories-in-heart-rate-zone, core-body-temperature, daily-heart-rate-variability, daily-heart-rate-zones, daily-oxygen-saturation, daily-respiratory-rate, daily-resting-heart-rate, daily-sleep-temperature-derivations, daily-vo2-max, distance, electrocardiogram, exercise, floors, food, food-measurement-unit, heart-rate, heart-rate-variability, height, hydration-log, irregular-rhythm-notification, nutrition-log, oxygen-saturation, respiratory-rate-sleep-summary, run-vo2-max, sedentary-period, sleep, steps, swim-lengths-data, time-in-heart-rate-zone, total-calories, vo2-max, weight. Other valid v4 kebab-case slugs are also accepted."
  5. First observedv0.1.3

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a small behavioral detail that aggregation happens over 'civil days' using Google Health dailyRollUp, but it does not describe pagination behavior, date-range semantics, or privacy/redaction behavior beyond what the schema exposes.

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?

The description is a single focused sentence that front-loads the core purpose and then gives concrete use-case examples. No words are wasted, and it is appropriately sized for the level of detail it intends to convey.

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

Completeness2/5

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

For a tool with 10 parameters, output schema, and a large sibling family, one sentence is insufficient. The description omits how start_date/end_date relate to civil-day windows, the role of window_size_days and page_size, the privacy_mode/raw behavior, and when to choose this over google_health_rollup or google_health_daily_summary. Although annotations and schema carry some of the burden, the overall context for correct invocation is incomplete.

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

Parameters2/5

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

Schema description coverage is only 50%, with start_date, page_token, window_size_days, data_source_family, and explicit_user_intent lacking descriptions. The tool description does not compensate for these gaps: it only lists example data types, which are already enumerated in the data_type schema. An agent would not learn the meaning of window_size_days, page_token, or the date semantics from either the description or those parameter schemas.

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

Purpose4/5

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

The description clearly states the operation ('Aggregate a data type over civil days') and identifies the resource and use cases ('steps, distance, calories, active minutes, weight and heart summaries'). It does not explicitly differentiate from close siblings like google_health_rollup or google_health_daily_summary, but the dailyRollUp reference makes the intent reasonably distinct.

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

Usage Guidelines3/5

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

The phrase 'Useful for steps, distance, calories, active minutes, weight and heart summaries' implies common use cases but provides no explicit guidance on when to prefer this tool over google_health_rollup, google_health_daily_summary, or google_health_list_data_points. There are no exclusion criteria or alternative tool mentions, so usage guidance remains inferred rather than stated.

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

Deploy Server

Other Tools