Apple Health MCP Server: Connect Apple Watch to Claude

You ask Claude about your run and it has never seen the run

You finish a 16 kilometre long run that fell apart in the last four. You open Claude, type out what happened from memory, and get back a fluent, sensible answer about a run it has never seen.

It does not know your cadence dropped from 178 to 169 over the final 20 minutes. It does not know your ground contact time crept up 14 milliseconds across the same stretch. It does not know you slept 5 hours 50 the night before, or that your resting heart rate has been three beats above baseline since Tuesday. All of that is sitting in Apple Health right now, recorded, timestamped and completely inaccessible to the thing you are asking.

The model is not the weak link. It is genuinely good at this kind of reasoning. It is blind, and you cannot type your way out of blindness, because the data that would make the answer good is a hundred workouts, six months of nights, and a per-second trace of the run in question. Nobody is pasting that into a chat window.

An MCP server fixes it at the root. Instead of you describing the run, the model fetches it.

What MCP actually is

The Model Context Protocol is an open standard for letting AI assistants call external tools. Anthropic published it in late 2024 and it has since been adopted well past Claude: ChatGPT, Cursor and Perplexity all speak it.

The protocol is boring in the good way. A server advertises a list of tools, each with a name and a schema. The model decides when to call one. Results come back as structured data it can reason over.

For training data, that shape is exactly right. You do not want six months of workouts frozen into a context window, going stale the moment you finish tomorrow's session. You want the model to go and look when a question needs an answer, the same way you would open the Fitness app and scroll to a specific week.

So "Apple Health MCP server" means a server that exposes your Apple Health history as tools. Ask "did my cadence hold through the last 5k, or did I fall apart?" and the model pulls the trace for that run and reads it.

Why Apple Health is the odd one out

Every other integration on the platform is a web connection. Garmin, WHOOP, Oura, Withings and the rest all publish server-side APIs, so you click Connect, approve an OAuth screen, and a server somewhere starts pulling your data. You never touch your phone.

Apple does not do that. There is no server-side API for HealthKit and there never has been. Your health data lives on your device, encrypted, and Apple's position is that it stays there unless something running on the device itself hands it over. That is a defensible privacy stance and it is also a hard architectural constraint: no amount of OAuth cleverness gets a server into HealthKit.

So the Apple Health connection starts on the phone. There is an athletedata iOS app, built in Expo, whose whole job is to read HealthKit samples and post them to the backend. Once they are up, they behave exactly like every other source: the same analytics, the same dashboard, the same MCP tools. The difference is only in how they arrive.

The practical consequence is a two-step signup. You create your account on the web, link it, and then get an invite to the iOS app, which is currently in beta through TestFlight. Inside the app you grant Health access, and the first sync pulls your history. From then on it runs in the background.

The second consequence is worth internalising before you start asking questions: data lands when the phone syncs, not the instant your watch records it. Apple Watch also finalizes sleep stages hours after you wake, so an early-morning question about last night is sometimes a question about data that does not exist yet. For a conversation at lunchtime this never matters. At 5:40am it occasionally does.

The upside of the arrangement is large and easy to miss. Apple Health is a hub, not a watch feed. Anything that writes to it flows through the same single connection: MyFitnessPal, Peloton, Nike Run Club, a smart scale, a sleep app. One grant covers a stack of apps you would otherwise wire up one at a time, which is a real advantage over connecting five services individually. The broader case for consolidating sources lives in the data-driven athlete guide.

What the connector exposes

With Apple Health connected, the MCP server registers eight Apple-specific tools.

Workouts. apple_health_get_workouts returns activity type, duration, distance, average and max heart rate, and energy. It also carries laps, which are the watch's own work and recovery boundaries, so a 4x1km session behind a warmup reads as four reps rather than one blurred average. Runs from recent app builds additionally carry splits, the per-kilometre breakdown with distance, duration, pace and average heart rate, and run dynamics: cadence in steps per minute, ground contact time, stride length, vertical oscillation and running power.

The run trace. apple_health_get_run_stream is the one worth knowing about, and it gets its own section below.

Recovery. apple_health_get_sleep returns each night with both time in bed and actual time asleep, which are typically one to two hours apart and routinely conflated. apple_health_get_hrv returns HRV in milliseconds, with a daily aggregate mode because Apple Watch writes many samples a day and a raw pull only reaches back a few weeks. apple_health_get_resting_hr covers resting heart rate on the same pattern.

Body and fitness. apple_health_get_body_composition returns weight and body fat samples. apple_health_get_vo2max returns Apple's cardio fitness estimates in millilitres per kilogram per minute.

Your calendar. apple_calendar_get_events is the quiet one. The same iOS app reads EventKit and syncs a rolling two-week forward window, so the model can see that Thursday has a 6pm flight in it before it suggests a Thursday evening session. Training plans fail on logistics more often than on physiology.

On top of those, every connected athlete gets the provider-agnostic tools: activity detail with heart rate zone breakdowns, daily metrics, the training plan, and power and pace curves showing your best efforts by duration. Those are the ones that change the conversation most, because they answer questions the Fitness app has no screen for.

The sub-kilometre trace is the interesting part

Most integrations stop at the session summary. apple_health_get_run_stream does not.

Give it a run, by date or by workout id, and it returns the downsampled trace of that run on one shared time grid of roughly 10 to 25 seconds per bucket: heart rate, cadence, pace, ground contact time, stride length, vertical oscillation and running power, as parallel arrays you read by index.

That is the resolution at which form questions become answerable. "Did my cadence drop in the last 5k" is not a question you can settle from an average, because the average is the answer you are trying to decompose. Neither is "when did ground contact start creeping up", or "did power hold through the reps or did I fade on rep four". Those need the shape of the run, not its summary.

There is a detail in the data worth respecting. A null inside one of those arrays means that bucket had no sample, a walk break or a signal gap. It is not a zero, and averaging over it as if it were quietly manufactures a slower rep. A whole stream missing from the response means the watch never wrote that metric for that run, which is a different statement again.

This is where the connector stops being a convenience and starts being something you cannot get elsewhere. Apple's own Fitness app will show you a cadence average. It will not compare the first half of your run to the second half and tell you the drift started at minute 48, five minutes before the pace showed anything.

Setting it up

About five minutes, and most of it is the app install.

1. Create an account and link it. Sign up at athletedata.health and connect Apple Health from the integrations page. You will get an invite to the iOS app.

2. Install the app and grant Health access. iOS will show you the permission sheet. Grant the read scopes it asks for. Each HealthKit type needs its own permission, and a missing one fails silently rather than erroring, so approve the full set rather than picking through them. If you later want to change your mind, it is in iOS Settings under Privacy and Health.

3. Let the first sync run. It pulls whatever history HealthKit holds, which for a long-time Apple Watch owner can be years. Leave the app open on a charger the first time.

4. Add the connector to your AI client. In ChatGPT, add a custom connector with the server URL https://mcp.athletedata.health/mcp and choose OAuth, then sign in to athletedata and approve. In clients without an OAuth option you paste a keyed URL copied from your dashboard instead. There is nothing to install locally and no server process to keep alive. The full picture of what the server exposes is on the MCP page, and step-by-step pages for each client live at /mcp/setup/claude-desktop and /mcp/setup/chatgpt.

5. Check your client's plan. This is the step people lose an afternoon to. Claude works on every tier, including Free: custom connectors are available to Free, Pro, Max, Team and Enterprise accounts, and a Free account can add one custom connector, which is all this needs. ChatGPT needs a paid plan, because adding a custom MCP plugin requires Developer mode, available on Plus, Pro, Business, Enterprise and Education accounts on chatgpt.com in a browser. The iPhone and Android ChatGPT apps have no Developer mode toggle at all. Plus is enough, and you do not need Pro. Cursor needs a paid plan, Pro or Business, because MCP is not part of its free Hobby tier.

6. In ChatGPT, mention it first. A custom plugin is not automatically attached to a new conversation. Start your first message with @athletedata so it attaches. Skip this and a perfectly connected plugin will tell you it cannot access the tool, which looks exactly like a broken setup and is not one.

7. Ask something you have never typed. "What was my longest run in the last 90 days, and how did its per-kilometre splits compare to the one before it?" If the numbers are right, the pipe is good. If you get a paragraph about how to think about long runs, it is not.

You can revoke a connected app at any time from your athletedata settings, and it loses access immediately. The same connector covers every other source you connect afterwards, so a second integration costs a click rather than another five minutes. The general version of this walkthrough is in the guide to connecting training data to ChatGPT or Claude.

What honest coverage looks like

Some of this data is newer than the rest, and pretending otherwise would just make the model confidently wrong.

Splits and run dynamics started landing in August 2026 and do not cover every run. Roughly 6 in 10 runs carry splits, and roughly 3 in 10 carry dynamics. A missing field means not on this run: an older app build, an indoor run, a watch that does not write those samples. It never means Apple Health cannot deliver it, and it is not a statement about your watch. If a run from March has no ground contact data, that is a date problem, not a device problem.

Apple Health delivers no elevation gain and no GPS route. Not to anyone, not on any build. If you want a grade-adjusted pace on a hilly run, that has to come from another source recording the same session.

Sleep staging is the softest metric in the set. Researchers at Brigham and Women's Hospital comparing consumer trackers for four-stage sleep classification found Oura ahead of Apple Watch by a few percentage points, which matches how most people experience it. Total sleep duration is trustworthy. The deep and REM breakdown is directional. Ask questions that depend on duration and trend rather than on a specific number of minutes in deep.

Heart rate is the one to lean on. Stanford validation research put the Apple Watch heart rate sensor within a few beats per minute of a chest strap during steady exercise, which is well inside the tolerance that makes zone work meaningful. The same body of work is far more sceptical about energy burn, where every wrist wearable struggles. Trust the heart rate, use the calories for relative comparison only.

What changes about the conversation

The real shift is not that the model can recite your data back to you. It is that you stop pre-filtering.

When you have to type your context, you decide in advance what matters. You mention the hard session, because you think the hard session is the story. You do not mention nine nights of short sleep, because you never connected the two. With tools available, the model can go looking, and a well-posed answer to "why did today's easy run feel awful?" pulls yesterday's session, last night's sleep, your HRV trend and your recent load before it says anything.

A worked example, because the difference is concrete. Ask a model without tools whether to keep tomorrow's threshold session and you get a paragraph about listening to your body. Ask a model with these tools and it calls the HRV tool with a daily aggregate, sees four days below baseline, pulls the run stream from your last quality session and finds the reps already degrading from rep three, checks your calendar and notices Thursday is clear. Then it tells you the specific thing: move it to Thursday, keep tomorrow at 50 minutes easy. The reasoning for that kind of call is covered in the HRV-guided training guide.

It also means one connection is rarely the end. If you wear a Garmin for structured sessions and an Apple Watch the rest of the time, both land in the same place and the model reconciles them. The Garmin MCP server guide covers that side, and the cross-source questions are where the answers get genuinely hard to find anywhere else.

Where the connector stops and a coach starts

Tool access is not coaching, and the distinction is worth being blunt about.

The connector answers when you ask. It does nothing between conversations, so it will never notice that your resting heart rate has drifted up four beats over ten days and message you about it, because nothing is running while you are not typing. That is the actual product line: the MCP tier, at $9/month or $69/year, is for querying your own data inside your own AI client. The coaching plan, at $39/month, adds something that watches the data continuously, writes and rewrites a plan, and starts the conversation itself. Both include a 7-day free trial.

If what you want is the second thing, the Apple Health AI coach guide covers what that looks like day to day, and the Apple Health integration page lists exactly what syncs.

Putting it together: an Apple Health MCP checklist

1. Sign up on the web first, then install the iOS app from your invite. The app is not optional here, because Apple offers no server-side route into HealthKit.
2. Grant the full set of Health read permissions rather than a subset. A missing scope returns no samples and no error, which is the hardest failure to diagnose later.
3. Let the first sync finish on a charger. It is the only slow step, and it is where years of history arrive.
4. Check your AI client's plan before you start debugging anything. Claude Free is fine. ChatGPT needs Plus or better, on the web, with Developer mode on.
5. In ChatGPT, open with @athletedata so the plugin attaches. Most reports of a broken connector are this.
6. Verify with a question that needs data you have never typed, and check one number against the Fitness app. Once it matches, stop verifying and start asking.
7. Ask at the resolution your question actually lives at. Session averages for load, per-kilometre splits for pacing, the run stream for form drift inside a session.
8. Add a second source if you have one. Apple Health plus one dedicated device answers more than either alone, and it costs one extra click.
9. Revoke from your settings the moment you stop using a client or share a machine. Access ends immediately.

Your watch has been recording all of this for years, quietly, in a database on your phone. The only thing missing was a way for something smart to read it without you typing it out first.