DEV Community: Philip D'Souza

Apple Health HRV and Sleep Trends in Your AI Agent: Visualize, Compare, Decide

Philip D'Souza — Thu, 05 Nov 2026 07:50:00 +0000

Apple Health HRV and Sleep Trends in Your AI Agent: Visualize, Compare, Decide

HRV and sleep are the two Apple Health signals worth reading together, and the hardest to eyeball. Here is how to pull both into Claude, Cursor or any MCP client: the tools it calls, the config, and the output you get back.

By MetricBridge · Published 5 November 2026 · ~10 min read

AI-assisted, human reviewed. How we use AI

Quick answer: give your agent read-only tools over your own Apple Health export with the MetricBridge MCP server, then ask a trend question in plain language. The agent calls get_trends, compare_periods or correlate_metrics and returns numbers with the date range they cover. HRV and sleep compare cleanly because both are recorded nightly, so "this week versus last week" is two tool calls and a sentence, not a spreadsheet.

Why HRV and sleep are the pair that matters

Most Apple Health metrics are noise on their own. Steps are cumulative, so a big Tuesday only means you walked. HRV and sleep are different. Both are recorded while you sleep, both move with recovery, and both are read against your own baseline rather than a population average. A single HRV reading of 52 ms says very little. The same 52 ms sitting well below your own recent range is the interesting part.

That is why a trend question beats a snapshot, and why the agent needs your history instead of a pasted number. Seven and a half hours of sleep means one thing after a normal week and something else after four short nights in a row. The comparison is the signal.

What you need before you start

MetricBridge on your iPhone. Grant Apple Health read-only, turn on export, and pick a destination. iCloud Drive is the simplest choice: the OS syncs the folder to your Mac with no extra setup. The app writes all 194 metrics into one local JSON file, including per-night sleep sessions with stages and HRV samples.
Node.js 18 or later on the machine where your agent runs. The MCP server is a single command with no dependencies to install.

Install the server in one line. On a Mac there is no environment variable to set:

claude mcp add health-export -- npx -y health-export-mcp
On Windows or Linux, point it at the export folder with HEALTH_DATA_DIR:

HEALTH_DATA_DIR="/Users/you/export-folder" npx -y health-export-mcp
The server is stdio only, MIT-licensed, and makes zero network calls. It never writes to Apple Health; the only two tools that write anything are add_event and remove_event, and they touch a file beside your export. For the full client-by-client walkthrough, see connecting Apple Health to Claude over MCP.

The tools that answer a trend question

You do not call tools yourself. You ask a question and the agent picks. These are the ones it reaches for on an HRV and sleep task, from the server's 22 tools (20 read-only, plus the two event writers) and 23 prompts:

get_mcp_status: confirms the server is up and the export folder was found
get_freshness: how current the export is, and whether it has gone stale
list_metrics: which of the 194 metrics are present in your file
get_health_metrics: raw values for one metric over a date range
get_trends: week-over-week and month-over-month math for a metric
compare_periods: A against B, for example this week against last
correlate_metrics: the relationship between two metrics over the same window, such as HRV and sleep duration
get_sleep_sessions: per-night sessions with stages and naps, not just a nightly total
get_intraday: within-day samples when you want the shape of a night
resolve_metric: the canonical name and unit for whatever you called it

Spelling is not a problem. Say "resting heart rate", "RHR" or "resting_hr" and resolve_metric maps it to the same canonical metric with the right unit. You never have to memorise our names.

A worked example: HRV against sleep, week over week

Once the server is connected you just ask. A representative run looks like this, with the tool calls and the reply:

`You: Compare my HRV and my sleep this week to last week.
Is there a pattern?

Agent: [get_freshness] data through 2026-11-04
[resolve_metric] "HRV" -> hrv (ms)
[compare_periods] hrv: last 7d vs prior 7d
[compare_periods] sleep: last 7d vs prior 7d
[correlate_metrics] hrv vs sleep_duration, 14d

HRV averaged 54.8 ms this week, up 6.1% from 51.6 ms last week.
Both figures sit inside your recent range, so this is a normal
week-to-week move for you, not a deviation from your baseline.
Sleep averaged 7h 22m, up 19 minutes. On the nights you slept
more than 7h 30m, your next-night HRV ran above your 14-day
average. Across the 14 days, longer sleep and higher next-night
HRV move together (r = 0.41). That is an association in your
own data, not a cause.`
Three things to notice. The agent checked freshness first, so you can trust the window it used. It reported the change and, crucially, whether that change is a deviation from your own baseline. And it labelled the correlation as an association, not a cause.

That last line is the honest reading of two metrics that move together over 14 days. A correlation between sleep and next-night HRV is the kind of thing a wellness tool should describe and a medical tool should not diagnose. MetricBridge is the first kind, and every number here is general-wellness information, not medical advice. The app publishes how it computes baselines in the methods.

How to visualise it, not just read it

A terminal agent will happily give you numbers and an ASCII sparkline if you ask for one. For a real chart, the reliable route is to have the agent hand the series to whatever draws on your machine:

`You: Export hrv and sleep_duration, daily, for the last 30 days
as a CSV I can plot.

Agent: [get_health_metrics] hrv, 2026-10-06..2026-11-04
[get_health_metrics] sleep_duration, same window
[writes hrv-sleep-30d.csv] 30 rows: date,hrv_ms,sleep_h`
Because the data is a local file, anything on your computer can read it: a notebook, a spreadsheet, gnuplot, or the Mac app if you would rather see the same export drawn for you.

If you would rather ask on the phone than on a laptop, the same HRV and sleep questions are answered by the on-device Ask in the app, each with a provenance card that shows the samples, the date range and the computation behind the number. See where your data goes when you ask in the app.

Frequently asked

Does the agent need my whole Apple Health history?

No. Your agent queries a date range at a time, and a 30-day window is one tool call. Backfilling to your first Apple Watch matters mainly when you want a personal baseline older than the last few weeks.

Can two agents read the same export at once?

Yes. The server reads your folder and does not write to your data, so Claude, Cursor and anything else can each run their own copy against the same file. Only the two event tools write, and they write to their own file.

What if the numbers look stale?

Ask the agent to call get_freshness. It reports when the export was last written. If it lags, check that background export is on in the app and that iCloud Drive or your synced folder has finished uploading.

Is a correlation between sleep and HRV medical advice?

No. The agent reports associations in your own data and flags each change against your personal baseline. It does not diagnose, treat or monitor anything. Wellness information only.

Ask your own sleep and HRV questions

194 metrics as local JSON, a zero-dependency MCP server, and on-device answers that show their working.

Start my 7-day free trial (https://apps.apple.com/app/apple-store/id6784185201?pt=129083290&ct=blog&mt=8&ppid=221531d9-aa54-41ed-ad67-6128263b81f2)
Install the MCP server

Where it goes: the app reads Apple Health read-only and writes JSON to a folder you pick. Nothing reaches us or a cloud AI. Price: $24.99 one time after a 7-day free trial, not a subscription.

The self-hosted Apple Health receiver pattern and its quiet failure mode

Philip D'Souza — Mon, 02 Nov 2026 07:47:28 +0000

Point your Apple Health export at an endpoint you run. You get the full body, the headers and the retry rules, and you own the pipeline. The catch is that nobody else is watching it, and a self-hosted receiver does not fail loudly. It just stops having anything new to say.

The pattern

The phone reads Apple Health, builds a JSON document, and POSTs it to a URL you set in the app. No account, no cloud relay, no vendor server in the path. The document kind travels in a header (X-MetricBridge-Type), not the path, so one handler accepts nightly metrics, hourly vitals, workouts, sleep sessions, a time zone log and your events timeline.

The contract you have to honour

Every request carries X-MetricBridge-Type, X-MetricBridge-Schema (currently 1), webhook-id (your idempotency key), and webhook-timestamp. With an ingest token set, webhook-signature follows Standard Webhooks v1: HMAC-SHA256 over {webhook-id}.{webhook-timestamp}.{raw body}, base64 with a v1, prefix. Sign the raw body before your JSON parser touches it, verify before you store, and reject anything more than five minutes off.

The storage rules decide whether your history is right

The app is deliberately chatty: each scheduled run re-sends today and the two days before it, so the same data point arrives more than once by design.

Upsert metrics on name plus date. Workouts upsert on workout id. Append-only tables double count every run.
Sleep sessions are not upserts. Delete what you hold for the covered days, then insert. Sessions split and merge when a source syncs late, so an upsert by id keeps stale rows.
The time zone log and events replace the whole document.
Skip a webhook-id you have already processed, and accept a type you do not know.

The quiet failure mode

Six things go wrong and none of them crash. Inserting instead of upserting. Upserting sleep sessions by id. Ignoring the type header, so typed documents arrive as empty metric updates. A 2xx that returns an HTML login page, which is a failure, and so is any 3xx, because redirects are never followed. Dropping the replay value on a resend. And no monitor at all: the receiver answers 200 and writes nothing, and the only signal is the absence of new rows.

The sixth one costs a month. Add one check that reads your store and asks a single question: when did I last successfully write a document of each type I care about?

The webhook is the push half of the export surface. The zero-dependency MCP server is the pull half: same data, two directions, no vendor in either path.

Full write-up, with the reference receiver and a Python signature-verification snippet: https://dub.sh/lhHWHNv

Pass-Through vs Answer-On-Device: Who Computes Your Health Answer

Philip D'Souza — Sun, 01 Nov 2026 09:14:00 +0000

Pass-Through vs Answer-On-Device: Who Computes Your Health Answer

Two designs showed up in health AI in 2026, and they disagree on one thing: where the computation happens.

A pass-through tool moves your data and stops. Your agent gets the samples and does the reading, so the model's arithmetic becomes the product. You audit it by asking again and hoping for the same number.

An answer-on-device app computes the number on the phone first. A model only words the result, and every answer carries a provenance card naming the samples, the date range and the computation behind it.

Why it matters

It is invisible in a demo. It shows up on the third question, when a trend flips sign between two identical prompts. A pass-through pipe has no artefact to inspect, so you cannot separate a data problem from a reasoning problem after the fact.

The design is not either/or

Answer-on-device is the pipe plus a checked answer. MetricBridge exports all 194 metrics as local JSON and CSV, and the open-source MCP server exposes them to any MCP-aware agent as 18 tools (16 read-only, plus add_event and remove_event, which write only an events file beside the export) and 22 prompts. Nothing writes to Apple Health.

So you get a computed answer you can audit in the app, and raw data your own agent can query over MCP.

How to choose

Pick pass-through if you trust your agent and only want a pipe. Pick answer-on-device if you want the number to be right before the model touches it. Pick both if you can, because the interesting questions are the ones where a checked answer and an open agent disagree.

Full post, with the provenance card example and the method behind every computed number: https://www.healthexport.dev/blog/pass-through-vs-answer-on-device?utm_source=devto&utm_campaign=exp-hea525-20261101

Both Apple Health exporters ship an MCP server now. Where it runs is the whole decision.

Philip D'Souza — Thu, 29 Oct 2026 03:28:00 +0000

Both Apple Health exporters now ship an MCP server. That was the easy half of the problem.

The half that decides your setup is transport. Health Auto Export runs its MCP server on the iPhone, reachable at http://{LAN_IP}:9000/mcp over your local network, with Premium access as a prerequisite and Node 18+ on the client machine. That is a clean design when your agent lives on the same Wi-Fi as your phone.

MetricBridge ships its MCP server as a file you run on your computer. It reads the export you sync to iCloud Drive, a local folder, your LAN or a webhook. The server has zero runtime dependencies, makes no network calls, and exposes 16 read-only tools, two event tools and 22 prompts. Your agent can run on a laptop, a home server, a container or a hosted runner, and the phone can be in another room.

So the question moved. It is no longer "does this app have an MCP server" but "where does it run, and what has to be switched on for my agent to reach it". If your agent and your phone share a network, the on-phone server is the shortest path. If your agent runs anywhere else, the export-file server is the one that survives the phone being put down.

The full comparison, including destinations and formats, is here: https://www.healthexport.dev/blog/health-auto-export-vs-metricbridge?utm_source=devto&utm_medium=social&utm_campaign=agentic_upgrade&utm_content=health-auto-export-vs-metricbridge

A read-only Apple Health token is a scope, not a label

Philip D'Souza — Wed, 28 Oct 2026 09:10:01 +0000

Read-only is a claim. Scope is the proof.

In a health-data agent setup there are two credentials people both call "the token", and they fail in different ways.

The pairing secret gates the server. Turn on Agent pairing in the app and set PAIRING_SECRET in the server config. Without a match, every data tool answers "Locked" rather than returning an empty result. That distinction is deliberate: an empty result reads as "no data today", while "Locked" tells you the credential is the problem.

The delivery token authenticates the export. Point the app at a webhook you run and the request carries your ingest token and, when you set one, an HMAC-SHA256 signature over the request id, timestamp and raw body. Each destination keeps a send history, so you can see what actually left the phone.

The part almost everyone gets wrong: pairing protects the server, not the files. Anyone who can open your export folder reads the JSON directly, with no token and no server. If that folder syncs to a shared drive, your token is decoration.

A read-only Apple Health token should reach one destination, one data folder, and a set of tools that can only read. It should return daily summaries, not individual raw samples, and be revocable in one step. It should never reach the write path back into Apple Health, workout GPS routes, medication records, a network, or anyone else's data.

The full scope test, including what to check and what to revoke, is here: https://www.healthexport.dev/blog/mcp-token-scoping-read-only-apple-health?utm_source=devto&utm_medium=social&utm_campaign=hea448-token-scoping

Metrya vs MetricBridge: a recovery score or a data bridge?

Philip D'Souza — Tue, 27 Oct 2026 09:06:03 +0000

Most Apple Health apps answer the same question the same way: they take your data and return a verdict. Metrya returns a recovery score from 0 to 100, plus a reserve battery and a sleep debt number. That is a real product with a real use.

MetricBridge answers a different question. It does not produce a score. You ask something like "how has my HRV trended this month?" and [the answer opens to the days behind it](https://dub.sh/Nny26eT the metric, the date range, the sample count, and each reading. The point is not the number. The point is being able to check it.

Then there is the direction the data flows. Metrya keeps your export inside its app as CSV, JSON or Markdown. MetricBridge exports 194 metrics as JSON on a schedule to iCloud Drive, a folder, your network or a webhook, and ships a local MCP server with 16 read-only tools. Claude, Cursor, ChatGPT or your own script can query the same data with zero network calls from the server.

Pricing differs in kind. Metrya is a free download with a Pro in-app purchase from $1.99 weekly up to $19.99 lifetime, [as listed on its App Store page](https://dub.sh/WOhvwUs MetricBridge is a free trial then $24.99 once, with no subscription ([pricing](https://dub.sh/Kav5set

Which one you want depends on whether you want to be told how you are doing or whether you want to inspect the inputs. One asks for trust. The other asks to be checked.

The full comparison, including the AI options and report types, is at https://dub.sh/aWBbwPL

The on-device health AI niche has a dozen apps. None ships an agent bridge.

Philip D'Souza — Mon, 26 Oct 2026 07:44:01 +0000

A dozen-plus iPhone health apps now answer questions about your Apple Health data on the device, 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 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. If the app can tell you something but cannot tell your agent anything, you are reading a summary, not a bridge.

Why the second half gets skipped

An agent bridge is a data contract, and the contract is the hard part. A server has to answer which metrics exist, in what unit, over what range; how fresh the file is; and what HRV means when the export carries a device-specific spelling. There is a business reason too: a bridge makes the app a component, and screen time is what the charts reward.

The five-minute test

Open the app's App Store listing and search the text for MCP, Model Context Protocol, and any agent you use.
Find the developer's docs and look for a config block, not a promise:

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

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

The tell: a bridge always documents its tool names. If the docs never name a tool, the agent was never the customer.

What we built

MetricBridge answers on-device with a provenance card on every answer, and also feeds a zero-dependency MCP server so the same numbers reach your own agent. The server ended up as 16 tools and 22 prompts, including get_mcp_status, get_freshness, list_metrics, get_health_metrics, get_trends, compare_periods, get_workouts, get_sleep_sessions, correlate_metrics and resolve_metric. One $24.99 unlock, no account, no subscription, and no server of ours in the path.

Full post, including the app sweep and the method: https://dub.sh/kthXU3E

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.

Export Apple Health to JSON in 2026: Where Each Route Sends Your File

Philip D'Souza — Sun, 25 Oct 2026 07:00:54 +0000

Three routes get your Apple Health data into JSON today. All three hand you a file. Only two keep the raw export on hardware you own, and that difference outlasts any argument about JSON shape.

The question the converter pages skip

Search how to turn Apple Health into JSON and you get a wall of browser tools that promise the same thing in the same words. Every one of them answers "can I get JSON". None answers the question that actually decides which tool you should use: where does my file go.

Route 1: the browser converter

Where your file goes: to their server, then back to you as JSON.

It is the fastest route and it needs nothing installed. Drop the archive in, get a file out. For a one-time look at a single metric it is fine. The limits show up later. You re-export and re-upload every time you want current numbers, and the upload step is permanent by design, because that is how the tool is built.

Route 2: the free built-in route, converted on your own Mac

Where your file goes: nowhere. It stays on your phone, then on your Mac.

Open the Health app on your iPhone, tap your profile picture, choose Export All Health Data, and save the export.zip it produces. AirDrop it to a Mac and unzip it. Inside you get export.xml plus folders for electrocardiograms and workout route files.

Convert it locally with the Python standard library:

import json, collections
import xml.etree.ElementTree as ET

root = ET.parse('apple_health_export/export.xml').getroot()
by_type = collections.defaultdict(list)
for rec in root.iter('Record'):
    by_type[rec.get('type')].append({
        "start": rec.get('startDate'),
        "end": rec.get('endDate'),
        "value": rec.get('value'),
        "unit": rec.get('unit'),
    })

with open('health.json', 'w') as fh:
    json.dump(by_type, fh, indent=2)

That prints a count per metric type and writes health.json. If your history is big, swap ET.parse for ET.iterparse and clear each element after you read it, otherwise you hold the whole document in memory at once.

The honest downsides: it is manual, it is a snapshot the moment it lands, and it will be stale by next week. For a single archive you want to keep, it is the right answer and it costs nothing.

Route 3: an on-device app that writes the JSON itself

Where your file goes: the destination you choose, and nothing else.

You connect Apple Health read-only, and the app writes 190 Apple Health and Apple Watch metrics as clean local JSON to iCloud Drive, a synced folder, your local network or a webhook. No account, nothing on a server. The same data answers questions on the phone itself, computed on device, with a card underneath showing the exact samples behind the number.

Where this route earns its keep is recurrence. An agent does not want a file you exported in June. The open-source MCP server is zero-dependency Node with 16 read-only tools, and it reads the same local folder the app writes to, so the data an agent sees is the data that just synced.

The routing table

Route	Where the file goes	Freshness	Setup
Browser converter	Uploaded to their server	Re-export and re-upload each time	None
Health app export, converted on your Mac	Stays on your devices	Re-export each time	Python, one script
On-device app export	The destination you pick	Continuous	App plus a read-only connection

Four questions before you upload a full health history anywhere

Any converter that parses on its own server should answer these in writing first:

Is the uploaded file deleted immediately, and is that deletion verifiable?
Does the file touch backups, logs or a CDN on the way through?
Is the transfer encrypted in transit, and is the result encrypted at rest?
Does the page sell, share or train on anything derived from your upload?

If a page cannot answer those four, treat it as a one-off convenience for data you would not mind losing, not as the way you move your health history around.

The full write-up, with the routing table and the local recipe in one place, is on the site: https://dub.sh/htX0Cgl

Let Your AI Agent Read Your Apple Health, Privately

Philip D'Souza — Sat, 24 Oct 2026 08:06:51 +0000

Most health AI apps upload your Apple Health export to a server, then hand you a chat box. MetricBridge keeps the export on your machine and exposes 190 metrics through one local MCP server, so Claude, ChatGPT or Cursor read the data in place. No account, no cloud copy.

Full post: https://www.healthexport.dev/blog/let-your-ai-agent-read-your-apple-health-privately

MetricBridge is the iPhone app behind this post. It reads your Apple Health on the device and answers there, so your data stays with you and your own agent instead of a cloud service. One-time unlock, no subscription. Get it: https://apps.apple.com/app/apple-store/id6784185201?pt=129083290&ct=blog&mt=8&ppid=2ce9bdfc-85e0-4c45-948b-81ad213405a3

Semantic Search MCP Servers for Apple Health: What Retrieval Adds

Philip D'Souza — Thu, 22 Oct 2026 06:45:44 +0000

Does semantic search actually help with your Apple Health data? It earns its keep for one kind of question, and quietly fails the one you probably care about most.

A new class of Apple Health MCP server does not only read your export. It chunks your records, embeds them into a vector store, and answers by similarity. That is the same RAG pattern people use for documentation. Health data makes it harder, because most of the payload is numeric time series rather than prose.

What retrieval actually buys you

Semantic retrieval works when you ask about text you wrote (notes, symptoms, journal entries) or about a metric whose exact name you forgot. Instead of exposing only a query_health_data tool, these servers retrieve by meaning, so a fuzzy question can surface the right rows.

It adds almost nothing to "what was my average HRV last week". That answer is arithmetic on exact samples, not the nearest vector. Similarity is not arithmetic: "resting heart rate 61" and "resting heart rate 610" can sit close together in embedding space.

Three real projects doing it now

The pattern is already public:

Barbaroso/apple-health-semantic-mcp reads export.zip into DuckDB and adds a "clinical semantic layer". Its stated reason is the interesting part: Apple Health is full of traps that produce confidently wrong answers, like percentages stored as fractions, sleep that changes date at midnight, and three apps recording the same metric.
Svetafo/health-agent is a self-hosted agent that stores health history in pgvector and runs in Telegram. It is built around remembering what matters across months.
Community RAG tutorials, like the DuckDB plus Pinecone walkthrough on DEV, wire LangChain to an Apple Health export and vectorize it. Useful as a pattern, but it is explicitly a build-it-yourself pipeline.

Notice what each one had to add: a database (DuckDB or Postgres), an embedding step, and a vector index.

What the second pipeline costs

Retrieval is not free. You add ingest, an embedding model, and a vector store, and you rebuild the index every time your export refreshes. Most of these pipelines call a cloud embedding model, which puts health data on someone else's server.

The zero-dependency counter-position

A read-only server that just reads a JSON file is a different shape. Ours ships 16 tools and 22 prompts, makes zero runtime network calls, and answers on-device with provenance cards that show the exact numbers used. No vector store, because the numbers never needed one.

Retrieval is a great tool for text. For the arithmetic, compute it.

Wellness, not medical.

Read the full post at https://dub.sh/vogHdf5

A 1.0k-vote MCP request, still under review: the agent gap in cloud health coaches

Philip D'Souza — Wed, 21 Oct 2026 08:13:00 +0000

You can learn more about a health app from its feedback board than from its feature page. The feature page tells you what the team built. The board tells you what the people paying for it cannot do.

Bevel's public feedback board carries a feature request titled Claude connector / MCP, opened on 22 February 2026. When I read it on 21 October 2026 it showed 1.0k votes and was still marked under review. Four separate threads had been merged into it, including Export API, AI, and Official ChatGPT Integration / MCP Connector.

What the thread actually says

The opening post is the shortest and clearest:

Connect so I don't need to copy paste across both to speak with each other.

Nine months later the comments are still arriving. The most useful one is about architecture rather than features:

MCP is the number 1 feature I'm now looking forward to. Bevel is actually becoming the main agent about health and fitness, but I need my other agents, which are built around me, to talk to Bevel and plan accordingly. Otherwise it's just a broken stack, if I have to tell one story twice.

And a shorter one:

I would like to connect data to my own AI but I can't get access.

A vote is demand, not a delivery date

"Under review" is honest product language. It means the team has read the request and has not committed to building it. A connector is real work, and a vendor with a cloud coach has a data path to redesign before it can hand a third-party agent read access.

But if you are choosing an app this month because you want your own agent on your health data, a highly voted request is not a feature. It is a queue position.

Why this ask keeps showing up

Nobody in those threads is asking for another in-app report. They are asking to stop maintaining two versions of their own story: one inside the health app's coach, one inside the agent they already use for everything else.

That problem is structural, not a missing toggle. A cloud coach is built so the vendor's model reads your data and answers inside the vendor's product. An agent bridge is built so your model reads your data and answers wherever you already are. Only one of those makes the health app replaceable.

The path that does not wait

Export your Apple Health data to JSON on your phone, keep the file local, and run an MCP server against it. Your agent calls read-only tools and gets real numbers instead of a summary someone else wrote.

{
  "mcpServers": {
    "health-export": {
      "command": "node",
      "args": ["/Users/you/.health-export-mcp/server.mjs"],
      "env": {
        "HEALTH_DATA_DIR": "/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents"
      }
    }
  }
}

Then ask your agent to call get_mcp_status to confirm it can see the export, and follow with something like "which nights did my sleep stages shift this month". You get an answer built on your own baseline, from your own model. Nothing in it is a diagnosis, just a deviation from your personal baseline.

Good product, different layer

This is not an argument that Bevel is bad. A long capability list and a public feedback board where the team merges duplicates are both signs of a company that listens. The argument is narrower: the most complete cloud coach in the category has a 1.0k-vote open request for exactly the interface a local bridge gives you on day one.

MetricBridge handles the export step: all 190 metrics as local JSON, plus the open-source MCP server with 16 read-only tools.

Read the full write-up with the source thread and the four buying questions: Bevel's Users Filed an MCP Request.

Apple Health API pricing in 2026: the cloud tiers vs the phone

Philip D'Souza — Tue, 20 Oct 2026 08:11:17 +0000

HealthKit is free. It ships with iOS, it reads the phone's health store, and Apple charges nothing for it. So the $299 to $499 a month that cloud health-data APIs publish is not paying for Apple Health data. It is paying for someone else's pipe, storage, and per-user metering on data the phone already holds.

I read the vendor pricing pages and wrote up the arithmetic. Three things stood out.

1. The entry tier is not the price. Published entry tiers are the floor. The per-user caps and overage meters are where a small product's bill actually lands, and they scale with the thing you most want to grow.

2. The seat matters more than the rate. A cloud API puts a processor between the phone and your server. Every read crosses a meter. The same read, done on-device, crosses nothing.

3. On-device is not anti-cloud. For some products a cloud pipeline is still the right call: multi-tenant analytics, web dashboards, batch ML. The question is whether your core loop needs a server in the path at all.

The full breakdown, with the vendor tiers quoted and the cases where cloud still wins, is here: https://www.healthexport.dev/blog/apple-health-api-pricing

I maintain MetricBridge, an open-source MCP server that reads 190 Apple Health metrics locally and hands them to any agent, so I have a stake in this. The arithmetic stands on its own though. Read the pricing pages.

DEV Community: Philip D'Souza

Apple Health HRV and Sleep Trends in Your AI Agent: Visualize, Compare, Decide

Apple Health HRV and Sleep Trends in Your AI Agent: Visualize, Compare, Decide

Why HRV and sleep are the pair that matters

What you need before you start

The tools that answer a trend question

A worked example: HRV against sleep, week over week

How to visualise it, not just read it

Frequently asked

Does the agent need my whole Apple Health history?

Can two agents read the same export at once?

What if the numbers look stale?

Is a correlation between sleep and HRV medical advice?

Ask your own sleep and HRV questions

Related reading

The self-hosted Apple Health receiver pattern and its quiet failure mode

The pattern

The contract you have to honour

The storage rules decide whether your history is right

The quiet failure mode

Pass-Through vs Answer-On-Device: Who Computes Your Health Answer

Why it matters

The design is not either/or

How to choose

Both Apple Health exporters ship an MCP server now. Where it runs is the whole decision.

A read-only Apple Health token is a scope, not a label

Metrya vs MetricBridge: a recovery score or a data bridge?

The on-device health AI niche has a dozen apps. None ships an agent bridge.

Two claims, constantly confused

Why the second half gets skipped

The five-minute test

What we built

Export Apple Health to JSON in 2026: Where Each Route Sends Your File

The question the converter pages skip

Route 1: the browser converter

Route 2: the free built-in route, converted on your own Mac

Route 3: an on-device app that writes the JSON itself

The routing table

Four questions before you upload a full health history anywhere

Let Your AI Agent Read Your Apple Health, Privately

Semantic Search MCP Servers for Apple Health: What Retrieval Adds

What retrieval actually buys you

Three real projects doing it now

What the second pipeline costs

The zero-dependency counter-position

A 1.0k-vote MCP request, still under review: the agent gap in cloud health coaches

What the thread actually says

A vote is demand, not a delivery date

Why this ask keeps showing up

The path that does not wait

Good product, different layer

Apple Health API pricing in 2026: the cloud tiers vs the phone