The On-Device Health AI Niche Now Has a Dozen Apps. None of Them Ships an Agent Bridge.

On-device answers became table stakes in health AI this year. Agent access did not. Those are two different features, and only one of them is being built.

Last updated 26 October 2026 · 8 min read · Written by the MetricBridge team

AI-assisted, human reviewed. How we use AI

Quick answer

More than a dozen iPhone health apps now answer questions about your Apple Health data on the device itself, with no cloud round trip. As of October 2026, none of them ships an agent bridge: no bundled MCP server, no config block you can paste into Claude Code or Cursor, no connection page naming the agents it supports. On-device is the claim everyone makes. Agent access is the one almost nobody has built, and it is the one that decides whether your health data ever reaches the tools you actually work in.

Two claims, constantly confused

"On-device" describes where an answer is computed. "Agent-connectable" describes where the data can go afterwards. A reader sees one app answering "how is my HRV trending this month" in a chat bubble on the phone and reasonably assumes the same numbers can reach their agent. They cannot, because the second thing is a separate product with a separate data contract, and a much less fun one to build.

Here is the distinction in one sentence: if the app can tell you something but cannot tell your agent anything, you are reading a summary, not a bridge.

What we checked, and how

We opened the App Store listing and the developer's own docs for every on-device health AI app we could find, then searched each for MCP, Model Context Protocol, a config block, or a connection page. The method matters more than the names: check the listing for the word, then check whether a reader could actually paste something and get data back.

Listings change and apps ship. The point is not that any one app is bad: the category converged on the same first half of the product and skipped the second half, and that has held through every sweep we have run this autumn.

Why the second half gets skipped

An agent bridge is not a checkbox. It is a data contract, and the contract is the hard part. A server has to answer: which 194 metrics exist, in what unit, over what range; how fresh the file is; what "HRV" means when the export carries a device-specific spelling. Then it has to expose that as tools an agent can call without inventing numbers.

Our own server ended up with a frozen surface of 16 tools and 22 prompts, and that count is treated as a contract rather than a nice-to-have. The tools are the boring, load-bearing part: get_mcp_status before anything else, get_freshness to prove the data is not stale, list_metrics, get_health_metrics, get_trends, compare_periods, get_workouts, get_sleep_sessions, correlate_metrics, and resolve_metric so an agent that guesses a metric name gets a real answer instead of a plausible one.

There is a business reason too. A bridge makes the app a component. If your agent can pull every number directly, the app's own screen time falls, and screen time is what the charts reward.

The five-minute test you can run yourself

1. Open the app's App Store listing and search the text for MCP, Model Context Protocol and any agent you use.
2. Find the developer's docs. Look for a config block, not a promise. Real config looks like this:

{
  "mcpServers": {
    "health": {
      "command": "npx",
      "args": ["-y", "health-export-mcp"]
    }
  }
}

3. Search the developer's site for a connection page that names the clients it supports. A page that lists Claude Code, Cursor, opencode and the rest is a bridge. A page that says "AI integration coming" is not.
4. Ask one question: could I paste this config and get a real number back, right now, with no hosted account? If not, keep looking.

What "on-device" should still buy you

On-device answers are worth having on their own. The reason is provenance: an answer computed on your phone from your own samples can show which samples, which date range and which computation produced the number, because the raw rows are right there. A good on-device app renders that as a card you can inspect: headline figure, inline chart, a tappable strip naming the samples behind it.

That is the difference between "your HRV is up 6% versus last month" and a number you can trace to 27 nights of readings. One is trivia, one is evidence. Ask the app to show its work. And keep the two privacy questions separate: on-device processing is one property, and where the export path sends your rows is a different one, written in different code.

The bet we made

MetricBridge is an iPhone app that answers questions about your Apple Health data on the device, with a provenance card on every answer, and also feeds a zero-dependency MCP server so the same numbers reach your own agent. One purchase, no account, no server of ours in the path.

If you are choosing an app this month, the honest question is not which one has the best AI. It is which one can still hand your numbers to the tools you will be using in two years, without making you copy a summary into a chat box.

FAQ

MetricBridge describes and computes from your own Apple Health data. It is a wellness tool, not a medical device, and it does not diagnose, treat or monitor any condition. Comparisons are our own reading of public listings and docs as of 26 October 2026. Back to MetricBridge