The easiest Apple Health MCP setups look the easiest for a reason: they run in someone else's cloud, behind their iPhone app, under your account there. That is not a side detail, it is the product. Here is what a hosted route actually asks of you, and how a server that reads a file you own changes the trade.
Quick answer
A hosted Apple Health MCP server asks for three things a local one does not: the vendor's app installed on your iPhone, an account with that vendor, and a live sync from your phone into their cloud. The app is the connector, so the feed runs only while it is installed and syncing. A folder-based server inverts that. Your phone writes the export to a folder you pick, and the MCP server reads that file. No vendor account, no cloud copy, and no app in the loop when your agent reads.
What "hosted" asks of you
Every hosted health MCP in this category works the same way. HealthAPI runs a remote MCP server and says plainly that behind it is "your own HealthAPI account, which the HealthAPI iPhone app keeps in sync with Apple Health" (their page, updated 20 October 2026). telo's page (reviewed 8 November 2026) walks the same path in three steps: Apple Health on your iPhone, telo keeps the synced history, your assistant. Somvia turns the measurements you choose into "a private remote Apple Health MCP server," sold on the promise of no XML export and no Mac left running, because their server holds the data. Freddy Health bridges Garmin, Oura and Apple Health from a cloud-hosted connector.
Read that list again as a list of dependencies. You install their app. You create their account. Your phone syncs to their servers, continuously, so the copy stays current. Take any one of the three away and the agent stops answering.
That is the second app problem. You already have Apple Health. A hosted route asks you to add another app whose whole job is to be the pipe between your phone and your agent, and to keep it installed and syncing for as long as you want the connection to work.
The honest case for hosted
It is worth saying why hosted wins for some people, because it does. Setup is a paste of one MCP address and an approval on your phone. Freshness is handled for you: their server updates as your phone syncs, so there is no stale-file question to think about. It works with the phone in your pocket and the laptop asleep, because the work happens on their machines. If your priority is zero files and zero local configuration, hosted is the shorter path, and no amount of preference changes that.
The trade is what it costs you, and where the data sits.
What you give up for the paste
Your data leaves the device. For HealthAPI this is explicit: your iPhone syncs to their cloud, and their docs say data is kept for about five weeks. telo keeps the synced history server-side. Somvia holds it on their server by design. That is the whole point of the hosted model, and it is also the whole cost of it.
You rent the connection. HealthAPI is free for two days, then a paid plan with a request quota. telo gives the last seven days free and puts older history behind a paid plan. It is a recurring charge, and the meter is real.
The app has to stay. Because the vendor's app is the sync source, uninstalling it, building a block on its background refresh, or signing out stops the feed. There is no file sitting on your machine for an agent to read once the app is gone.
None of that makes hosted a bad choice. It makes it a specific one: a feature that reaches every country and every plan, at the price of a second app, an account and a bill you keep paying, with your health data on someone else's server in between.
The file model, and who owns the pipe
The other way to connect is not a server in their cloud but a file on your disk. MetricBridge reads Apple Health on the iPhone, read-only, and writes 194 metrics as JSON or CSV to a destination you choose: a local folder, iCloud Drive, your LAN, or a webhook. The open-source health-export-mcp server then runs on your own machine and reads that folder over stdio. It makes zero network calls.
Two of the three hosted dependencies disappear. There is no vendor account, because there is nothing to sign in to: the app has no account at all. And there is no cloud copy, because your health data never reaches us or a cloud AI. What is left is a file that updates on the schedule you set, and a server that reads it.
The app's job changes, too. In a hosted route the app is the connection and has to keep running for it. Here the app is a writer. Once the JSON lands, your agent reads it with the phone in your pocket and the vendor absent from the path. The phone app is still the one thing an agent cannot replace, and that is a platform rule, not a shortcut: only an iOS app can read Apple Health. The real choice is not app or no app. It is whose app, doing what.
The one question that sorts any listing. Does the MCP address point at a domain, or at a folder on your own machine? An address like https://dub.sh/3MWHJXx is hosted: the data lives with them. A stdio command reading HEALTH_DATA_DIR is local: the data is a file you can open, back up and delete.
The honest limits of the file route
A file is a snapshot, not a live socket. Freshness on a folder route is your export schedule. Set the export to automatic and freshness stops being a question; set it to manual and you will notice. The server can tell your agent how old the export is, so a stale read gets flagged rather than trusted.
Hosted really is faster to start. If one pasted address is the entire priority, hosted wins that round by design. It charges for it every month, and keeps a copy.
One app is still required. No route to Apple Health skips the iPhone app. The claim here is not "no app", it is "no second app whose only job is to be somebody's pipe."
The arithmetic, one purchase against a meter
Hosted routes meter the connection. HealthAPI is free for two days and then a recurring paid plan with a request quota; telo is free for the last seven days with older history paid. The file route is one purchase. MetricBridge is a 7-day free trial, then a single $24.99 one-time unlock that covers the export, the MCP tools, on-device Ask with a provenance card on every answer, the Weekly Health Brief, and the Mac and Apple Watch apps. Asking your own agent is unlimited local reads, because there is nothing to meter.
For the standing comparison of routes and what each one sends where, the format guide and the compare page go deeper. For the mechanics of adding a local server to a client, the Claude setup walkthrough has the exact config.
Doing this yourself? MetricBridge writes the export on the phone: all 194 metrics as local JSON, read by the open-source MCP server (GitHub) with 22 tools (20 read-only) and 23 prompts. No account, one purchase.
FAQ
Do hosted Apple Health MCP servers require their own app?
Yes. A hosted route syncs your Apple Health from the vendor's iPhone app into their cloud, and their MCP server serves it from there, behind your account with them. The app is the connector, so it works only while it is installed and syncing. Take the app or the account away and the connection goes with it.
Is a hosted Apple Health MCP server faster to set up?
Usually yes. You paste one MCP address and approve a sign-in, instead of exporting a file and adding a local server. The trade is a recurring charge you rent, a cloud copy of your data, and a dependency on the vendor's app staying installed and current.
Can I use an Apple Health MCP server with no account?
With a folder-based server, yes. The MetricBridge MCP server runs locally over stdio, makes zero network calls, and needs no account or API key; it reads an export file the iPhone wrote. The app itself has no account either, so there is nothing to sign in to on either side.
Does the local route still need an iPhone app?
Yes. Only an iOS app can read Apple Health, so a phone app writes the export in every route. The difference is what the app is for: a writer of a file you own, or a sync client feeding someone else's cloud.
Your health data in your agent, with no second app to keep
Export all 194 metrics on the iPhone, then let Claude, Cursor or any MCP client read them from your own folder. No vendor account, no cloud copy, no recurring meter on the connection.
Start my 7-day free trial
Install the MCP server
Source on GitHub
Where it goes: the app reads Apple Health read-only and writes JSON to a folder you pick. Your health data never reaches us or a cloud AI; the MCP server makes zero network calls. What you get: all 194 metrics, 22 tools (20 read-only) and 23 prompts, on-device Ask with a provenance card on every answer, the Weekly Brief, and the Mac and Apple Watch apps. Price: $24.99 one time after a 7-day free trial, not a subscription. Wellness, not medical advice.
Related reading
→ Claude's Apple Health access is US-only: the connector route that works everywhere
→ Connect Apple Health to Claude via MCP: the exact config
→ Pass-through vs answer-on-device: who computes your health answer
→ Where agents actually find MCP servers, and what directs installs
→ The MCP server: 22 tools (20 read-only), 23 prompts and every client config
→ health-export-mcp: the zero-dependency MCP server on GitHub
Originally published at [healthexport.dev](https://dub.sh/hcRXADn
