Schema | mibly-apple-health-mcp

mibly-apple-health-mcp

Overview Schema Source Related Servers Discussions Admin

Server Configuration

Describes the environment variables required to run the server.

Name	Required	Description	Default
`MIBLY_HOST`	No	Bind address host:port	0.0.0.0:7345
`MIBLY_TOKEN`	Yes	Pairing token from the Mibly app. On first run the token is saved to ~/.mibly/config.json, so later restarts need no env var.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

Capability	Details
`tools`	{ "listChanged": true }

Tools

Functions exposed to the LLM to take actions

Name	Description
health_nowA	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.
health_detailB	Detailed time-range query for one health data type. Limited to the last 365 days. 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.

Name

Description

health_nowA

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.

health_detailB

Detailed time-range query for one health data type. Limited to the last 365 days.

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.

Prompts

Interactive templates invoked by user choice

Name	Description
No prompts

Resources

Contextual data attached and managed by the client

Name	Description
No resources

Deploy Server

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

TDQS

A3.6/5.0

Scored 2026-10-16 07:50 across 2 tools

Disambiguation5/5

health_now returns a compact latest snapshot across multiple health metrics, while health_detail queries a single metric type over a time range. Their purposes are clearly distinct and unlikely to be confused despite sharing a read-only health-data context.

Naming Consistency4/5

Both tools use snake_case with a shared health_ prefix, which is predictable and consistent. The suffix pattern is not a uniform verb_noun convention (now vs detail), but the set remains readable and coherent.

Tool Count3/5

Two tools is borderline thin for an Apple Health data server. While both roles are justified, there is no discovery, metadata, or multi-type range query tool, making the surface feel minimal.

Completeness4/5

The surface covers the core retrieval paths: latest snapshot and single-type historical queries up to 365 days. However, it lacks explicit data-type discovery and older-than-365-day access, which are minor gaps agents can work around.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers