WHOOP MCP Server: Connect WHOOP to Claude and ChatGPT

You wake up, open WHOOP, and it says 34% recovery. You have a threshold session on the calendar. So you open Claude, type "my WHOOP recovery is 34%, should I train hard today?", and get back a thoughtful, well-written answer from a model that has never seen a single one of your nights.

It does not know that 34% is your fourth sub-50 morning in a row. It does not know your HRV has been sitting eight milliseconds under your own baseline since Sunday. It does not know that the last three times this pattern showed up you got sick within the week. It knows one number, because one number is all you typed.

That gap is not a model problem. Claude and ChatGPT are genuinely good at this kind of reasoning. They are just blind, and you cannot type your way out of blindness, because the context that would make the answer good is six months of nightly physiology and nobody is pasting that into a chat box.

An MCP server closes the gap at the root. Instead of you describing the number, the model goes and reads 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 adoption has spread well past Claude: ChatGPT, Cursor and Perplexity all speak it now. The protocol itself is deliberately boring. 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 physiological data that shape is exactly right. You do not want a static dump of your history sitting in a context window, going stale the moment you sleep again. You want the model to ask a question when it needs an answer, the way you would open the WHOOP app and swipe back to a specific week.

So "WHOOP MCP server" means a server that exposes your WHOOP history as tools. Ask "has my recovery been worse on nights after lifting than after running?" and the model pulls recovery records and workouts for the same window, joins them, and answers from your data rather than from general knowledge about resistance training and autonomic recovery.

What the WHOOP connector exposes

The AthleteData MCP server registers five WHOOP-specific tools when WHOOP is connected. Five is a small number next to some providers, and that is a fact about WHOOP rather than about the connector: WHOOP's API is narrow and deep rather than wide. Each of these returns a lot.

whoop_get_recovery returns per-night recovery: the 0-100 recovery score, HRV as rMSSD in milliseconds, resting heart rate, blood oxygen and skin temperature deviation. The raw HRV and resting heart rate are the interesting fields, not the score. A recovery percentage is WHOOP's own compression of those inputs against its own model of you, and it is far more useful to ask a model to compare this morning's rMSSD against your own 30-day distribution than to have it repeat a number you can already read on your wrist.

whoop_get_cycles returns day-level physiological cycles: day strain on WHOOP's 0-21 scale, day-level average and maximum heart rate, and kilojoules burned. One thing worth internalising before you start asking questions about strain: it is logarithmic and it is not additive. A 14.0 and a 15.0 are not a point apart in any meaningful sense, and two sessions at 10 do not make a 20. It is also not TSS and does not convert to it. Models will happily treat it as if it were linear unless something tells them otherwise, which is why the tool description says so explicitly.

whoop_get_sleep returns nightly sleep: time in bed and time asleep, the stage breakdown across light, deep, REM and awake, sleep performance, efficiency and consistency scores, respiratory rate, and sleep need against sleep achieved. That last pair is the one WHOOP does better than almost anyone. Sleep need is dynamic, moving with your recent strain and sleep debt, so "you got 7 hours" and "you got 7 hours against a need of 8 hours 40" are different statements and only the second one is coaching.

Respiratory rate is in that record too, and it is worth calling out separately: a reading more than about 1 breath per minute above your own baseline is one of the earlier illness signals a wearable can give you, and it usually moves before you feel anything.

whoop_get_workouts returns WHOOP-tracked sessions: sport, duration, average and maximum heart rate, time in each heart rate zone, strain and energy.

whoop_get_body_measurement returns height, weight and max heart rate, which sounds trivial until a model needs to sanity-check a zone distribution or a calorie figure and has to guess otherwise.

Alongside those, the connector registers around thirty derived analytics tools that are not WHOOP fields at all. They compute across every source you have connected: get_pmc_status for fitness and fatigue balance, get_readiness_today, get_training_trends, get_load_balance, get_injury_risk, get_anomalies, get_daily_metrics and the power and pace curves. These tend to be the ones that change how the conversation goes, because they answer questions the WHOOP app does not have a screen for.

What WHOOP does not send, and why it matters

Being specific about the gaps is more useful than listing features, because the gaps are where a model will confidently invent something if nobody tells it.

No VO2max. WHOOP does not report one. If your AI client offers you a VO2max trend and WHOOP is your only connected source, it is making it up.

No pace, power or GPS depth. WHOOP is a physiological monitor, not a training computer. It knows your heart rate went to 178 for eleven minutes. It does not know you were running 3:55 per kilometre while it happened. If you want the model to reason about pace or power, you need a device source alongside it, and the same connector handles that: a Garmin, Wahoo or COROS connection lands in the same place. The Garmin MCP server guide covers that side.

Auto-detected workouts are noisy. WHOOP will detect activity from heart rate alone, which means commutes, brisk walks and the occasional stressful meeting show up as workouts. When another source has recorded the same session properly, the platform prefers it. When WHOOP is the only source, it is worth a glance at the timestamp before treating a detected session as real training.

Some records carry no score at all. A WHOOP record can come back marked as scored while containing no score object, which is what happens for things like a sauna session where WHOOP measured no meaningful heart rate or strain. That is a different situation from partial sensor coverage, and conflating the two produces confidently wrong answers about effort. The connector annotates both cases so the model can tell them apart.

That last category is the sort of thing that only turns up once you have run a coaching product against real data for a while. It is in the tool descriptions because our own coach got it wrong first.

Why this beats the alternatives

There are three other ways people try to get WHOOP data in front of a model, and each fails in a specific way.

Screenshots. The model reads them imperfectly, cannot follow up, and cannot compare this week against a week in March. You are also choosing what matters before the model has looked at anything, which defeats the purpose of asking.

CSV exports. WHOOP will give you a data export. It works exactly once, then goes stale the next time you sleep, and re-exporting before every conversation is friction nobody sustains past the second attempt.

Self-hosted scripts. Search for "whoop mcp" and you will find open-source projects that wrap WHOOP's API in a local server. They work, and if you enjoy maintaining one, nothing here argues against it. The costs are the usual ones: a process that has to stay running, OAuth tokens you refresh yourself, and a setup that only exposes WHOOP, so the cross-source questions stay out of reach.

The hosted route uses WHOOP's official API through an OAuth grant. Nothing runs on your machine, tokens refresh server-side, and revoking access is a button on the WHOOP integration page rather than a password change.

Setting it up

The whole flow is about five minutes, and most of it is WHOOP's consent screen.

1. Connect WHOOP. Sign in at athletedata.health, open the integrations page and click Connect on WHOOP. You land on WHOOP's own OAuth screen listing the scopes being requested. Approve, and you come back with the connection live.

2. Let the backfill run. The initial pull brings in roughly 180 days of recovery, sleep, cycle and workout history. That depth matters more for WHOOP than for most sources, because every WHOOP number is relative. A 34% recovery is only interpretable against your own distribution, and a baseline built from two weeks of data is not a baseline. After the backfill, WHOOP webhooks keep the connection current, so new nights arrive within minutes of your watch syncing.

3. Copy your MCP URL. In the dashboard, use the Copy MCP URL button. It produces a URL of the form https://mcp.athletedata.health/mcp?apiKey=sk_soma_.... That key is yours alone and is revocable from the same page, so treat the URL like a password.

4. Add it to your AI client. In Claude, open Settings, then Connectors, then Add custom connector. Name it athletedata, paste the URL, click Add. It should report as Connected. ChatGPT, Cursor and Perplexity each have an equivalent panel, and there are step-by-step pages for all four in the MCP setup section.

5. Ask something you have never typed. Open a new chat and ask a question that requires data you have not mentioned, for example "what has my HRV done over the last 30 days relative to the 30 before that?" You will see the tool calls fire before the answer arrives. That is the confirmation the pipe is live.

What changes about the conversation

The shift is not that the model can now recite your recovery score. It is that you stop pre-filtering.

When you have to type your context, you decide in advance what is relevant. You mention the 34% recovery because you think the 34% is the story. You do not mention that you have been in bed at midnight for nine days, or that your respiratory rate is up half a breath, because you did not connect them. With tools available the model can go looking, and the good answers come from questions you would not have known to ask.

The questions that show this off are the cross-source ones. WHOOP tells you today's recovery. It does not tell you whether your recovery is systematically worse after strength sessions than after equivalent endurance load, because that requires joining WHOOP recovery records against a lifting log WHOOP has never seen. Connect a strength source and the join is one tool call away. Our HRV-guided training guide covers the framework for acting on those trends once you can see them.

A worked example, since the difference is concrete. Ask a model with no tools "should I do tomorrow's threshold session?" and you get a paragraph about listening to your body. Ask a model with tools and it calls whoop_get_recovery for the last two weeks, get_pmc_status for your load balance and whoop_get_sleep for the nights involved, notices your rMSSD has been below baseline for four days while your acute load has climbed and your sleep need has been unmet on five of seven nights, and gives you the specific answer: move it to Thursday, keep tomorrow at 45 minutes easy.

That is the same reasoning a good coach does. It just needs to be able to see.

Where the coaching tier fits

Tool access is not a coach, and it is worth being clear about the line.

The connector answers questions you ask. It does not notice on Tuesday that your resting heart rate has climbed for six straight mornings and message you about it, because nothing is running between your conversations. That is the actual difference between the two products. The MCP tier at $9 a month, or $69 a year, is for querying your own data inside your own AI client. The full coaching plan at $39 a month, or $389 a year, adds a coach on Telegram, iMessage or WhatsApp that watches the data continuously, builds and rebalances a training plan around it, and starts the conversation itself when something changes. Both include a 7-day free trial.

If what you want is the second thing, the WHOOP recovery coach guide covers what proactive coaching on WHOOP data actually looks like day to day. If what you want is the first, everything above is the whole setup.

The limits worth knowing about

Strava is not available over MCP. Strava's API terms do not permit serving Strava data to third-party AI platforms and tools, so it is excluded from the connector entirely. If WHOOP plus a device is your setup, this changes nothing, because your sessions already arrive from the device directly.

WHOOP is one source among many. The same connector exposes Oura, Garmin, Hevy, Withings, Apple Health, Intervals.icu, TrainingPeaks, Wahoo, COROS, Polar, Zwift and others through one connection. If you wear WHOOP and train on a Garmin, the model sees both, and that is where the answers get genuinely hard to obtain anywhere else. The general guide to connecting training data to ChatGPT or Claude has the full source list.

Two recovery wearables is a real setup, not a mistake. Plenty of athletes wear WHOOP and an Oura ring, and the two disagree often enough to be interesting rather than annoying. The connector reads both. Our three-way comparison of WHOOP, Oura and Garmin covers where each one is strongest and what the validation research says about their agreement with clinical measurement.

A recovery score is an input, not an instruction. The most useful thing about putting WHOOP behind a model is that it stops the score being the answer. A 34% with stable HRV and a bad night's sleep is a different situation from a 34% with rMSSD eight milliseconds down on a fourth consecutive day, and only one of them means move the session.

Putting it together: a WHOOP MCP setup checklist

1. Connect WHOOP on the integrations page and approve the OAuth scopes. Confirm the connection shows as live.
2. Let the 180-day backfill finish before you start asking baseline questions. A recovery trend built on ten days of data will mislead you and the model equally.
3. Connect at least one activity source alongside WHOOP, whether that is a watch, a head unit or a strength log. WHOOP supplies the physiology; something else has to supply what you actually did.
4. Copy your MCP URL from the dashboard and treat it like a password, because the API key is embedded in it.
5. Add the connector to your AI client and confirm it reports as Connected.
6. Run one verification question that needs data you have never typed, such as your lowest recovery score of the last 90 days and what you did the day before it.
7. Then ask a cross-source question rather than a single-metric one. "How does my recovery on the morning after a lifting session compare to the morning after an equivalent endurance session?" is the kind of question this exists for.
8. Revoke the key from the dashboard if you share a machine or stop using a client. One click, and every session using it dies.

WHOOP has been measuring you every night for as long as you have worn it. The number on the screen was never the hard part. Reading six months of it at once, in the middle of a conversation, is.