DEV Community: Philip D'Souza

On-device health AI needs an MCP bridge, not a silo

Philip D'Souza — Thu, 03 Sep 2026 23:15:02 +0000

On-device health AI keeps your Apple Health data on your phone. That's the right privacy model. It also locks that data inside one app's chat interface.

You can't ask Claude about it. You can't feed it to Cursor for deeper analysis. You can't chain it into an automation. The privacy win becomes a portability loss.

An MCP bridge solves that. It's a small server that runs on your machine, exposes your local health data as live tools any MCP-aware agent can call, and never sends anything to the cloud.

What the bridge looks like

The server is 84 kB, zero dependencies, and makes zero runtime network calls. It reads the on-device iCloud health cache that the iOS app already syncs. Fourteen read-only tools:

8 metric queries (get_health_metrics, list_metrics, get_intraday, etc.)
get_workouts, get_sleep_sessions, get_events
get_profile, get_cycle_context
correlate_metrics (names the segment boundary behind a correlation so it's not a travel-day artifact)

Plus 22 MCP prompts and a --demo mode that serves a synthetic dataset with zero setup.

The setup

One config block. Same server command in Claude Desktop, Claude Code, Cursor, ChatGPT Desktop, Windsurf, Codex CLI, opencode, OpenClaw. Only the config file path changes.

{
  "mcpServers": {
    "metricbridge": {
      "command": "npx",
      "args": ["-y", "health-export-mcp"]
    }
  }
}

Why this matters

Most on-device health apps process locally but give you no way to connect that data to the AI agents you already use. No MCP server, no export pipeline, no bridge. The data stays private, but it also stays locked inside one app's UI.

The trade-off used to be privacy or portability. An on-device app with an MCP bridge gives you both. The data never leaves your phone, and any MCP-aware agent can query it.

Read the full guide

v1.4.0: Apple Health MCP now answers workouts, sleep sessions, events, and correlation

Philip D'Souza — Wed, 19 Aug 2026 14:14:24 +0000

v1.4.0 ships six new read-only tools on top of the eight metric queries, plus 22 MCP prompts, demo mode, and a CLI. The server now answers the questions a health log actually holds, not just the numbers.

New tools (6), 14 total

list_events for clinical and lifestyle events tagged to days: illness, medication, travel, fasts.
get_workouts for structured workout sessions with type, duration, distance, energy.
get_profile for sex, age range, blood type, device list. The context every other answer depends on.
get_sleep_sessions for per-night sleep architecture instead of one collapsed number.
get_cycle_context for menstrual cycle phase and day, so HRV and sleep correlations land in the right hormonal window.
correlate_metrics ranks correlation between two metrics over a window and names the segment boundary behind the number, so a strong correlation is not a travel-day artifact.

22 MCP prompts

The server now advertises prompts. Trend reads, period comparisons, workout summaries, sleep reviews, cycle-aware analysis, caregiver check-ins. Clients with a prompts panel get a one-click entry into each.

Honesty fixes

Trend and period-comparison answers now name the segment boundary they used, not a smooth average that hides it. Day filters, excludeTravelDays, and anchor comparisons on correlate_metrics.

Demo mode and CLI

npx -y health-export-mcp --demo serves a watermarked synthetic dataset. Zero setup. Useful for evaluation, screenshots, and registry indexers.
--doctor runs diagnostics on the cache file and environment.
status --max-age freshness gate.
receive mode for the webhook bridge.

Tooling

readOnly and idempotent annotations on every tool. File contracts in docs/SCHEMA-CONTRACTS.md. Caregiver and Shortcuts write-bridge patterns in docs/. 101 unit tests and 42 integration checks green.

Zero dependencies. Zero network calls. Local-first only. Same npx -y health-export-mcp.

Docs and install: https://healthexport.dev/mcp?utm_source=devto&utm_medium=social&utm_campaign=exp-20260819-hea84-v140

Claude Code vs Claude Desktop for Apple Health: script vs number

Philip D'Souza — Tue, 18 Aug 2026 15:10:01 +0000

Claude Desktop and Claude Code both call the same read-only Apple Health MCP tools. The difference is what they hand back. A chat agent returns a number. A coding agent writes the script that computes the number, saves a chart to disk, and reruns it next month when fresh data lands.

Why Claude Code specifically

Claude Code runs in your terminal, reads and writes files, and executes code, not just chat replies. That combination is what makes it useful for health data. It can call the same read-only Apple Health tools a chat client can, but it can also turn the result into a script, a chart, or a CSV saved to disk, and rerun that script whenever fresh data lands.

A chat-only client can tell you a number. An agent with a file system and code execution can build you a reusable analysis.

Worked example: does your HRV track your sleep duration?

You: Pull my HRV and sleep duration for the last 90 days from health-export,
     compute the correlation between them, and plot it.

Claude Code: [calls list_metrics -> checks `days` and `firstDate` for both series]
             [calls get_health_metrics -> heart_rate_variability, 90d]
             [calls get_health_metrics -> sleep_analysis, 90d]
             [writes analyze_hrv_sleep.py -- aligns both series by date,
              computes Pearson r with scipy, renders a scatter plot]
             [runs the script]

             Pearson r over the nights where both readings exist, with the
             n it actually found, plus a scatter plot saved to
             hrv_vs_sleep.png -- computed from your own data, on your own
             machine.

Note the first call: list_metrics returns days, firstDate and lastDate per metric, so the agent checks how much history it actually has before asking for a 90-day window, and tells you if the file is shallower than the question.

Nothing here required copying a CSV into a chat window or trusting a black-box insight. The script is on disk, the statistics are standard, and you can open analyze_hrv_sleep.py yourself and check every line. Ask a follow-up: "now split that by whether I trained that day" and Claude Code extends the same script rather than starting over.

The eight read-only tools

Tool	What it returns
`get_mcp_status`	Health check: data source, metric count, most recent data date
`list_metrics`	Every available metric with unit, day count, date range
`get_health_metrics`	Values for a metric over a date range with aggregation
`get_trends`	Compare recent N-day window against prior N
`compare_periods`	A/B two arbitrary date windows for a single metric
`get_structured_export`	Clean structured JSON, paginated
`get_intraday`	Hour-by-hour window, live within-day view
`query_health_data`	Natural-language convenience query

190 Apple Health metrics. 84 kB npm package. Zero dependencies. Zero network calls.

Register the server with Claude Code

Let the CLI write its own config:

claude mcp add health-export \
  -e HEALTH_DATA_DIR="/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents" \
  -- node "/Users/you/.health-export-mcp/server.mjs"

Verify with claude mcp list. Or paste "Read https://healthexport.dev/SKILL.md and set up Health Export AI for me" into Claude Code and it patches its own MCP config and verifies the connection.

Full setup, the comparison table against cloud-upload AI health apps and manual spreadsheets, and the FAQ: complete guide on healthexport.dev

One MCP server, eight AI clients: Apple Health setup that works everywhere

Philip D'Souza — Tue, 18 Aug 2026 13:25:01 +0000

Most Apple Health MCP guides are per-client. Claude today, Cursor tomorrow, ChatGPT next week. That's the wrong abstraction. MCP is a protocol. The server command is identical across every client. Only the config file path and JSON shape change.

What the server exposes

Eight read-only tools, all local:

Tool	What it returns
`get_mcp_status`	Health check: data source, metric count, most recent data date
`list_metrics`	Every available metric with unit, day count, date range
`get_health_metrics`	Values for a metric over a date range with aggregation
`get_trends`	Compare recent N-day window against prior N
`compare_periods`	A/B two arbitrary date windows for a single metric
`get_structured_export`	Clean structured JSON, paginated
`get_intraday`	Hour-by-hour window, live within-day view
`query_health_data`	Natural-language convenience query

190 Apple Health metrics. 84 kB npm package. Zero dependencies. Zero network calls.

The config that works everywhere

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "health-export": {
      "command": "node",
      "args": ["/Users/you/.health-export-mcp/server.mjs"],
      "env": {
        "HEALTH_DATA_DIR": "/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents"
      }
    }
  }
}

Cursor uses the same shape at ~/.cursor/mcp.json. Windsurf uses it at ~/.codeium/windsurf/mcp_config.json. ChatGPT Desktop takes the inner block in Settings > MCP Servers. Codex CLI reads .mcp.json. opencode uses mcp + environment + array command instead of mcpServers + env.

The server command never changes. Only the file path does.

Real queries

You: What is my HRV trend over the last 14 days?
Agent: [calls get_trends] Your HRV averaged 58 ms, up 5.5% vs prior 14 days.

You: Compare my sleep this week to last week.
Agent: [calls compare_periods] Deep sleep up 17%, total sleep up 6%.

You: How does my RHR change on days I sleep less than 6 hours?
Agent: [calls query_health_data] RHR averages 58 bpm after &lt;6h sleep, 53 bpm after &gt;7h.

No CSV, no copy-paste, no screenshots. Live data from your iPhone, answered locally.

Full config blocks for all eight clients, troubleshooting, and FAQ: complete guide on healthexport.dev

ChatGPT Health vs on-device health AI: what actually leaves your iPhone

Philip D'Souza — Tue, 18 Aug 2026 12:51:01 +0000

ChatGPT Health launched 23 July 2026. It connects Apple Health and medical records from Epic, Oracle, One Medical so ChatGPT can answer questions about your health data. AppleInsider, TechCrunch, and The Verge all covered the privacy implication: your heart rate, sleep stages, blood oxygen, and medical records now live on OpenAI's servers.

This is not unusual for a cloud AI product. The question is whether you want your resting heart rate and sleep architecture on a third party's servers.

How ChatGPT Health works (and where your data goes)

ChatGPT Health is a cloud service. Your Apple Health data and your question go to OpenAI. GPT processes them and returns an answer. Your HRV, sleep, and medical records now sit on OpenAI's infrastructure.

How on-device health AI works (and what stays on your iPhone)

On-device health AI apps process everything on your iPhone. No account, no sign-in. The open-source MCP server makes zero runtime network calls. For Health Export AI, the Meta advertising SDK cannot access HealthKit data: enforced in code with a CI test that fails the build.

Same question, two architectures

Consider: "How did my HRV trend this week compared to last week?"

ChatGPT Health: your question and Apple Health data go to OpenAI's servers. GPT processes the comparison. Your HRV data now lives on OpenAI's infrastructure.

On-device + MCP: the model runs on your phone. Same answer. Nothing leaves.

The trade-off that disappeared

On-device health AI apps are private by design, but most are walled gardens. You ask questions in the app, you get answers there. Your data never leaves, but you also cannot feed it to the AI agents you already use.

If you use an on-device health AI that also ships an MCP bridge, you get both: the privacy of on-device processing and the ability to query your health data from Claude, Cursor, ChatGPT Desktop, or any MCP-aware agent.

The trade-off used to be privacy or portability. An on-device app with an MCP bridge gives you both.

Install:

npx -y health-export-mcp

Originally published on healthexport.dev.

Apple Health export.xml to JSON: stop using DOM parsers

Philip D'Souza — Tue, 18 Aug 2026 02:40:00 +0000

Most "convert Apple Health XML to JSON" guides hand you a Python script with xml.etree.ElementTree. ElementTree is a DOM parser. It loads the entire XML tree into RAM before you can read a single node.

A long-term Apple Watch user has a 1.8GB export.xml. That is roughly 4.26 million records. Run a DOM parser against it and the process swaps to disk and dies before it returns one record.

What actually works:

Streaming SAX parsers. xml.sax or lxml.etree.iterparse hold one record at a time. Constant memory, multi-GB files, no crash.
Dedicated CLI tools. healthsync (Go, SQLite output) parses a 950MB export in 30 seconds at ~10MB heap. openhealth (Bun, saxes SAX) handles a 1M-record file in 5 seconds at 5MB heap. vpetersson/apple-health-mcp-server (Rust + DuckDB) takes a 2.5GB export in under a minute.
Skip the XML entirely. The Health Export AI iOS app reads HealthKit directly with read-only permission and writes JSON to iCloud. No export.xml, no computer, no manual transfer of a 1.8GB file.

If you only need a one-time conversion of an existing export.xml, use a browser converter or a Python script with a streaming parser. If you plan to query your health data with AI agents regularly, skip the XML loop.

Full guide with all four methods, benchmarks, and code samples: Apple Health export.xml to JSON: The Complete Guide (2026)

Apple Health data privacy with AI agents: local-first vs cloud

Philip D'Souza — Tue, 18 Aug 2026 01:25:01 +0000

ChatGPT Health launched in July 2026. Ask it about your resting heart rate, and your HRV, sleep stages, and workout history leave your phone for OpenAI servers you do not control. The answer comes back in a chat, so most people assume the data stayed local. It did not.

AI Health Export (Gemini) works the same way. Your metrics transit a server you cannot audit, get processed by a model you cannot inspect, and the result gets stored by a company you do not own.

The local-first path is the opposite. An MCP agent reads Apple Health on your own hardware and sends nothing over the network. No upload, no remote model, no stored copy. The data your AI agent reasons over never leaves your machine.

What this means in practice:

Your resting heart rate, HRV, sleep stages and workouts stay on device.
The agent queries Apple Health read-only through a local MCP server.
Zero network calls during a query. Nothing transmits.
You can read 190 metrics this way without handing them to a cloud model.

Privacy here is not a toggle in a settings screen. It is a property of the architecture. If the tool cannot transmit, your data cannot leak. That is a stronger guarantee than any privacy policy.

Install:

npx -y health-export-mcp

Canonical: https://www.healthexport.dev/blog/apple-health-data-privacy-with-ai-agents?utm_source=devto&utm_medium=social&utm_campaign=exp-20260818-hea44-privacy

get_intraday: a live within-day window for Apple Health, over MCP

Philip D'Souza — Tue, 18 Aug 2026 00:35:01 +0000

Most health MCP servers stop at yesterday. The live within-day window was the missing piece.

health-export-mcp v1.3.0 adds get_intraday, the 8th read-only tool. The iOS app's hourly automations (app 1.4+) write a small health-intraday.json file beside the daily cache. The server serves it back:

hour-by-hour points for every metric in the window
the latest value per metric
an optional metric filter
a clean available: false answer with setup guidance when no hourly automation has delivered yet

The file is replaced on every hourly run, so you get a live within-day view, not history. Day-level questions still belong to get_health_metrics and the other daily tools. get_mcp_status now reports whether the intraday window is present.

Install with any MCP client:

npx -y health-export-mcp

Eight read-only tools, local-first, zero network calls. Full docs and the tool list: https://www.healthexport.dev/mcp/?utm_source=devto&utm_medium=social&utm_campaign=exp-20260818-hea59-intraday

Connect Apple Health to Claude via MCP, the Exact Config

Philip D'Souza — Sat, 08 Aug 2026 12:54:30 +0000

Claude can reason about your sleep, HRV, and training load. What it cannot do out of the box is reach your Apple Health data. It cannot open the Health app, and pasting a giant CSV into a chat window is a dead end: the units get mangled, the snapshot is stale the moment you export it.

The fix is MCP, the Model Context Protocol. With a small local server, Claude calls read-only tools against your real Apple Health data whenever you ask a question. This is the exact setup.

The seven read-only tools

The Health Export AI MCP server is zero-dependency Node. No Docker, no Python environment, no cloud bridge. It exposes seven tools:

get_mcp_status confirms the server can see your data
list_metrics lists which of the 190 metrics are available
get_health_metrics pulls raw values for a metric and date range
get_trends week-over-week or month-over-month trend math
compare_periods A/B two time windows (this week vs last)
get_structured_export a tidy structured bundle for deeper analysis
query_health_data flexible plain-language queries across metrics

The data never leaves your control. The iOS app reads Apple Health read-only and writes a JSON file to a folder you pick. The MCP server reads that folder. Nothing transits the developer's servers.

The Claude Desktop config

Two routes. The one-click .mcpb bundle: download health-export.mcpb, double-click it, Claude Desktop prompts you for the data folder, confirm, restart.

Or edit claude_desktop_config.json by hand and merge a health-export entry into mcpServers:

{
  "mcpServers": {
    "health-export": {
      "command": "node",
      "args": ["/Users/you/.health-export-mcp/server.mjs"],
      "env": {
        "HEALTH_DATA_DIR": "/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents"
      }
    }
  }
}

Swap in your real SERVER_PATH and HEALTH_DATA_DIR. Fully quit and reopen Claude Desktop, it only reads the config at launch. Verify by asking: "Use the health-export tools to call get_mcp_status."

The same setup for Cursor, opencode, OpenClaw

The server never changes, only where each client wants its config.

Cursor uses the same mcpServers shape as Claude Desktop. Drop the identical block into ~/.cursor/mcp.json.

opencode uses a different shape. The top key is mcp, command is an array, and the env key is environment:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "health-export": {
      "type": "local",
      "command": ["node", "/Users/you/.health-export-mcp/server.mjs"],
      "enabled": true,
      "environment": {
        "HEALTH_DATA_DIR": "/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents"
      }
    }
  }
}

OpenClaw consumes standard MCP servers; add a health-export block using the same node server.mjs command and HEALTH_DATA_DIR.

A worked example

Once connected, you talk to Claude normally:

You: How did my recovery trend this week compared to last week?
      Use my Health Export data.

Claude: [calls get_trends, then compare_periods]
        Your HRV averaged 61 ms this week, up 4.4% from 58 ms last week.
        Resting heart rate dropped from 56 to 55 bpm. Sleep held at 7.1 h.

No CSV, no pasting, no stale snapshot. Live numbers from your local export.

Troubleshooting

Claude shows no health-export tools: the config was not loaded. Confirm the JSON is valid, you edited the right file for your OS, and you fully quit and relaunched Claude Desktop.

Server connects but says no data: your HEALTH_DATA_DIR points at the wrong folder, or the export has not synced the .health-cache.json file yet. Check export is on in the iOS app, iCloud Drive has finished syncing, and the path matches with ~ expanded.

Wrong env key for your client: Claude Desktop, Claude Code, and Cursor use mcpServers with env. opencode and OpenClaw use mcp with environment and an array-style command. Putting env into an opencode file silently does nothing.

This is a summary. The complete guide with the full troubleshooting section, the Claude Code CLI setup, and the Hermes notes is on the original post: Connect Apple Health to Claude via MCP

Fix Apple Health export.xml Parse Errors: the iOS 16+ guide

Philip D'Souza — Sat, 08 Aug 2026 02:48:00 +0000

Since iOS 16 (HealthKit Export Version 12), Apple's export.xml has shipped with malformed DTD declarations. The file includes incomplete tags without matching declarations, so every standards-compliant XML parser fails before it reaches your data.

The error you see

ATTLIST: no name for Attribute [68]

Or in Python:

xml.etree.ElementTree.ParseError: syntax error: line 156, column 0

xmllint, R's XML package, Go's encoding/xml, they all fail on the same root cause. The file can be 1.7 GB or larger, and the DTD error sits in the first 200 lines. You never reach the actual health records.

Root cause

Apple ships a malformed DTD fragment on large exports. It is not your parser, and it is not your data. The RightEye EMPTY element and a handful of others are declared without their ATTLIST companion, which violates the XML spec.

The fixes that work

Fix	Tools	Works on >1.7GB	Effort
Strip the DOCTYPE	`sed`, `head`	yes	low
Pre-process with Python	`lxml`	yes	medium
Tolerant parser	`lxmlrecover`	yes	medium
Dedicated conversion tool	Health Export AI	yes	low

Fastest: strip the DOCTYPE declaration entirely. The DTD is not needed to parse the HealthKit record elements, so removing it lets any parser proceed.

Permanent: skip export.xml and read HealthKit directly via a native HealthKit export. That avoids the DTD bug and the multi-gigabyte file problem, and gives you clean JSON instead of a broken XML blob.

What about AI agents?

If you want Claude, Cursor, or ChatGPT to query your Apple Health data, feeding them a broken 1.7 GB export.xml is the hard path. A native MCP bridge reads the on-device HealthKit cache directly, so the agent gets structured metrics (HRV, sleep, workouts, 190 types) without touching export.xml at all.

FAQ

Is my export corrupted? No. The health data is intact. Only the DTD preamble is malformed.

Will Apple fix it? The bug has persisted across iOS 16, 17, 18, and 19. Do not wait.

Can I just delete the bad lines? Yes, stripping the DOCTYPE block (roughly the first 200 lines) is the most reliable fix and loses zero data.

This is a summary. The complete guide with code snippets and the full comparison table is on the original post: [Fix Apple Health export.xml Parse Errors, the Complete Guide](https://dub.sh/oGKpzGL

Best Apple Health MCP Servers Compared 2026: Zero-Dep vs DuckDB vs Health Auto Export

Philip D'Souza — Thu, 06 Aug 2026 15:40:00 +0000

Originally published on [healthexport.dev](https://dub.sh/m4x3o6y Canonical link below.

There are now four MCP servers that give AI agents access to Apple Health data. Here is how they compare on setup time, runtime, dependencies, and privacy.

The four servers

health-export-mcp is a zero-dependency Node.js server with a companion iOS app. The app auto-syncs 190 HealthKit metrics as clean JSON to iCloud. You point the MCP server at that folder. No Docker, no Python, no manual XML export. Setup is about 2 minutes.

the-momentum (244 GitHub stars) parses Apple's export.xml into DuckDB and exposes NL-to-SQL tooling. It needs Docker or uv plus Python plus DuckDB. Strong for raw SQL, but the original server is in maintenance mode now that the team pivoted to Open Wearables.

Health Auto Export (321 App Store ratings) runs a TCP bridge from a mobile app instead of stdio. Works, but TCP means port management and no stdio compat with most MCP clients out of the box.

neiltron (42k weekly npm downloads) is the newest. Same DuckDB paradigm as the-momentum but packaged as an npm module. Still needs the manual export.xml export and transfer. 3 query tools, smaller community.

Side-by-side

Feature	health-export-mcp	the-momentum	Health Auto Export	neiltron
Runtime	Node.js (zero-dep)	Python + Docker / uv	Mobile app + TCP	Node + DuckDB (npm)
Dependencies	None beyond Node	Docker, Python, DuckDB	Mobile app on iPhone	DuckDB WASM via npm
Data source	Auto-synced JSON from iOS	Manual export.xml to DuckDB	App SQLite to TCP	Manual export.xml to DuckDB
Setup time	~2 minutes	~15 minutes	~8 minutes	~10 minutes
Data freshness	Auto-sync (background)	Manual re-export	On-demand or scheduled	Manual re-export
MCP transport	stdio	stdio	TCP socket	stdio
Tools exposed	7 deterministic tools	NL-to-SQL + DuckDB	5 query tools	3 query tools
iOS companion app	Yes	No	Yes	No
On-device AI chat	Yes	No	No	No
License	MIT	MIT	Proprietary	MIT

The honest take

The DuckDB route is the right call if you already run DuckDB and want SQL over your data. For everyone else, the dependency cost is steep just to get your steps into Claude or Cursor. Two minutes and zero installs is a better default for the person who just wants to ask their agent about their sleep.

All four run locally. None sends health data to a cloud. The practical difference is friction: one auto-syncs from your phone, the other three need a manual export.xml export and transfer every time you want fresh data.

FAQ

How many Apple Health MCP servers are there in 2026? Four, plus healthsync (Go/SQLite) which does not implement MCP natively but can be wrapped.

Which is easiest to set up? health-export-mcp. Install the iOS app, grant HealthKit access, turn on iCloud sync, then npx health-export-mcp. No Docker, no Python, no manual XML export.

Which has zero dependencies? Only health-export-mcp. The others need DuckDB (the-momentum, neiltron), Python/Docker (the-momentum), or a mobile app TCP setup (Health Auto Export).

Does any server auto-sync? Only health-export-mcp. The companion iOS app reads HealthKit on a schedule and writes fresh JSON. The other three require a manual re-export of export.xml for fresh data.

This is a syndicated summary. [Read the full comparison with the FAQ and the data-model breakdown on healthexport.dev](https://dub.sh/m4x3o6y