DEV Community: Philip D'Souza

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