P.R.O. Apple Health MCP

Detailed health data

fetch_health_data

Idempotent

Request or retrieve detailed Apple Health data for a date or workout. Supported scopes cover heart-rate series, sleep stages, workout details and workout routes. status=requested means the phone has not uploaded the data yet. Opening P.R.O. fulfils the request; a later call with the same arguments retrieves it, and P.R.O. then also sends the last 30 days (kept 7 days), so later dates in that range answer directly. Other detailed payloads expire after 48 hours.

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": {
      "scope": "<scope>"
    },
    "name": "fetch_health_data"
  }
}

Input Schema

Name	Required	Description
`date`	No	Calendar date YYYY-MM-DD. Required for heart_rate_series and sleep_stages; for sleep it is the morning the user woke up.
`scope`	Yes	What to fetch: heart_rate_series (intraday HR for one day), sleep_stages (awake/core/deep/rem for one night), workout_details (HR series and per-km splits of one workout), workout_route (GPS track of one workout).
`workout_id`	No	Workout UUID as returned by get_workouts. Required for workout_details and workout_route.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Substantial context beyond annotations: the async request pattern, what status=requested means, that data is only produced once the phone uploads via opening P.R.O., 48-hour payload expiry, and the 7-day retention of the 30-day backfill. This also explains the readOnlyHint=false annotation — the call triggers a sync request rather than being a pure read — so there is no contradiction.

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?

Front-loaded with purpose and scopes, then the lifecycle behavior, with every sentence carrying information. It is dense but coherent; the retention detail ('kept 7 days') is slightly cryptic but earns its place for planning repeated calls.

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 asynchronous, stateful tool with no output schema, the description covers the request lifecycle, status signal, and expiry, which is what an agent needs to retry correctly. It does not describe the shape of a successful payload, but the absence of an output schema makes that a minor gap.

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 coverage is 100%, so the enum scopes, date format, and workout_id source are already fully documented in the schema. The description reinforces the same-arguments retry behavior but adds no new parameter syntax or constraints. Baseline 3 is appropriate.

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?

States a specific verb-plus-resource ('Request or retrieve detailed Apple Health data') and enumerates the exact payloads covered (heart-rate series, sleep stages, workout details, routes). This cleanly separates it from siblings like get_daily_metrics and get_workouts, which return aggregate or list data rather than raw detail.

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

Usage Guidelines4/5

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

It spells out the request/retrieve workflow precisely: a first call may return status=requested, opening P.R.O. fulfils it, and re-calling with the same arguments retrieves. It also explains that a 30-day backfill (kept 7 days) makes later dates answer directly. It lacks an explicit contrast with get_daily_metrics for non-detailed queries, so not a full 5.

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

All P.R.O. Apple Health MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?