Skip to main content
Glama
littlenew117

mibly-apple-health-mcp

by littlenew117
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Latest Apple Health snapshot

health_now

Retrieve a compact snapshot of recent sleep, steps, heart rate, HRV, workouts, weight, body fat, and optional menstrual flow from Apple Health for quick status checks.

Instructions

Compact snapshot of the user's most recent sleep, steps, heart rate (latest hourly summary), resting heart rate, walking heart rate average, HRV, workout, weight, body fat, and (if the user opted in separately) menstrual flow samples pushed from their iPhone. Use this for quick, high-frequency status checks. Sleep adds date (wake-up date), totalSleepMinutes, deepMinutes, coreMinutes, remMinutes, awakeMinutes, sleepStart and sleepEnd when available; missing stages are null, and legacy sleep may contain only value/min. Body fat is bodyFat with value as a percentage (23.5 means 23.5%) and unit %.

Health data consumption and presentation (Local and Cloud):

  • Time/timezone: sleepStart, sleepEnd, start and end may be ISO 8601 UTC timestamps ending in Z. Preserve raw timestamps for storage and calculations. When presenting clock times, convert UTC to the user's local timezone when that timezone is known. Do not display UTC clock times as though they were local. Do not assume the Agent host timezone: a VPS or server may use a different timezone. If the user's timezone is unknown, explicitly label UTC times as UTC or ask for their timezone.

  • Sleep date: date is already the wake-up calendar date calculated by Mibly using the iPhone's local calendar. Treat date as authoritative for the sleep record. Do not recompute or change date from sleepStart/sleepEnd UTC timestamps.

  • Sleep minutes: durations and stage values may contain fractional minutes. Preserve raw fractional values for calculations. When presenting whole minutes, round to the nearest minute; do not truncate (for example, 59.6 minutes displays as 60 minutes).

  • Missing sleep stages: null means stage data is unavailable. Never interpret null as 0. Never invent or infer a missing sleep stage.

  • Body Fat: bodyFat.value is already a human percentage: 23.5 means 23.5%. Do not divide by 100 or multiply by 100 when presenting it.

  • Heart rate: a heartRate sample is an hourly summary, not a single reading. value is that hour's average bpm; heartRateSummary has min, avg, max, count and context. context is sedentary (still), active (moving) or unknown (Apple Health did not label it); the same hour can appear once per context. The newest hour may still be in progress and is replaced when updated. Older samples may be single readings without heartRateSummary.

  • Resting heart rate: restingHeartRate and walkingHeartRateAverage are separate daily values from Apple Health (one per day, bpm). Use restingHeartRate for the user's resting heart rate; never derive it from heartRate minimums or sedentary averages, and do not compare active hours with sedentary hours as if they were the same kind of reading. These are consumption/presentation rules only; preserve the raw Health data and existing calculations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.1

TDQS

A3.7/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 so well: it discloses that missing stages are null (and must not be read as 0), that heartRate is an hourly summary that can repeat per context, that resting/walking heart rate are separate daily values, and that timestamps are UTC. It stops short of the operational traits an agent might still want (freshness/staleness of the snapshot, whether data can be absent entirely, auth needs).

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

Conciseness3/5

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

The core purpose is front-loaded in one sentence, which is good. But the bulk of the text is output-consumption/presentation policy (rounding rules, timezone conversion, body-fat percentage warnings) that reads like return-value documentation rather than tool selection guidance, and some directives ('preserve raw values') repeat across sections. Useful content, but not tightly scoped to the description's job.

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?

With no output schema and no annotations, the description sensibly compensates by documenting the shape and semantics of most returned fields, especially sleep and heart rate. Steps, HRV, workout, weight, and menstrual flow are only named, not described, leaving some return semantics thin, but overall it is sufficient to call and interpret the tool.

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

Parameters4/5

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. The schema is an empty object, so no coverage gap exists.

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 opening sentence names a precise resource and enumerates its contents (sleep, steps, heart rate, HRV, workout, weight, body fat, menstrual flow), so the agent knows exactly what this returns. It distinguishes itself implicitly as the 'latest/compact' counterpart, but never names the sibling health_detail, so the boundary between the two is only inferable.

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?

'Use this for quick, high-frequency status checks' gives a clear intended context, which is more than nothing. However, it never names health_detail as the alternative, states no when-not-to-use condition, and gives no guidance on choosing between a snapshot and a detailed pull.

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