Open Health Sync for Apple Health, Read End to End: A Read-Only Token, a Docker Stack, and About Twenty Minutes
Open Health Sync is the closest thing to a like-for-like rival to MetricBridge in the self-hosted camp. It is MIT licensed, it runs on your own computer, and it gives Claude read-only access to your Apple Health data through an MCP server. Its own docs put the setup at about 20 minutes. We read them end to end so you know exactly what the twenty minutes buys.
AI-assisted, human reviewed. How we use AI
Quick answer
Open Health Sync (openhealthsync.com, v0.3.0) is an open-source Apple Health MCP server you run yourself. You load the Health app export into its own PostgreSQL database, mint a read-only token scoped to one person, and add the server to Claude. Their docs say about 20 minutes, and the steps are a Docker Compose stack, an import, a token and a client config. MetricBridge takes the other route: the iPhone app exports 194 metrics as JSON to a folder you pick, and an open-source MCP server reads that folder over stdio after a one-line install.
What Open Health Sync actually is
Their docs are refreshingly plain about the shape: "Open Health Sync holds your data in its own database and serves it through a read-only MCP server." The assistant calls its tools (get_daily, get_sleep, get_workouts, get_samples and others) and works from what they return. Everything runs on your own machine. Latest release as of this read is v0.3.0.
Two lines from their own page deserve to be quoted rather than paraphrased, because they are the honest version of the trade:
Their words: "Know where your data goes: what the assistant reads to answer you is sent to the company that runs the model, like anything you type to it. Your instance and the rest of your data stay on your machine."
That is the correct caveat, and it applies to every route where a cloud model writes the sentence. Your database can be yours and your numbers can still land with the model provider the moment you ask. Hold on to that, because it decides which route is the private one for you.
The four steps, as their docs give them
Step 1 Load your Apple Health data. Start the stack with Docker Compose, create your user with ohs admin personal setup, export from the Health app on the iPhone, then run ohs import apple-health export.zip. You also install the ohs command here, because Claude Desktop starts it later.
Step 2 Mint a read-only token. One command from the repository folder, go run ./recipes/ai-agent, prints something like:
Read only token, valid until 2026-11-17. Keep it private.Under the hood the script reads ~/.ohs.env and calls POST /v1/users/{id}/tokens with the read scope. You can also do it by hand.
Step 3 Add it to your assistant. For Claude Code, their script prints a line you paste:
claude mcp add --transport http open-health-sync http://localhost:8080/mcp \
--header "Authorization: Bearer ohs_ut_..."For Claude Desktop it is a claude_desktop_config.json entry with "command": "ohs", "args": ["mcp"], and OHS_MCP_URL plus OHS_MCP_KEY in the env block. Restart the client.
Step 4 Ask. They suggest opening broad so the assistant learns what you have: "What health data can you see for me? List each kind of data and the dates it covers." Then real questions. One instruction in that step is the most interesting sentence on the page: "Ask it to show its numbers, so you can check them."
That sentence is the whole argument for provenance in one line, and we agree with it hard. The difference is where the burden sits: their route relies on the model complying when you ask for the working, while ours puts the numbers in the answer as a provenance card, so there is nothing to ask for.
Where the twenty minutes actually go
Nothing in that list is difficult, and this is not a knock. But "about 20 minutes" is doing a lot of work in one phrase, so count the moving parts:
- A container stack. Docker Compose, plus PostgreSQL inside it. That is a service on your machine that now needs to be running for the agent to work.
- An import. The Health app export has to get from the iPhone to the computer and into the database. If your history is long, that file is not small.
- A token to renew. The minted token stops working after 30 days. That is good security hygiene and also a recurring chore: when it lapses, the agent goes quiet.
- A database to back up. Your health history now lives in a Postgres instance you own and maintain.
Add it up and you get a route that is genuinely yours, with the maintenance that implies. Some people want exactly that. Others want the agent answering questions tonight.
The token scoping idea is the part worth keeping
The strongest idea on their page is not the database, it is the grant: a token that can only read one person's data. Per their docs it cannot write, delete or connect anything, it sees only your user, and it expires after 30 days. If two people share a machine, that scoping is the thing standing between your agent and someone else's records.
We took the same idea and moved the boundary. Our MCP server reads a folder, so the grant is the file path: point it at your export directory and that is the entire reach of the agent. There is no token to rotate and nothing to expire, and revoking access means moving or deleting the folder, or turning the export off. It is a smaller surface with fewer things to forget. We wrote the longer version of that argument in what a read-only Apple Health token should and should not reach.
The two routes, side by side, honestly
Open Health Sync wins on: MIT licence, source you can read, your own database, no app purchase at all, and no vendor anywhere in the path.
It costs you: about 20 minutes and a stack to keep alive, a token that lapses every 30 days, a database to back up, and the cloud-model caveat above, which no amount of self-hosting removes while a hosted model is writing the answer.
The MetricBridge route is the shorter path to the same job. Install the app, allow Apple Health, ask. The app reads Apple Health read-only and writes 194 metrics as JSON or CSV to a destination you choose (iCloud Drive, a local folder, your LAN, a webhook). Then one line on a Mac:
claude mcp add health-export -- npx -y health-export-mcpThat server is zero-dependency, speaks stdio, ships 22 tools (20 read-only, and the other two only log events to their own file), and makes zero network calls. On the iPhone, Ask answers questions with a provenance card computed on the device, so the numbers in the answer never leave it. One purchase, $24.99, after a 7-day free trial, and it covers the export, the MCP tools, on-device Ask, the Weekly Brief, and the Mac and Apple Watch apps.
Which one to pick. If you want your own Postgres and you enjoy running things, Open Health Sync is a good option and we will not pretend otherwise. If you want an agent reading your real numbers this evening with no container in the way, the app route is shorter and the on-device Ask keeps the question itself local. Both beat pasting a health export into a cloud chat window, which is what most people do today.
Doing this yourself? MetricBridge handles the export step on the iPhone: 194 metrics as local JSON, read by the open-source MCP server (GitHub) in one install line.
FAQ
Is Open Health Sync free?
Open Health Sync is open source under the MIT licence and runs on your own computer, so there is no licence fee. You pay in setup time and in the machine it runs on: a Docker stack, a PostgreSQL database and a token you renew. MetricBridge is a single $24.99 one-time unlock after a 7-day free trial, with no server of ours in the path.
How long does Open Health Sync take to set up?
Its own documentation says about 20 minutes. The work is: start the stack with Docker Compose, create your user, export from the Health app on your iPhone, import the export into its database, mint a read-only token, and add the MCP server to Claude. MetricBridge's own route is the app writing JSON to a folder you pick, then one install line for the MCP server.
What does Open Health Sync's read-only token allow?
Per its documentation, the token is minted with the read scope, cannot write, delete or connect anything, sees only your user, and stops working after 30 days. It is scoped to one person's data, which is the idea worth copying on any health MCP setup.
Does the health data stay on my own computer?
The Open Health Sync instance does, and its own docs say so plainly while adding that what the assistant reads in order to answer is sent to the company that runs the model. MetricBridge splits that differently: on-device Ask computes the answer on the iPhone with a provenance card on every answer, and the export plus the MCP server keep the data path local, with the MCP server making zero network calls.
An agent reading your real numbers tonight, without a container
Export all 194 metrics on the iPhone, then let Claude, Cursor or any MCP client query them locally. One install line, no account in the middle.
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, 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.