Vaultbeat Apple Health

Your AI agent reads your Apple Health data: sleep, HRV, cycle, workouts. Decrypted on your machine

LLM Mart 2 views 9 listing impressions
Transport
Not stated
Package
—
Registry id
io.github.Fino-wind/vaultbeat-apple-health

No install snippet on purpose. A working MCP config is a command, its arguments and an environment block — the last two are where API keys live, so this catalogue never stores them and cannot publish them. Follow the link above for the authors' own instructions.

Your Apple Health data — sleep stages, cycle, HRV, resting heart rate, workouts, weight, VO₂ max, meals, lifts, notes — readable and writable by your own AI agent (Claude Code, Hermes, OpenClaw, anything MCP), end-to-end encrypted so that only your machine ever sees plaintext. The Vaultbeat iPhone app captures from HealthKit; this package is the local server that decrypts for the agent.

Technically: the local service program for Vaultbeat's encrypted health-data recipient flow. Published externally as Fino-wind/vaultbeat-apple-health (public package name vaultbeat-apple-health since 0.6.2; vaultbeat-mcp and vaultbeat-mcp-local remain back-compat console scripts). This directory is the source of truth — after any user-visible change here, re-export the public repo and update its README tool table + the website /mcp page (see CLAUDE.md "Sync duty").

It runs on the user's computer, generates the Curve25519 keypair used by the iOS app, shows a QR binding payload, receives a one-time server token from the cloud API, and then exposes decrypted health data — sleep, water, weight, cycle, activity, vitals — through the MCP server, and only through it. Read-only for health data: writes come from the iOS app or from this server's own log_* tools.

Commands

There are six, and none of them reads health data. Health data has exactly one exit — the MCP protocol — so the commands here only pair a machine, check that pairing, and start the server. See "Why the CLI cannot read health data" below.

python -m pip install -e './mcp-local-server[qr]'

vaultbeat-apple-health bind      # pair this machine with the iOS app (QR)
vaultbeat-apple-health status    # local binding state
vaultbeat-apple-health doctor    # self-diagnose config, key, cloud reachability
vaultbeat-apple-health init      # generate a keypair + config without pairing
vaultbeat-apple-health poll      # poll once for a pending authorization

# run as an MCP server — this is how health data is read
vaultbeat-apple-health serve --transport stdio
vaultbeat-apple-health serve --transport http --host 127.0.0.1 --port 8000 --path /mcp
vaultbeat-apple-health --demo serve --transport stdio   # synthetic dataset, wired into a client
vaultbeat-apple-health --demo doctor

Why the CLI cannot read health data

Until 0.7.4 this package shipped fifteen data subcommands (sleep, water, weight, menstrual, hrv, …) that printed decrypted health JSON to stdout. They were removed, and nothing was lost: every one of them had an MCP tool doing the same job (sleep → vaultbeat_sync_sleep, water → get_water_intake, and so on), while the MCP side additionally carries whole capabilities the CLI never had — food, basal energy, total energy, VO₂ max, the metric-series tools, and every log_* writer.

The CLI half was not a second feature, it was a second door into the same room — and a door that skipped everything the MCP tools state about what they return: how many days are actually covered, why an empty result is not a zero, which plan clamps the window. Any agent with shell access could read a person's cycle history by running a command, bypassing all of it. One exit is the property worth having, so there is one exit.

From the project's README.