Oura MCP Server: Connect Your Oura Ring to Claude and ChatGPT

Your readiness score is 62 and you do not know why. Sleep looked fine, you did not train hard yesterday, and the app's contributor breakdown says body temperature is the culprit without saying anything else.

So you open Claude and ask. And Claude, being a good model, gives you a careful and completely generic answer about what elevated body temperature can indicate: early illness, alcohol, a warm room, the luteal phase, overtraining. All true. None of it about you, because the only thing it knows about you is the number 62 and the word "temperature".

What would actually settle it is the last six months. Whether your temperature deviation has run high before every one of the three times you got ill. Whether it spikes on the nights after you tag alcohol. Whether this is a two-day blip or the fourth day of a slow climb. That context exists, sitting in Oura's servers, and nobody is pasting six months of it into a chat window.

An MCP server is how the model goes and reads it instead.

What MCP actually is

The Model Context Protocol is an open standard that lets AI assistants call external tools. Anthropic published it in late 2024 and it has since been adopted well beyond Claude: ChatGPT, Cursor and Perplexity all speak it. The protocol is deliberately unexciting. A server advertises tools, each with a name and a schema. The model decides when to call one. Structured data comes back.

For sleep and recovery data that shape fits well. You do not want a static export sitting in a context window and going stale tonight. You want the model to fetch a specific window when a question needs one, the way you would swipe back through the Oura app to compare this month against last.

So "Oura MCP server" means a server that exposes your ring's history as tools. Ask "does my deep sleep drop on the nights I tag alcohol?" and the model pulls your sleep periods and your tags for the same range, joins them, and answers with your numbers.

What the Oura connector exposes

The AthleteData MCP server registers 17 Oura-specific tools when Oura is connected. That is the deepest per-provider coverage of any recovery wearable on the platform, and it reflects how much Oura's API actually returns.

Sleep, in two layers. oura_get_daily_sleep returns Oura's own per-day sleep scores with the contributor breakdown. oura_get_sleep_periods returns the layer underneath: deep, REM, light and awake durations per period, overnight average and lowest heart rate, overnight HRV, restlessness, and bedtime and wake timing. The second one is where the real analysis happens. A sleep score of 71 tells you Oura is unimpressed. Sixty-one minutes of deep sleep against your usual eighty-five, with a lowest overnight heart rate four beats high, tells you what happened.

Readiness and its contributors. oura_get_daily_readiness returns the 0-100 score plus the fields that make it up: HRV balance, resting heart rate, body temperature deviation, recovery index and sleep balance. Those contributors are the useful part. Two identical 62s built from different contributors are different mornings and want different decisions.

Autonomic and stress load. oura_get_daily_stress returns the daily stress index and high-stress minutes. oura_get_daily_resilience covers daytime and evening recovery and how well you are absorbing stress across the day. Neither is training data, which is exactly why they matter: a hard week at work loads the same system a hard week of training does, and Oura is one of the few sources that measures it.

The physiological long tail. oura_get_heart_rate for continuous heart rate, oura_get_daily_spo2 for blood oxygen, oura_get_vo2_max for cardio capacity estimates, oura_get_cardiovascular_age derived from arterial stiffness, oura_get_daily_activity for steps and movement, and oura_get_sessions for meditation and breathing work with the heart rate and HRV recorded during them.

Context fields most people never query. oura_get_enhanced_tags returns your own tags: alcohol, caffeine, illness, stress, menstruation, whatever you log. oura_get_rest_mode_periods returns the stretches where you told the ring you were sick or recovering. oura_get_sleep_time returns Oura's recommended bedtime windows and whether you are hitting them. oura_get_personal_info and oura_get_ring_configuration cover the basics plus your ring model and firmware.

Alongside those, the connector registers around thirty cross-source analytics tools that are not Oura fields at all: 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. Those compute across everything you have connected, which is where the questions get interesting.

The tags are the underused part

If you take one thing from this guide, take this: oura_get_enhanced_tags is the highest-value tool in the set and almost nobody queries it.

Every other field is physiology. Tags are the only place where cause lives. A model looking at a bad night can tell you the stages were poor. A model that can also read that you tagged alcohol and a late meal can tell you which nights with that combination have been poor, how many, and by how much against your baseline. That is the difference between describing a night and explaining one.

It only works if you tag. If you have never used the feature, the tool returns nothing and the correlation questions are unavailable. Two weeks of tagging alcohol, caffeine after 2pm, illness and unusually late meals is enough to make the analysis worth running, and it costs a few seconds a day.

The same logic applies to rest mode. A model that does not know you flagged three days as sick will read the temperature spike and the flattened HRV as a training-load problem and tell you to deload, which is the wrong advice for a chest infection.

What Oura does not send

Being specific about the gaps is more useful than listing features, because a model will confidently fill a silence.

No pace, power or GPS. Oura is a recovery device worn on a finger. It does not know how fast you ran. If you want reasoning about training intensity, you need a device or activity source alongside it, and the same connector handles that: Garmin, Wahoo, COROS, Zwift and others land in the same place. The Garmin MCP server guide covers that side of the setup.

Auto-detected workouts are noisy. oura_get_workouts returns both manually logged and auto-detected sessions, and Oura's detection is generous. Walks, commutes and housework register as activity. When another source recorded the same session properly, the platform prefers it. When Oura is the only source, check the timestamp before treating a detected session as training.

Some fields are hardware and firmware dependent. Blood oxygen needs Gen 3 or newer, and the newer derived metrics are not reported by every ring. When a metric is simply absent rather than wrong, oura_get_ring_configuration returns your model, firmware and setup date, which answers the question faster than a support search.

A score is not a diagnosis. Readiness is Oura's model of you, and it is a good model, but it compresses five contributors into one number and the compression is where information goes. The reason to put the ring behind an AI client is to get underneath the compression, not to have something else read the score aloud.

Why this beats the alternatives

Screenshots. The model reads them imperfectly, cannot follow up, and cannot compare last night against March. You also decide what matters before the model has seen anything.

CSV or JSON exports. Oura will give you an export. It is accurate on the day you take it and stale the next morning, and re-exporting before every conversation is friction nobody keeps up.

A self-hosted script. Oura's API is well documented and wrapping it in a local MCP server is a genuinely reasonable weekend project. The costs are the usual ones plus one specific to Oura: Oura rotates its refresh token on every refresh. Each successful refresh returns a new pair and invalidates the old one, so a dropped write, a crashed process or two instances refreshing concurrently loses the grant and you re-authorize by hand. It is the kind of failure that happens quietly and turns up a week later when a query returns nothing. Handling it properly is most of the work in maintaining one.

The hosted route uses Oura's official API through an OAuth grant, refreshes server-side, and revoking access is a button on the Oura integration page.

Setting it up

1. Connect Oura. Sign in at athletedata.health, open the integrations page, click Connect on Oura. You land on Oura's own consent screen listing the scopes. Approve, and the connection is live.

2. Let the backfill run. The initial pull brings in roughly 180 days of sleep, readiness, activity and heart rate history. Depth matters more here than for most sources, because every Oura number is relative to your own distribution. A readiness of 62 means nothing in isolation and quite a lot against six months of your own mornings.

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

4. Add it to your AI client. In Claude: 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, with step-by-step pages for all four in the MCP setup section.

5. Ask something you have never typed. "What has my overnight HRV done across the last 60 nights, and which nights were the outliers?" You will see the tool calls fire before the answer. That is the confirmation the connection is live.

What changes about the conversation

The shift is that you stop pre-filtering.

When you type your own context you decide in advance what is relevant, and you are frequently wrong about that. You mention the 62 because the 62 is what you noticed. You do not mention that your bedtime has drifted 50 minutes later across the last fortnight, because that drift was invisible to you. With tools available the model can go looking, and the useful answers come from the questions you did not know to ask.

The cross-source questions are where this stops being a convenience. Oura tells you last night was poor. It cannot tell you whether your sleep is systematically worse in the 48 hours after threshold sessions than after easy volume, because that needs your training log, which Oura has never seen. Connect an activity source and that join is one tool call away. Our HRV-guided training guide covers what to do with those patterns once they are visible, and the Oura ring coaching guide covers how readiness should and should not drive a training decision.

A worked example. Ask a model with no tools "why is my readiness 62?" and you get the list of possible causes. Ask a model with tools and it calls oura_get_daily_readiness for the last three weeks, oura_get_sleep_periods for the nights involved, and oura_get_enhanced_tags for the same range. It notices your temperature deviation has climbed for three consecutive days, that the same three-day shape preceded both of your logged illness tags this year, and that nothing in your training explains it. Then it tells you the useful thing, which is to keep today easy and watch tomorrow rather than to deload a block.

Where the coaching tier fits

Tool access is not a coach, and the line is worth stating plainly.

The connector answers questions you ask. It does not notice on a Tuesday that your temperature has been climbing and message you, because nothing runs between your conversations. That is the 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 continuously, builds and rebalances a training plan, and starts the conversation itself. Both include a 7-day free trial.

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. If Oura plus a watch is your setup, this changes nothing, because your sessions arrive from the watch directly.

Oura is one source among many. The same connector exposes WHOOP, Garmin, Hevy, Withings, Apple Health, Intervals.icu, TrainingPeaks, Wahoo, COROS, Polar, Zwift and others through one connection. The general guide to connecting training data to ChatGPT or Claude has the full list.

Wearing two recovery devices is a legitimate setup. Plenty of athletes wear an Oura ring and a WHOOP, and the disagreements between them carry information rather than noise. The connector reads both, and the Oura versus WHOOP comparison covers where each is stronger. If WHOOP is the one you want set up next, the WHOOP MCP server guide is the equivalent walkthrough.

Cycle phase changes what the numbers mean. For athletes who menstruate, body temperature and HRV move predictably across the cycle, and a luteal-phase temperature rise is biology rather than a warning. Tagging menstruation makes that legible to a model that would otherwise read the same shape as early illness.

Putting it together: an Oura MCP setup checklist

1. Connect Oura on the integrations page and approve the OAuth scopes. Confirm the connection reads as live.
2. Let the 180-day backfill finish before asking baseline questions. Two weeks of readiness data will mislead you and the model equally.
3. Start tagging. Alcohol, illness, late meals, unusual stress. Two weeks of tags turns the whole set from description into explanation.
4. Connect an activity source alongside the ring. Oura supplies the recovery side; something else has to supply what you actually did.
5. Copy your MCP URL and treat it like a password, because the API key is embedded in it.
6. Add the connector to your AI client and confirm it reports as Connected.
7. Verify with a question that needs data you have never typed, such as your five worst nights of the last 90 days and what you had tagged on each.
8. Then ask a correlation question rather than a single-night one. "Which of my tags has the strongest association with a drop in deep sleep?" is the kind of question this exists for.
9. Revoke the key from the dashboard if you share a machine or stop using a client.

The ring has been recording every night since you put it on. The score on the screen was never the hard part. Reading six months of it at once, in the middle of a question, is.