The On-Device Health AI Shortlist: Which Apple Health Apps Your Agent Can Actually Reach
On-device health AI got crowded in 2026. The feature lists all look the same. The one question that actually sorts them is whether your AI agent can reach the data, or whether the app answers only inside its own chat window.
AI-assisted, human reviewed. How we use AI
Quick answer
An on-device health app is only "reachable" if a standard MCP client can call tools on your data with no copy-paste step. That splits the category into three shapes: apps that answer on the phone and ship a local MCP bridge (MetricBridge), apps that answer on the phone with no bridge at all, and pass-through tools that hand your numbers to the agent you already run (Mibly). Most of the 2026 launch wave is the second shape, and the second shape cannot feed an agent by design.
The three shapes, and why the shape beats the feature list
Every app in this category now claims "on-device", "private", and "no cloud". Those words describe where the model runs, not where your data ends up. The thing that changes what you can actually do is the integration shape.
- Answer plus bridge. The app answers your questions itself, on the phone, and separately exposes a local MCP server your desktop agent can read. Two readers, one dataset.
- Answer only. The app answers in its own UI and ships no server and no connector page. You get the answer, but your agent never sees the numbers.
- Pass-through. The app does not answer at all. It hands the raw rows to your agent and lets the agent answer. "Mibly doesn't read your data. Your AI does," is the pitch.
None of these is automatically better. They solve different jobs. But if you bought the app to work with Claude or Cursor, only the first and third shapes do anything for you.
MetricBridge: answers on the phone, and a local bridge your agent can read
MetricBridge is the answer-plus-bridge shape. The iPhone app reads Apple Health read-only, gives you an on-device Ask that shows a provenance card (the actual numbers behind each answer), and writes a JSON snapshot to a destination you pick, your iCloud Drive, a synced folder, or a webhook you run. The open-source MCP server then reads that folder on your own machine. The privacy line is scoped to health data: your health data never reaches us or a cloud AI.
Because the server is local stdio, any MCP host can drive it. Here is the whole Claude Desktop config, and this is the part you actually paste:
{
"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"
}
}
}
}Then verify the connection by asking the agent to call get_mcp_status. A healthy response confirms two things separately: the server is up, and it found your data source. That single tool is also the fastest way to audit any Apple Health MCP server, because it tells you what the agent can actually see rather than what the listing claims. The export side covers 194 HealthKit metrics. The full client configs for Cursor, Claude Code, opencode and Hermes live on the MCP page.
Mibly: the pass-through end of the shortlist
Mibly takes the opposite bet. It markets itself as a pass-through that hands data to your own agent rather than answering: Mibly doesn't read your data. Your AI does. If you already pay for a strong general model and you want raw access rather than a second chat UI, that is a coherent design. The trade-off is that there is no on-device answer: when your agent is unavailable, so is your app's ability to answer anything.
The raw-number tools: Health Export Pro and healthmd.app
The rest of the field leans on counts and helpers. Health Export Pro leads with 190+ HealthKit types, a metric-count pitch that predates the current 194-metric bar. healthmd.app takes a different route: a signed healthmd-mcp stdio helper, 21 fixed tools, and a Mac loopback API on 127.0.0.1:17645. Both are honest about being pipes. Neither is a device that answers.
Check any app in five minutes. Three questions sort the whole category:
1. Does it publish an MCP server or a documented connector page?
2. Is that server local (a command you run) or hosted (an endpoint plus an account)?
3. What exactly does the install page tell you to paste? If there is no paste command and no connector page, there is no bridge.
How to read the close calls
On-device is not a privacy policy. The model can run on the phone while the app still forwards rows to a hosted agent. The claim that means something is the scoped one: what leaves, and to whom.
A hosted bridge re-creates the problem. If the "MCP server" is really a remote endpoint with an account, somebody runs a database that holds your rows. A local stdio server that reads a file you own keeps the data on hardware you control.
FAQ
What does it mean for a health app to be reachable by an AI agent?
It means a standard MCP client (Claude Desktop, Claude Code, Cursor, or any MCP host) can call tools on your data without a copy-paste step. Reachable apps ship either a local MCP server that reads your export, or a documented pass-through that hands your numbers to the agent you already run. An app that only answers inside its own chat window is not reachable.
Is an on-device app automatically private?
No. On-device describes where the model runs, not where your data goes. A pass-through app can still forward your rows to a hosted agent, and a mobile app can still ship an advertising SDK. Read the specific claim: MetricBridge's privacy line is scoped to health data, and its exports go to a folder you choose.
How do I check in five minutes whether an app can reach my agent?
Ask three questions. Does it publish an MCP server or a documented connector? Is the server local (a command you run) or hosted (an endpoint and an account)? What does the install page tell you to paste? If there is no paste command and no connector page, there is no bridge.
Does the data leave the phone if I use an MCP bridge?
With a local stdio bridge, the app writes a JSON snapshot to a destination you pick, and the agent reads that file on your own machine. Nothing routes through the app maker's servers. Where your data goes is then a function of which agent you point at it.
Shortlist it yourself. MetricBridge answers on the phone and ships the local MCP bridge (GitHub), covering all 194 metrics.
One app that answers and connects
The iPhone answers with a provenance card. Your desktop agent reads the same data over local MCP. Nothing to host, nothing of ours in the path.
Where it goes: the app reads Apple Health read-only and writes JSON to a folder you pick. Nothing reaches us or a cloud AI. What you get: all 194 metrics, the on-device Ask, the local MCP bridge, the Mac app and the Watch app. Setup: about two minutes. Price: $24.99 one time after a 7-day free trial, not a subscription. Your phone: works on any iPhone the app runs on; Apple Intelligence is not needed for the export or MCP.
MetricBridge is a general-wellness app, not a regulated medical device. Everything here is wellness information, not medical advice. Comparisons describe public product pages as dated and linked above; every app's own site is the source for what it claims.