Why On-Device Health AI Apps Need an MCP Bridge — And Which Ones Have One
On-device health AI keeps your Apple Health data private. But it also locks that data inside a single app's chat. An MCP bridge breaks that lock — letting your data reach Claude, Cursor, or any AI agent — without sacrificing privacy. Here's why that matters, and why only one app ships both.
Here's the tension at the heart of private health AI.
On-device processing is the gold standard for privacy. Your heart rate, sleep stages, HRV, and 190+ other metrics never leave your iPhone. The model runs locally. The answers are computed locally. No upload, no cloud account, no server in the path. That's the right model.
But on-device also means locked in. Your data lives 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 own machine, exposes your local health data as live tools any MCP-aware agent can call, and never sends anything to the cloud. You get the privacy of on-device processing and the freedom to use your data with whatever agent you want.
Quick answer: what's the MCP bridge and why does it matter?
The Model Context Protocol (MCP) is an open standard that lets AI agents talk to external tools through a consistent interface. An MCP bridge for health data is a server that exposes your local Apple Health export as queryable tools — get_health_metrics, get_trends, compare_periods — that any MCP client (Claude Desktop, Claude Code, Cursor, VS Code, opencode) can call on demand.
Without it, an on-device health AI app is a walled garden. You type a question, get an answer, and that's it. With an MCP bridge, the same data powers your whole agent ecosystem. You can ask Claude to correlate your HRV with your sleep stages. You can have Cursor build a custom dashboard. You can pipe trends into an automation. Your data stays private and becomes useful beyond a single chat interface.
The raw numbers. In July 2026, a sweep of the on-device health AI market found 9 apps claiming on-device processing — Risi, Metrya, Ahimo, Suvi, Pharo, Priv AI, Sifa, Thryve, and Lifetrails. Every single one of them has zero MCP support. None ship a bridge, an export pipeline, or an open data format an agent can consume.
The on-device AI paradox
On-device health AI is popular for good reason. Cloud-based health tools ask you to upload your most personal data — resting heart rate, sleep patterns, HRV trends — to servers you don't control. Privacy policies and encryption help, but the data still leaves your phone. Every upload is a trust decision you have to make over and over.
On-device flips that. The data stays on your iPhone. The computation happens on your iPhone. The answer appears on your iPhone. Nothing leaves. For anyone serious about health data privacy, this is the only acceptable architecture.
But there's a downside nobody talks about: data lock-in.
An on-device health AI app gives you a chat window. You ask about your HRV trend, it answers. You ask about your sleep, it answers. Every interaction is mediated through that one app's interface and that one app's model. If you want to do something the app wasn't designed for — cross-correlate metrics, build a visualization, feed the data into a Claude Code script — you're stuck.
The app has your data. But it won't let it out.
How an MCP bridge breaks the lock
An MCP bridge is a piece of software that runs on your Mac or PC and speaks the Model Context Protocol. It reads the same local JSON export your phone produces — the clean, structured cache of your 190 HealthKit metrics — and exposes it as a set of tools any MCP client can call.
The Health Export AI MCP server, for example, ships seven read-only tools:
get_mcp_status— confirms the server can see your datalist_metrics— lists which of the 190 metrics are availableget_health_metrics— pulls raw values for a metric and date rangeget_trends— week-over-week or month-over-month trend computationscompare_periods— A/B two time windows (e.g. this week vs last)get_structured_export— a tidy structured bundle for deeper analysisquery_health_data— flexible plain-language queries across metrics
The server is zero-dependency — plain Node.js, no Docker, no Python environment, no cloud bridge. It runs entirely on your own machine, reads only from a local file, and makes zero network calls. The data never leaves your control.
Any MCP-aware client can use it. Claude Desktop, Claude Code, Cursor, VS Code, opencode, OpenClaw, Hermes — same server, same tools, same privacy model. The full setup takes about two minutes: install the iOS app to produce the export, point the MCP server at that export, and add one config block to your client.
For the exact config, see Connect Apple Health to Claude via MCP.
A worked example: the same data, two modes
Here's what the on-device-vs-bridge difference looks like in practice.
On-device only: You open the app and type "How's my HRV trending this month?" The app computes the answer locally and shows you a provenance card — the metric, the date range, the sample count, and a sparkline. You see that your HRV averaged 58 ms this month vs 62 ms last month. Good answer, fast answer, private answer. But that's where it ends.
With the MCP bridge: You open Claude Desktop and ask the same question. Claude calls get_trends against your local data, gets the same numbers, and gives you the same answer. Then you ask a follow-up: "Can you cross-reference my HRV drops with my sleep quality over the same period?" Claude calls compare_periods twice, merges the results, and shows you a chart. Then you ask: "Write a Python script that runs this correlation weekly and emails me the output." Claude writes the script and you save it.
The on-device app gave you insight. The MCP bridge gave you a pipeline.
Which on-device health AI apps have an MCP bridge?
As of August 2026, exactly one.
Health Export AI is the only on-device health AI app for iPhone that ships a production MCP bridge. The iOS app answers questions about your Apple Health data on-device with full provenance. The MCP server (open source, health-export-mcp) exposes the same data to any MCP client. You get both: a private on-device chat and a live agent pipeline.
The major on-device competitors — Risi, Metrya, Sifa, Thryve, Lifetrails, Ahimo, Suvi, Pharo, Priv AI — all run their AI locally. None of them provide an MCP server, a JSON export pipeline, or any standardized way to feed your data into an external agent. You can chat with your data inside their app, but you can't take it out.
There are also standalone MCP servers you can use without an on-device health app — the-momentum/apple-health-mcp-server (DuckDB-based) and healthsync (SQLite-based) — but these are developer tools, not consumer apps. They require you to manually export and convert your Apple Health export.xml. They have no iOS app, no on-device AI, no provenance cards, and no guided chat.
Health Export AI is the only product that bridges both worlds: consumer-friendly on-device AI for the iPhone, plus a zero-dependency MCP server for developers who want to connect their own agents.
What this looks like for developers
If you're an AI-native developer, the MCP bridge is the feature. You don't need another chat app — you already have Claude, Cursor, Codex, or opencode. What you need is a way to get your health data into those agents without a manual CSV dump or a cloud upload.
Install Health Export AI on iOS, grant Apple Health read access, and pick an export destination (iCloud Drive is the simplest — the OS syncs it to your Mac automatically). Then add this to any MCP client's config:
{
"mcpServers": {
"health-export": {
"command": "node",
"args": ["/path/to/server.mjs"],
"env": {
"HEALTH_DATA_DIR": "/path/to/export/folder"
}
}
}
}That's it. Your agent can now call get_trends, compare_periods, and list_metrics against your real, live health data. Read-only, local, no accounts. For the full setup across every client, see the MCP documentation.
Privacy note. The MCP server is fully open source (MIT license) and makes zero network calls. It reads a local JSON file and answers tool requests over stdio or HTTP. There is no telemetry, no analytics, no phone-home. You can verify every line of code.
Why most on-device apps don't ship an MCP bridge
It's not an accident that only one app has this. Building an MCP bridge means engineering a read-only export pipeline, maintaining a server that works across multiple clients, and designing tools that are actually useful to agents — not just a REST API wrapped in an MCP label. Most health AI apps are focused on the consumer chat experience and don't have the developer literacy or the incentive to build a general-purpose bridge.
There's also an obvious business reason: an MCP bridge lets users take their data out of the app. If your app's value is exclusive access to health AI, giving users a pipe to Claude or Cursor looks like you're handing them a reason to leave. The counterintuitive truth is the opposite — the bridge makes the app more valuable because your data works everywhere, not just in one place. But most apps haven't figured that out yet.
The bottom line
On-device health AI is the right privacy model. But privacy without portability is a cage with better locks.
An MCP bridge is the escape hatch. It gives you the same private, local processing you expect from an on-device app, plus the ability to use your data with any AI agent — Claude, Cursor, opencode, or whatever comes next. You don't have to choose between keeping your data on your phone and being able to actually use it.
Right now, only one app ships both. That will change — the market will catch up. But if you want private on-device health AI and an MCP bridge today, there's exactly one option.
Get on-device health AI + MCP bridge — both, today
190 Apple Health metrics answered on your iPhone with provenance cards, plus a zero-dependency MCP server for Claude, Cursor, and any agent. Local-first, no accounts, no telemetry in the MCP server.
Frequently asked questions
What is an MCP bridge for on-device health AI?
An MCP bridge is a Model Context Protocol server that runs on your own machine and exposes your local health data as live tools any MCP-aware AI agent can call — Claude, Cursor, VS Code, opencode. It lets agents query metrics, trends, and comparisons on demand without ever uploading your data to a cloud.
Which on-device health AI apps have an MCP bridge?
As of August 2026, Health Export AI is the only on-device health AI app that ships a built-in MCP bridge. Competitors like Risi, Metrya, Sifa, Thryve, and Lifetrails process data on-device but provide no MCP server, no JSON export pipeline, and no way to connect the data to external AI agents.
Why does MCP matter for private health AI?
On-device health AI keeps your data on your phone — that's good for privacy. But it also locks your data into one app's chat interface. An MCP bridge lets you use the same private data with any AI agent you want, without breaking the privacy model. You get both: the data never leaves your control, and you're not limited to one app's UI.
Does the MCP bridge work with Claude, Cursor, and VS Code?
Yes. The Health Export AI MCP server is a standard MCP server. It works with Claude Desktop, Claude Code, Cursor, VS Code, opencode, OpenClaw, Hermes, and any other MCP-compatible client. The only differences are where each client expects its config file and the JSON key names. See the MCP documentation for the exact config per client.
Does the MCP server send my data anywhere?
No. The MCP server is fully open source and makes zero network calls. It reads a local JSON file from your disk and answers tool requests over stdio or HTTP on your local machine. There is no telemetry, analytics, or phone-home functionality. You can verify every line of code on GitHub.