The Two-App Tax: The Most-Starred Apple Health MCP Server Still Needs a Separate CSV Exporter
You found the most-starred Apple Health MCP server on GitHub, cloned it, wired it into your agent, and asked a question. It answered with nothing. Before it can read a single metric, a second app has to turn your health data into a CSV. That is the two-app tax, and it is not a small one.
Quick answer
The star-leading Apple Health MCP server, neiltron/apple-health-mcp, does not parse Apple's native export.xml. It reads a CSV that a separate iOS exporter app has to produce first (evidence E11 in our weekly market pack, read 2026-10-18). So the real install is two apps and a file handoff, not one server. A server that reads export.xml or a JSON export directly collapses that to one step.
What the two-app tax looks like
Here is the actual sequence a new user walks through with a CSV-only server:
- Install the MCP server from GitHub and add it to your agent config.
- Discover it cannot read anything yet, because there is no CSV.
- Install a separate exporter app on the iPhone, and usually pay for it, because scheduled CSV export is rarely free.
- Configure the exporter's filters so the columns match what the server expects.
- Run an export, then find and copy the file to the machine where the agent runs.
- Re-export by hand every time you want fresh numbers, because the two apps do not know about each other.
That is the tax: an extra app, an extra config, and a recurring manual step that has nothing to do with asking your health data a question. The frustrating part is that step three is where most people quit, because now they are paying a second vendor to make the first tool work.
Why the server does not just read export.xml
Apple's native export is a single XML file that can run from hundreds of megabytes into the gigabytes. Parsing it needs streaming, not a naive load, and Apple's schema is verbose: every record carries a type, a source, a unit, start and end times, and a value. Writing that parser well is more work than wiring up a CSV reader, so a lot of servers take the CSV shortcut and push the hard part onto the user.
That shortcut has a cost beyond convenience. CSV is a lossy shape for health data. Nested workout routes, sleep stage streams and unit metadata do not survive the flatten, so the agent gets a thinner picture than the export actually contains.
One app, or two
| Two-app setup (separate exporter) | One-app setup (direct export) | |
|---|---|---|
| Apps to install | MCP server plus an exporter app | The one app that ships both |
| Input the server reads | A CSV you produced elsewhere | The app's own JSON export, directly |
| Native export.xml | Unsupported | Parsed or converted for you |
| Refresh | Manual re-export and file copy | Re-export on the phone, file stays in place |
| Data lost in the handoff | Nested records flattened away | Kept, units and metadata included |
| Vendors in the path | Two | One |
How we sourced this. The CSV-only behaviour above is from the project's own repository as read on 2026-10-18 (E11). Repos change, so check the current README before you install. We are describing a design trade, not accusing anyone of a bug.
Why you should care even if it works
Two apps means two update paths. When iOS changes a HealthKit permission, or when the exporter changes its CSV columns, your server silently stops understanding the file. The failure is quiet: the agent just answers with less, or answers nothing, and you spend an evening diffing headers.
It also doubles the privacy surface. Now two vendors' code touches your health export on the way to your agent. If your whole reason for choosing a local MCP server was to keep the path short, a required second app undoes it.
The one-app path
MetricBridge is the app and the source of the data. It exports 190 Apple Health metrics as clean local JSON, and its zero-dependency stdio MCP server reads that export directly, so there is no separate exporter and no CSV to reconcile. Sixteen read-only tools, Node.js 18 or newer, one path to your export folder.
{
"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"
}
}
}
}Ask the agent to call get_mcp_status and it confirms the server is up and the data is found. Then the questions are ordinary: how HRV trended this week, which nights sleep stages shifted, whether resting heart rate has drifted over 30 days. All of it is a deviation from your own baseline, not a verdict about your health.
FAQ
Why does an Apple Health MCP server need a separate exporter?
Because Apple's native export is a large, verbose XML file and parsing it properly is real work. Some servers take the shortcut of reading a CSV instead, which means a separate iOS exporter app has to produce that CSV first. That is the two-app tax.
Can an Apple Health MCP server read export.xml directly?
Some can. The star-leading CSV-only server cannot, and treats export.xml as unsupported. A server that reads a structured JSON export or parses the XML directly removes the second app entirely.
Does the CSV route lose any health data?
Yes. Nested structures like workout routes and sleep stage streams do not survive a flatten into CSV, and unit metadata is often dropped. The agent gets a thinner dataset than your export actually contains.
What is the smallest Apple Health MCP setup I can run?
One app that both exports your data and ships the MCP server. MetricBridge exports 190 metrics as local JSON and its open-source stdio server reads that export with no second app, no CSV and no cloud in the path.
Doing this yourself? MetricBridge handles the export step: all 190 metrics as local JSON, with the open-source MCP server (GitHub).
One app. Not two.
MetricBridge is a $24.99 one-time unlock: the export, the raw MCP server, and the on-device Ask and Weekly Brief, with no separate exporter to install and nothing on our servers.