Skip to main content
Glama
echocharlie

Oura MCP Server

by echocharlie
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Oura MCP server

CI

A Model Context Protocol (MCP) server that gives Claude read-only access to your Oura ring biometrics via the Oura API v2.

It's designed to sit alongside a Strava connector: every tool is namespaced oura_* and keyed by ISO date (YYYY-MM-DD), so Claude can join Oura recovery data against Strava training load on date and answer questions like "how did last week's hard sessions affect my sleep, stress, and next-day readiness?" in one reasoning step.

Claude running the Oura connector — daily summary with an overreach day highlighted

Illustrative example using sample data, not real biometrics.

Tools

Tool

What it returns

Default window

oura_get_daily_summary

Start here. One row/day: readiness, sleep & activity scores, total sleep, bedtime, resting HR, HRV, respiratory rate, temp deviation, breathing disturbance, steps, active calories, daytime stress. The cross-source join table.

30 days

oura_get_sleep_time

Oura's bedtime guidance: optimal bedtime window + recommendation (what Oura thinks you should do, vs. daily_summary's actual bedtime).

30 days

oura_get_sleep_detail

Per-night architecture: bedtime, sleep stages (deep/REM/light), efficiency, latency, avg/lowest HR, HRV, respiratory rate.

14 days

oura_get_readiness_detail

Readiness with every contributor (hrv_balance, resting HR, recovery index, body temp, previous-day activity, sleep balance…) — explains why readiness moved.

30 days

oura_get_stress_resilience

Daytime stress vs. recovery minutes, day summary, and long-term resilience level + contributors.

30 days

oura_get_workouts

Workouts as logged by Oura — reconcile against Strava, catch missed sessions, see intensity labels.

30 days

oura_get_baselines

Slow-moving baselines: overnight SpO2, breathing disturbance, pulse wave velocity (arterial stiffness), vascular age, VO2 max.

90 days

oura_get_heart_rate

Fine-grained HR timeseries, tagged by source (awake/rest/sleep/workout). Aggregated stats by default.

24 hours

All output is compact CSV with units stated in the column names.

Related MCP server: Oura MCP

Setup

python -m venv .venv && source .venv/bin/activate   # Windows: .venv\Scripts\activate
pip install -e .

New here? The full setup & configuration guide walks through install, token creation, the Claude Desktop config, common mistakes, and troubleshooting.

Authentication

This server uses an Oura Personal Access Token (PAT):

  1. Go to https://cloud.ouraring.com/personal-access-tokens and create a token.

  2. Copy .env.example to .env and paste the token into OURA_PERSONAL_ACCESS_TOKEN (for local dev), or set it in the Claude Desktop env block below.

Never commit your real token — .env is gitignored.

Run / test

fastmcp dev oura_mcp.py   # opens the MCP Inspector to exercise each tool manually

Run the tests (offline — no token or network needed):

pip install -e ".[dev]"
pytest -q

Install in Claude Desktop

Edit claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\) and add:

{
  "mcpServers": {
    "oura": {
      "command": "/ABSOLUTE/PATH/TO/oura-mcp-server/.venv/bin/python",
      "args": ["/ABSOLUTE/PATH/TO/oura-mcp-server/oura_mcp.py"],
      "env": {
        "OURA_PERSONAL_ACCESS_TOKEN": "your-token-here"
      }
    }
  }
}

Use the venv's Python interpreter and an absolute path to oura_mcp.py (older configs pointing at server.py still work — it's kept as a shim). Fully quit and reopen Claude Desktop after editing. The oura_* tools then appear in the tools/connectors menu, ready to use alongside your Strava tools.

Usage & examples

Once the server is connected, just ask Claude in plain language — it picks the right tool(s) and date ranges. A few patterns that work well:

Oura on its own

  • "Pull my Oura daily summary for the last two weeks."

  • "Did my readiness drop after any night this month? Show me why." → oura_get_readiness_detail

  • "Break down last night's sleep stages and compare them to my 14-day average." → oura_get_sleep_detail

  • "Which days this month were most stressful, and how's my resilience trending?" → oura_get_stress_resilience

  • "How's my VO2 max and SpO2 trending over the last 90 days?" → oura_get_baselines

  • "What was my heart rate during yesterday's workout vs. overnight?" → oura_get_heart_rate

The headline use case — Oura + Strava together

Because both connectors are date-keyed, Claude can join them on date in one step:

  • "Compare last month's Strava training load against my Oura readiness and sleep. Flag any days I overreached (readiness or HRV dropped the morning after a hard session)."

  • "After my long runs, how much does my resting heart rate rise the next morning, and how long until it recovers to baseline?"

  • "Do my hardest training days hurt that night's deep sleep? Show the correlation."

  • "Reconcile my Strava activities with Oura's logged workouts for the past month — did Oura catch anything Strava missed?" → oura_get_workouts

  • "Build me a weekly table: Strava distance & suffer score next to Oura sleep score, avg HRV, and next-day readiness, so I can see if my training plan is sustainable."

What the data looks like

Tools return compact CSV with units in the column names — easy for Claude to reason over and join. For example, oura_get_daily_summary returns rows like:

date,readiness_score,sleep_score,activity_score,total_sleep_h,bedtime,resting_hr_bpm,avg_hrv_ms,resp_rate_brpm,temp_deviation_c,breathing_disturbance_idx,steps,active_cal,stress_high_min,day_summary
2026-06-05,78,84,95,8.31,23:36,52,79,13.375,-0.16,0,8122,1211,360,stressful
2026-06-06,63,60,97,5.14,05:49,74,12,18.25,-0.19,6,7667,941,240,stressful
2026-06-07,85,87,96,7.95,01:01,60,37,17.125,0.13,1,7768,919,30,normal

Here the high-load, high-stress day (Jun 5: 1,211 active cal, 360 stressful min) is followed by a readiness crash (84→63), a resting-HR spike (52→74 bpm), and an HRV collapse (79→12 ms) — exactly the training-to-recovery signal this server is built to surface. Note the leading indicators moving with it: respiratory rate jumps 13.4→18.3 brpm and breathing disturbance 0→6 on the same night.

Tip: start broad with oura_get_daily_summary, then drill into a specific day or signal with the detail tools (oura_get_readiness_detail, oura_get_sleep_detail). Keep date ranges modest to stay fast and within Oura's rate limit.

Notes & limits

  • Read-only. No tool writes to your Oura account.

  • Dates are ISO YYYY-MM-DD and the range is inclusive. Heart rate uses ISO 8601 datetimes.

  • Some metrics are sparse or ring/firmware-dependent (VO2 max, cardiovascular age, resilience need enough history); rows show blanks where a metric wasn't measured.

  • VO2 max is a measurement event, not a daily value — often only a few readings per quarter, so most rows are blank by design. oura_get_baselines appends a footer with the latest reading in the window so blanks aren't misread as "no data."

  • Overnight SpO2 must be enabled in the Oura app (Settings → your ring) and needs sleep sessions longer than ~3 hours to register; it also increases battery drain.

  • pulse_wave_velocity_m_s (meters/second) is the raw arterial-stiffness measure (lower = more elastic); vascular_age_years is a derived presentation of the same signal. Prefer PWV for tracking real change over time.

  • Oura's rate limit is ~5000 requests/day; tools default to modest windows and paginate automatically.

Available Tools

8 tools
oura_get_baselinesA
Read-only

Slow-moving health baselines: SpO2, breathing, arterial stiffness, VO2 max.

These trend over weeks/months, so the default window is 90 days. Use to track long-term vascular and aerobic health alongside training history.

CSV columns: date, spo2_avg_pct (overnight blood-oxygen %), breathing_disturbance_index, pulse_wave_velocity_m_s, vascular_age_years, vo2_max_ml_kg_min

pulse_wave_velocity_m_s (meters/second) is the RAW arterial-stiffness measurement and the most clinically meaningful vascular metric here — lower is better/more elastic; it is the same class of measure (PWV) used in hypertension research. vascular_age_years is a derived presentation of it, so prefer PWV when tracking real change.

IMPORTANT — sparsity: vo2_max is a measurement EVENT, not a daily value (often only a handful of readings per quarter), so most rows will be blank for it. Blank does NOT mean "no VO2 data" — read the footer, which reports the most recent reading in the window. cardiovascular_age/VO2 also require a compatible ring/firmware.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO end date (YYYY-MM-DD), inclusive. Defaults to today.
start_dateNoISO start date (YYYY-MM-DD). Defaults to a 90-day window ending at end_date.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only indicate readOnlyHint=true. The description goes well beyond by disclosing data sparsity ('IMPORTANT — sparsity: vo2_max is a measurement EVENT...'), explaining blank rows, and detailing the clinical meaning of pulse_wave_velocity_m_s. It also notes compatibility requirements for some metrics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening, then a detailed column listing, and important usage notes. It is somewhat lengthy but every sentence adds value. It could be slightly more concise without losing essential detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the purpose, parameters, return format (CSV columns), and critical caveats (sparsity, PWV interpretation). Given the presence of an output schema, it does not need to repeat return value details. The level of detail is appropriate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters already well-described in the input schema. The description adds value by noting the default 90-day window and the inclusive nature of end_date, but does not fundamentally extend understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Slow-moving health baselines: SpO2, breathing, arterial stiffness, VO2 max.' which specifies the resource and scope. It distinguishes from siblings by focusing on long-term trend data versus other Oura metrics like stress, sleep, or workouts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear use case: 'Use to track long-term vascular and aerobic health alongside training history.' It mentions the default window of 90 days, which guides usage context. However, it does not explicitly state when not to use or provide alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oura_get_daily_summaryA
Read-only

One row per day joining readiness, sleep, activity, and recovery signals.

THIS IS THE CROSS-SOURCE JOIN TABLE. Use it first for almost any question about how training/activity relates to recovery — it lets you join Oura against a Strava connector on date in one step. Reach for the detail tools only to drill into a specific signal.

CSV columns (units in the name): date, readiness_score(0-100), sleep_score(0-100), activity_score(0-100), total_sleep_h, bedtime (HH:MM local, when sleep started), resting_hr_bpm (lowest nightly HR, a resting-HR proxy), avg_hrv_ms, resp_rate_brpm (overnight respiratory rate), temp_deviation_c (body temp vs baseline), breathing_disturbance_idx, steps, active_cal, stress_high_min (stressful daytime minutes), day_summary

Defaults to the last 30 days. Higher readiness/sleep/activity scores are better; a rising resting_hr or positive temp_deviation often signals incomplete recovery. resp_rate_brpm and breathing_disturbance_idx are leading illness/strain flags — a sustained rise in either often precedes a subjective sense of getting sick. bedtime is included because sleep timing (not just duration) drives next-day recovery, and it anchors any analysis of late meals/alcohol relative to sleep.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO end date (YYYY-MM-DD), inclusive. Defaults to today.
start_dateNoISO start date (YYYY-MM-DD). Defaults to a 30-day window ending at end_date.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. The description adds interpretative context: explains what columns mean (e.g., rising resting_hr signals incomplete recovery, resp_rate_brpm as illness flag). No contradictions, but could mention any rate limits or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative but verbose, with multiple paragraphs including detailed column explanations and interpretive notes. It could be more concise while retaining key guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return values need not be explained in detail. The description covers columns, units, defaults, and interpretative guidance. Missing error/exception info, but complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for start_date and end_date. The description reiterates defaults (last 30 days) but adds no new parameter-level details beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a cross-source join table for daily summaries combining readiness, sleep, activity, and recovery signals. It distinguishes itself from sibling detail tools by advising to use detail tools only for drilling into specific signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use this tool first for almost any question about training/activity vs recovery, and to join with Strava. It also tells when not to use it (reach for detail tools for specific signals).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oura_get_heart_rateA
Read-only

Fine-grained heart-rate timeseries (one sample every few minutes).

This is high-volume data, so default to a SHORT window (<= ~2 days) and the 'summary' format. Oura tags each sample with a source: awake, rest, sleep, workout, etc. — useful for isolating workout HR or overnight resting HR around hard training days.

summary -> CSV with one row per source: source, samples, min_bpm, avg_bpm, max_bpm, plus a final 'all' row. raw -> CSV: timestamp, bpm, source (capped at limit; narrow the window for more).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax raw samples to return when response_format='raw'.
end_datetimeNoISO 8601 end, e.g. 2026-06-15T00:00:00. Defaults to now.
start_datetimeNoISO 8601 start, e.g. 2026-06-14T00:00:00. Defaults to 24h before end.
response_formatNo'summary' = aggregated stats by source (few tokens); 'raw' = capped sample list.summary

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behavioral traits: high-volume data, source tagging (awake, rest, etc.), and output format differences. These go beyond the annotations' read-only hint, giving full context for selection and invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear topic sentence, usage advice, and format breakdown. Slightly verbose but every sentence adds value; could be tightened slightly but no waste exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully covers the tool's complexity given 4 parameters with 100% schema coverage, annotations present, and an output schema. No gaps in context for correct agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds significant meaning beyond the 100% schema coverage: explains the purpose of response_format values ('summary' vs 'raw') and how limit caps raw samples. The description clarifies usage context such as 'capped at limit; narrow the window for more.'

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'fine-grained heart-rate timeseries' and explains sampling frequency, distinguishing it from sibling tools like oura_get_sleep_detail or oura_get_workouts. It provides specific verb-resource mapping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends a short window and summary format to manage high-volume data, and explains when to use raw vs summary. This provides clear guidance for the agent across typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oura_get_readiness_detailA
Read-only

Daily readiness with every contributor broken out — explains WHY readiness moved.

Use when oura_get_daily_summary shows a readiness change and you want the driver. Each contributor is a 0-100 sub-score (higher = better). A low hrv_balance or resting_heart_rate contributor the morning after a hard session points to load.

CSV columns: date, score, temp_deviation_c, activity_balance, body_temperature, hrv_balance, previous_day_activity, previous_night, recovery_index, resting_heart_rate, sleep_balance

Defaults to the last 30 days.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO end date (YYYY-MM-DD), inclusive. Defaults to today.
start_dateNoISO start date (YYYY-MM-DD). Defaults to a 30-day window ending at end_date.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds context about contributor sub-scores (0-100), example interpretation, and default window. No contradictions. Could be slightly improved by clarifying output format (CSV vs JSON) but overall strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise with clear, front-loaded structure. First sentence states purpose and usage, second gives interpretation guidance, third lists columns. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has optional parameters, output schema present, and annotations present, the description is complete. It explains purpose, usage, data meaning, and defaults without needing to duplicate schema or output details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so parameters are already documented. The description reinforces defaults (30-day window, ISO format) but does not add new semantic information beyond what the schema provides. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides daily readiness with each contributor broken out, explaining why readiness changed. It directly contrasts with sibling tool oura_get_daily_summary, making its unique value explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to use this tool when oura_get_daily_summary shows a readiness change and the driver is needed. This provides clear when-to-use guidance, distinguishing it from alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oura_get_sleep_detailA
Read-only

Per-night sleep architecture for drilling into specific nights.

Use after oura_get_daily_summary when you need stage breakdown or sleep timing. One row per sleep period (a day may have a nap plus the main sleep).

Concise CSV columns: date, type, bedtime_start, bedtime_end, total_sleep_h, time_in_bed_h, deep_h, rem_h, light_h, awake_h, efficiency_pct, latency_min, avg_hr_bpm, lowest_hr_bpm, avg_hrv_ms, resp_rate_brpm

Defaults to the last 14 days. Use 'detailed' for raw fields and 5-min hypnogram.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO end date (YYYY-MM-DD), inclusive. Defaults to today.
start_dateNoISO start date (YYYY-MM-DD). Defaults to a 14-day window ending at end_date.
response_formatNo'concise' = CSV of key metrics; 'detailed' = full JSON incl. period ids and timeseries.concise

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description adds behavioral details: one row per sleep period (including naps), default 14-day window, and the effect of the response_format parameter. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with clear, front-loaded sentences. It earns its place by covering purpose, usage, format, and defaults without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description adequately explains behavior (per-night, nap handling, default window) and distinguishes from siblings. It is sufficiently complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds value by explaining defaults (last 14 days) and listing columns for the 'concise' format, which are not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it provides per-night sleep architecture for drilling into specific nights, distinguishing itself from oura_get_daily_summary by offering stage breakdowns and sleep timing with per-period granularity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly advises using this tool after oura_get_daily_summary when stage breakdown or sleep timing is needed, providing clear context but no explicit exclusions for other scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oura_get_sleep_timeA
Read-only

Oura's own bedtime guidance: the optimal bedtime window and what it recommends.

Use to answer "am I going to bed at the right time?" — distinct from oura_get_daily_summary's bedtime, which reports when you ACTUALLY slept. This is what Oura thinks you SHOULD do, derived from your circadian/temperature data.

CSV columns: date, optimal_bedtime_start, optimal_bedtime_end (local HH:MM; blank when Oura couldn't compute a window), recommendation, status

recommendation is one of: follow_optimal_bedtime — you're aligned; keep the current window earlier_bedtime — go to bed earlier later_bedtime — go to bed later earlier_wake_up_time / later_wake_up_time — adjust the wake side instead

status is one of: optimal_found — a concrete window was computed (times populated) only_recommended_found — Oura has a direction but NOT enough data for a window, so the time columns are blank. This is normal, not an error. not_enough_nights / no_data — insufficient history in the range.

Note: Oura returns these times as raw second-offsets from local midnight; this tool decodes them to HH:MM. A run of identical earlier_bedtime rows means Oura has been persistently flagging late sleep timing — worth reading as a trend, not a single day.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO end date (YYYY-MM-DD), inclusive. Defaults to today.
start_dateNoISO start date (YYYY-MM-DD). Defaults to a 30-day window ending at end_date.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. Description adds extensive behavioral context: explains CSV columns, enumerations for recommendation and status, notes blank times for status 'only_recommended_found', and advises reading trends over single days. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with purpose upfront, followed by columns and enumerations in bullet-like format. Slightly lengthy but every part adds value; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 optional parameters and presence of output schema, description independently and thoroughly explains the output format (CSV columns, possible values) and edge cases (blank times, trend reading). Complete for a data-retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. Description does not add meaning beyond schema for start_date and end_date; it focuses on output interpretation. No additional parameter context given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Oura's own bedtime guidance: the optimal bedtime window and what it recommends.' It explicitly distinguishes from sibling oura_get_daily_summary's `bedtime`, which reports actual sleep time, thus differentiating resource and scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use to answer "am I going to bed at the right time?"' and contrasts with oura_get_daily_summary, providing a clear alternative and when-not-to-use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oura_get_stress_resilienceA
Read-only

Daytime stress load plus long-term resilience — the daytime side of recovery.

Combines the daily_stress and daily_resilience collections into one table so you can see whether high-load days accumulate physiological stress and erode resilience.

CSV columns: date, stress_high_min (stressful daytime minutes), recovery_high_min (restorative minutes), day_summary (restored|normal|stressful), resilience_level (limited|adequate|solid|strong|exceptional), sleep_recovery, daytime_recovery, stress (the last three are 0-100 resilience contributors).

Defaults to the last 30 days. Resilience needs ~weeks of data to populate.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO end date (YYYY-MM-DD), inclusive. Defaults to today.
start_dateNoISO start date (YYYY-MM-DD). Defaults to a 30-day window ending at end_date.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true, so the description adds value by noting default 30-day window and that resilience requires weeks of data. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description efficiently communicates purpose and columns, but the CSV column list adds length. It could be slightly tighter while remaining informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description covers purpose, output structure (column list), default behavior, and a data-population caveat. It is fully adequate for agent selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and adequately documents start_date and end_date. The description adds no extra parameter details beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fetches daytime stress and long-term resilience data, combining two collections. It distinguishes from siblings by specifying 'daytime side of recovery' and listing CSV columns, providing a specific verb+resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for viewing stress alongside resilience but does not explicitly state when to use it versus siblings like oura_get_daily_summary. No when-not-to-use or alternative guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

oura_get_workoutsA
Read-only

Workouts as logged by Oura — cross-check or supplement Strava activities.

Oura auto-detects and lets you tag workouts. Use this to reconcile against a Strava connector (match on date/time), catch sessions Strava missed, or see Oura's intensity label. source shows how the workout was recorded (e.g. auto_detected, manual, confirmed).

CSV columns: date, activity, intensity (easy|moderate|hard), start_time, end_time, duration_min, distance_km, calories, source, label

Defaults to the last 30 days.

ParametersJSON Schema
NameRequiredDescriptionDefault
end_dateNoISO end date (YYYY-MM-DD), inclusive. Defaults to today.
start_dateNoISO start date (YYYY-MM-DD). Defaults to a 30-day window ending at end_date.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=true, and the description adds context about default date range, CSV columns, and the `source` field meaning. No contradiction; the description enhances transparency beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short paragraphs: first explains purpose and usage, second lists CSV columns. No unnecessary words; every sentence adds value. Front-loaded with key purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity, full schema coverage, and presence of an output schema, the description provides all needed behavioral and usage context. CSV column list compensates for missing output schema details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and describes parameters well. Description adds that start_date defaults to a 30-day window, which is already in schema. No additional semantics beyond schema, meeting baseline for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves workouts logged by Oura and explicitly distinguishes it from siblings by mentioning cross-referencing with Strava activities. The verb 'get' and resource 'workouts' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit use cases: reconcile against Strava, catch missed sessions, see intensity label. However, it does not explicitly state when not to use this tool or mention alternatives, though siblings are listed elsewhere.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv0.2.2
    • First observedoura_get_baselines
    • First observedoura_get_daily_summary
    • First observedoura_get_heart_rate
    • First observedoura_get_readiness_detail
    • First observedoura_get_sleep_detail
    • First observedoura_get_sleep_time
    • First observedoura_get_stress_resilience
    • First observedoura_get_workouts
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool targets a distinct data domain (stress, sleep detail, bedtime guidance, readiness breakdown, workouts, baselines, HR timeseries) with no overlap. The descriptions explicitly clarify differences, like separating actual bedtime from recommended bedtime.

Naming Consistency5/5

All tools follow the consistent pattern 'oura_get_<noun_phrase>' in snake_case. The verb 'get' is used uniformly, and the noun phrases clearly indicate the data type (e.g., 'stress_resilience', 'daily_summary', 'sleep_detail').

Tool Count5/5

With 8 tools, the server covers the major categories of Oura health data without being overly granular or sparse. Each tool earns its place, offering focused access to key metrics while avoiding unnecessary fragmentation.

Completeness4/5

The tool set covers most primary Oura data types (sleep, readiness, activity, HR, stress, baselines, workouts). Minor gaps exist, such as missing dedicated tools for user tags or activity detail beyond the summary, but the daily summary serves as a central join table that mitigates this.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Oura MCP Server

    YuzeHao2023
    A
    license
    B
    quality
    C
    maintenance
    Provides access to Oura Ring health data including sleep, readiness, and resilience metrics through the Oura API, enabling language models to query and analyze personal health information.
    6
    115
    MIT

  • Oura MCP

    ai-niki
    A
    license
    Not graded
    quality
    D
    maintenance
    Provides LLMs with access to Oura Ring health data including sleep metrics, activity tracking, heart rate, readiness scores, and other wellness insights through the Oura API v2.
    MIT

  • oura-mcp-server

    BarnNorth
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables Claude Desktop and Claude Code to access your personal Oura Ring health data—including sleep, readiness, activity, heart rate, and workouts—through local MCP tools.
    11
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/echocharlie/oura-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server