DEV Community

Philip D'Souza
Philip D'Souza

Posted on

On-device health AI needs an MCP bridge, not a silo

On-device health AI keeps your Apple Health data on your phone. That's the right privacy model. It also locks that data 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 machine, exposes your local health data as live tools any MCP-aware agent can call, and never sends anything to the cloud.

What the bridge looks like

The server is 84 kB, zero dependencies, and makes zero runtime network calls. It reads the on-device iCloud health cache that the iOS app already syncs. Fourteen read-only tools:

  • 8 metric queries (get_health_metrics, list_metrics, get_intraday, etc.)
  • get_workouts, get_sleep_sessions, get_events
  • get_profile, get_cycle_context
  • correlate_metrics (names the segment boundary behind a correlation so it's not a travel-day artifact)

Plus 22 MCP prompts and a --demo mode that serves a synthetic dataset with zero setup.

The setup

One config block. Same server command in Claude Desktop, Claude Code, Cursor, ChatGPT Desktop, Windsurf, Codex CLI, opencode, OpenClaw. Only the config file path changes.

{
  "mcpServers": {
    "metricbridge": {
      "command": "npx",
      "args": ["-y", "health-export-mcp"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Why this matters

Most on-device health apps process locally but give you no way to connect that data to the AI agents you already use. No MCP server, no export pipeline, no bridge. The data stays private, but it also stays locked inside one app's UI.

The trade-off used to be privacy or portability. An on-device app with an MCP bridge gives you both. The data never leaves your phone, and any MCP-aware agent can query it.

Read the full guide

Top comments (0)