mcp-google-health

daily_roll_up_data_points

Read-only

Aggregates health data into daily civil-day windows in the user's time zone, so you can summarize metrics such as steps or calories over a date range.

Instructions

Aggregate a data type into civil-day windows in the user's time zone, such as daily steps or calories. endDate is exclusive. At most 14 days for heart-rate, active-minutes, total-calories, and calories-in-heart-rate-zone, 90 days otherwise.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dataType": "<dataType>",
      "startDate": "<startDate>",
      "endDate": "<endDate>"
    },
    "name": "daily_roll_up_data_points"
  }
}

Input Schema

Name	Required	Description
`endDate`	Yes	Exclusive end date, YYYY-MM-DD.
`dataType`	Yes	Data type in kebab case, such as steps, sleep, or heart-rate. See list_data_types.
`pageSize`	No
`pageToken`	No	nextPageToken from the previous response.
`startDate`	Yes	Civil date in the user's time zone, YYYY-MM-DD.
`apiVersion`	No	API version. Defaults to v4, or v4beta for beta-only data types.
`windowSizeDays`	No	Days per window. Default 1.
`dataSourceFamily`	No	Data sources: all-sources (default), google-wearables (Fitbit and Pixel devices only), google-sources (Google devices, manual logs, Health Connect), or self-sources (data this client wrote).

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: aggregation into civil-day windows keyed to the user's time zone, an exclusive endDate boundary, and hard date-range limits that will cause requests to fail. It stops short of describing the returned window shape or how pagination behaves across windows.

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

Conciseness4/5

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

Three short sentences, front-loaded with the core action, then the boundary rule, then the limits – a logical order with almost no filler. The examples 'daily steps or calories' earn their place by making the abstraction concrete; only the endDate sentence is arguably redundant with the schema.

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

Completeness4/5

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

For an eight-parameter read tool with 88% schema coverage and no output schema, the description covers the highest-risk unknowns: time-zone semantics, exclusive end date, and failure-triggering span limits. Remaining gaps (return-value shape, windowStitching behavior, pagination) are modest given the rich schema, though the lack of an output schema means the response format is undocumented anywhere.

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

Parameters3/5

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

Schema description coverage is 88%, so most parameters are already documented, and the description's 'endDate is exclusive' largely repeats the schema's own wording. The phrase 'civil-day windows' is the only real semantic addition, implicitly framing windowSizeDays as a window count in days rather than a raw range, but the description never explains windowSizeDays, pageToken, or dataSourceFamily behavior beyond the schema.

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 gives a specific verb and resource: 'Aggregate a data type into civil-day windows in the user's time zone,' reinforced by concrete examples (daily steps, calories). It is clear what the tool produces, but it never distinguishes itself from the near-identically named sibling roll_up_data_points, leaving the agent to guess which aggregation entry point to pick.

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?

Usage is only implied through constraints: the per-data-type date-span caps (14 days for heart-rate, active-minutes, total-calories, calories-in-heart-rate-zone; 90 days otherwise) tell the agent how far a request may reach. There is no explicit statement of when to choose this over roll_up_data_points, list_data_points, or list_data_types, and no mention of prerequisites such as obtaining a valid dataType.

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