The On-Device AND Agent-Connectable Venn Diagram
Most Apple Health AI apps sit in one circle or the other. A group answers questions on the iPhone and never touches a server. Another group connects your data to Claude or ChatGPT and puts a copy in the cloud. Very few sit in the overlap, and that overlap is the whole decision.
AI-assisted, human reviewed. How we use AI
Quick answer
On-device and agent-connectable are two separate claims, and most Apple Health AI apps hold only one of them. On-device means the model that reads your data runs on your iPhone and the rows stay there. Agent-connectable means an outside agent, Claude or Cursor or ChatGPT desktop, can read the same data through an MCP server. The apps that do both are the ones where you keep the privacy and still get the agent, and there are not many of them.
Two claims, two different tests
The two properties sound related, and that is the trap. They are independent. A listing can be aggressively private and completely closed. Another can be wide open to every agent and hold a full copy of your history on a vendor server. Neither claim implies the other, so you have to test them separately.
Test one is the computation. Where does the answer get built? If the app says it runs a model on the iPhone, or computes from your data without a round trip, that is the on-device claim. The tell is what the app can do with airplane mode on.
Test two is the access surface. Can anything other than the app's own chat window read your numbers? Look for an MCP server, a documented tool list, a config block you can paste. If the only way to ask a question is inside the app, the answer to test two is no.
The four quadrants
Put the two tests on two axes and the category splits cleanly.
| Quadrant | On-device | Agent-connectable | What it feels like to use |
|---|---|---|---|
| On-device only | Yes | No | Private chat inside one app. Nothing else can read the data. |
| Agent-connectable only | No | Yes | Claude can read it, and a copy lives somewhere you do not control. |
| Neither | No | No | Charts, a PDF, and an aggregate summary that leaves out your real numbers. |
| Both | Yes | Yes | The agent reads numbers computed on your phone, and nothing sits on a server. |
The bottom row is small, and it is the only row where you are not trading one property for the other. That is the whole argument for a Venn diagram here: the interesting question is not which app is most private or which connects to the most clients. It is which app is in both circles at once.
Why on-device alone leaves you stuck
An on-device app with no bridge is a walled garden with excellent walls. Your data is safe and the answers are fast, but the app is the ceiling. You cannot ask Claude to compare last month to this one, because Claude cannot see the data. You cannot write a script over it, because there is no file and no tool. You cannot point Cursor at it and build your own view.
This is a real trade, and some people want exactly that. It just is not the same product as one that also hands your numbers to an agent.
Why agent-connectable alone is not on-device
The reverse trade is worse, because it quietly undoes the point. The agent you are connecting to lives in a datacentre. If the connection is a hosted connector, the vendor holds a copy of your rows and your questions become round trips to a service. If the connection is a local server that only runs inside a desktop companion app, then your phone's data is available exactly when that app is open, which is a strange definition of local.
Neither of those is dishonest. The honest version of both-at-once is narrower than the marketing suggests: your iPhone computes, and a server on your own machine reads a file on your own disk.
The contrast, measured
Here is the same decision as a table, with the two figures we can verify on our own pages. Every contrast in this table carries an evidence id from our market pack: E1 is the open-source server's runtime behaviour, E2 is the published tool surface on our MCP page.
| On-device app with an agent bridge | Cloud health AI | |
|---|---|---|
| Where the answer is computed | On the iPhone | On vendor servers |
| Network calls the MCP server makes at runtime | Zero (E1) | Every tool call is a round trip |
| Agent surface | 16 read-only MCP tools and 22 prompts (E2) | Usually none, or a vendor-specific connector |
| Data the vendor holds | None | A copy of your rows |
| Works with the agent closed and the laptop shut | No, but the data is already on disk when you reopen it | No |
| Cost shape | One purchase | Recurring, or metered per request |
How we sourced this. The two figures with evidence ids come from our own published surfaces, read and hashed on 2026-10-11: the zero-dependency server's runtime behaviour (E1, the public repository) and the tool and prompt counts on the MCP page (E2). Everything in the cloud column is the category's general shape, not a number we are asserting about any single product. Check the source before you plan around it.
The 60-second listing check
You do not need to read a spec sheet. Five questions get you to the quadrant.
- Where is the model? Look for "on-device", "on your iPhone", or a named local pipeline. If the only claim is "private", keep reading.
- Is there an MCP server? Search the listing and the site for "MCP". A tool list with names is a bridge. A feature called "AI chat" is not.
- Does the bridge need a desktop app open? If yes, it is local in name only.
- Where does the data go? A file you choose is different from a sync to a vendor account, even when both are encrypted.
- What is the cost shape? One purchase is a different relationship from a recurring meter, because a meter caps how often you may look at your own numbers.
Two of five yes answers put an app in one circle. Four or five put it in the overlap. It is a coarse test on purpose, and it filters the category faster than any comparison table.
How the bridge stays local
The both-at-once version is not complicated. The iOS app reads Apple Health read-only and writes a JSON file to a destination you pick. The MCP server is zero-dependency Node, so it runs with a plain node command and reads that file. It makes zero runtime network calls (E1). Point your agent at it with a config block:
{
"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"
}
}
}
}Quit and relaunch the agent, then ask it to call get_mcp_status. It reports whether the server is up and whether it found your data. From there the agent has 16 read-only tools and 22 prompts (E2) to work with, and every one of them is a read of a file on your own machine. The on-device Ask in the app computes on the phone and shows a provenance card with the samples, the date range and the computation behind each answer. That card is the part a cloud round trip cannot give you, because it can only exist when the numbers were computed rather than requested. The other half of the overlap is the path itself: an iPhone-only route with no Mac companion app to keep open, and the same export can be sent as signed JSON to your own server or to a platform you use, under a published contract.
FAQ
What does agent-connectable actually mean?
It means an outside AI agent can read your health data through a standard interface, usually an MCP server. Claude, Cursor, opencode and ChatGPT desktop can all drive one. Without a bridge, the app's own chat window is the only place your data can be read.
Can an app be on-device and still send my data somewhere?
Yes, if it has a cloud fallback or a hosted connector. The claim to check is where the model runs and whether a copy of your rows reaches a server. On-device is a property of the computation, not a promise about every feature in the app.
Do I need a desktop app running for the MCP server to work?
No, and this is the check most people miss. A local MCP server that only runs inside a desktop companion is not available when that app is closed. MetricBridge writes a JSON file to a folder you choose, and the zero-dependency Node server reads that file directly.
What is a provenance card and why does it matter?
A provenance card shows the samples, the date range and the computation behind an on-device answer. It is the difference between an AI that asserts a number and one that shows you where the number came from, and it is only possible when the numbers are computed rather than guessed.
Is there a recurring plan?
No. MetricBridge is a single $24.99 one-time unlock. It covers the export, the raw MCP server, the on-device Ask and the Weekly Brief. There is no recurring charge.
Doing this yourself? MetricBridge handles the export step: all 190 metrics as local JSON, with the open-source MCP server (GitHub).
Both circles, one purchase.
MetricBridge is a $24.99 one-time unlock. It covers the export, the raw MCP server, and the on-device Ask and Weekly Brief. No account, no recurring plan, nothing of yours on our servers.