Apple Health MCP for Claude in 2026: Own-DB Decision Guide
If you searched for apple health mcp, you probably want Claude — Desktop, Claude Code, or Cursor — to query your HealthKit data with real tool calls, not pasted CSV dumps. In 2026 that is a solvable problem, but the stack you pick decides whether the data stays fresh, whether it works off your home Wi‑Fi, and whether you own the database.
This is a decision guide, not a setup dump. For the step-by-step checklist see the Apple Health MCP setup. For a feature matrix see compare. Product and schema notes live under docs.
What “Apple Health MCP” actually means
Apple does not expose a server-side HealthKit API. Samples live on your iPhone. An Apple Health MCP server is the bridge that turns those samples into Model Context Protocol tools so Claude can call things like get_hrv_trend or get_health_summary instead of guessing.
Three architectures dominate searches for apple health mcp server and apple health claude today:
- Same-device / same-Wi‑Fi MCP — an iOS app exposes a local TCP MCP endpoint; your laptop must reach the phone on the LAN (classic Health Auto Export folk stack).
- Export + npx MCP — you manually export Health data (XML/CSV), then wrap the file in an MCP server you often start with
npx(e.g. neiltron/apple-health-mcp-style projects). - Own-DB wedge — HealthKit syncs continuously into a Postgres/Supabase project you control; a local MCP process on your Mac reads that DB for Claude, Claude Code, Cursor, ChatGPT clients that speak MCP, or Ollama.
health4.ai is built for path 3. The rest of this post is about when that is worth it — and when it is not.
Decision criteria that matter
Use these five filters before you install anything:
| Criterion | Why it matters for Claude |
|---|---|
| Freshness | Morning HRV / sleep only help if last night’s samples already landed |
| Remote reach | Claude Code on a laptop away from home Wi‑Fi cannot open a phone TCP port |
| History depth | Multi-year trends need a durable store, not a one-shot export |
| Ownership | Health data in your Postgres vs a vendor cloud vs a flat file on disk |
| Client surface | Claude.ai web connector ≠ Claude Code / Cursor MCP |
If your goal is “chat about health inside Claude.ai on iPhone,” Anthropic’s native connector may be enough — and it is a different product surface than apple health claude code workflows. Developers who live in the terminal almost always need MCP against data they can reach from the machine running the agent.
Also separate ChatGPT Health from MCP. ChatGPT Health is a cloud product surface inside ChatGPT. It is not a drop-in replacement for a local MCP server you point Claude Code or Cursor at. If your workflow is agent tooling, you still need a connector that speaks MCP.
Path A — Health Auto Export folk stack
Health Auto Export is the established consumer export/sync app. Its MCP path typically keeps the tool server near the phone and expects your AI client to connect over the local network.
Choose this when: you mostly query from a Mac that stays on the same Wi‑Fi as your iPhone, you already paid for Premium, and you want a polished App Store product today.
Trade-offs: remote Claude Code sessions break when the phone is unreachable; sync freshness depends on how the app schedules background work; you are not building a personal warehouse you can SQL against for five years of history the way a Postgres schema lets you.
None of that makes HAE “bad.” It optimizes for a different constraint set than agent-first developers. The compare page spells out the same-Wi‑Fi TCP vs BYO-Supabase contrast in more detail.
Path B — Export file + npx MCP (neiltron-style)
Projects like neiltron/apple-health-mcp take Apple’s one-shot export and expose it as MCP — often with a quick npx start. Zero custom iOS app. Great for a weekend experiment.
Choose this when: you want to prove Claude can reason over HealthKit at all, you accept re-exporting when you want newer data, and you do not need continuous observer-based sync.
Trade-offs: the export is a snapshot. There is no HKObserverQuery keeping a database warm overnight. health4.ai deliberately does not ship an npx package yet — install is still clone the repo and run the Python MCP server (see /setup).
Path C — Own Postgres + local MCP (the health4.ai wedge)
Architecture in one line:
HealthKit → your Supabase/Postgres → local MCP → Claude / Cursor / ChatGPT / Ollama
The iOS app registers HealthKit observers, authenticates to your Supabase project, and posts samples through an Edge Function you deploy. The MCP server runs on your machine, reads DATABASE_URL, and registers tools documented on /mcp-tools.
Choose this when:
- You want Claude Code or Cursor agents to work from coffee shops, offices, and remote SSH sessions
- You want SQL, backups, and a schema you can inspect
- You care that health4.ai never hosts your biometrics — the project is yours
Honest constraints (read these before the waitlist):
- The iOS app is invite-only TestFlight — not a public App Store listing yet
- There is no public TestFlight URL; join the waitlist and request a beta invite
- There is no npx one-liner yet — MCP install is clone + Python
- Backend for the iOS app is Supabase you own (Auth + Edge Functions). Plain Neon/local Docker alone cannot receive app writes — details in docs and the Neon clarification post
If the own-DB path is what you want, the companion post Apple Health → Postgres goes deeper on schema, RLS, and why Postgres is the wedge — not just “another sync app.”
How Claude actually uses the tools
Once MCP is connected, apple health claude stops being a metaphor. You ask in plain language; the model selects tools.
Examples:
- “Summarize the last 7 days” →
get_health_summary - “HRV trend vs prior week” →
get_hrv_trend - “Sleep stages last night” →
get_sleep - “Anything odd about yesterday?” →
get_daily_snapshotplus follow-ups
In Claude Code, run /mcp and confirm the health4ai server lists its tools before you trust any answer. Tool cards and parameter notes live on /mcp-tools. The protocol mechanics (stdio, JSON-RPC, tool schemas) are covered in The MCP Protocol Explained for Health Developers.
A useful mental model: MCP tools return structured JSON; Claude’s job is interpretation. That split is why “ask in English” works without teaching every teammate HealthKit type identifiers.
Mapping search intent to a path
| You searched… | Best first move |
|---|---|
| apple health mcp | Read this guide, then /compare |
| apple health mcp server | Own-DB if you need remote agents; HAE if LAN-only is fine |
| apple health claude | Confirm Desktop vs Claude.ai web vs Claude Code |
| apple health claude code | Own-DB or export+npx; native web connector will not help |
If you already read our earlier pillar Apple Health MCP Server: Connecting HealthKit to Claude Code, treat that piece as the architecture deep dive and this one as the 2026 decision tree — same product family, different question.
Recommended default for developers in 2026
For Claude Code / Cursor builders who want continuous sync and ownership: own Supabase + local MCP. Start with the ~15-minute setup, skim compare if you are still weighing HAE vs export+npx, and keep /docs open while you deploy the ingest function.
If you only need a static snapshot this weekend, export+npx is faster and fine. If you live on one home network and already use Health Auto Export’s MCP, stay there until remote reach becomes a pain.
Whatever you pick, skip medical claims and treat AI output as coaching-adjacent analysis over your samples — not diagnosis.
health4ai: Free while in early access. Invite-only TestFlight — not on the public App Store yet.
Join the waitlist →