This server connects Oura Ring data to conversational AI clients (ChatGPT, Claude, etc.), enabling natural-language queries about your health and wellness — all read-only, defaulting to the last 7 days with no arguments needed.
Sleep Scores: Daily sleep scores (0–100) with contributor breakdowns (deep sleep, REM, latency, timing).
Sleep Details: Per-night session data including bed/wake times, sleep stages in minutes, sleep latency, efficiency, night heart rate, HRV, and breathing rate.
Readiness Scores: Daily recovery scores with contributors like HRV balance, resting heart rate, sleep balance, and body temperature deviation — useful for "should I train today?"
Activity Tracking: Daily activity scores, step counts, active and total calories, and optionally minutes by intensity level.
Stress Monitoring: Daily stress summaries including high stress minutes, high recovery minutes, and an overall day verdict (e.g., "restored", "stressful").
Health Vitals: Slow-changing metrics like blood oxygen (SpO2), breathing disturbance index, resilience level, cardiovascular age, and VO2 max.
Workouts & Sessions: Logged workouts (type, intensity, calories, distance) and mind-body sessions (meditation, breathing, relaxation).
User Tags: Tags logged in the Oura app (caffeine, alcohol, sickness, custom notes) to correlate lifestyle factors with health outcomes.
Hourly Heart Rate: Aggregated avg/min/max bpm across day and night for up to 3 days.
Profile & Ring Status: User profile info (age, sex, height, weight) and ring details (model, firmware, battery level).
Most tools support a concise or detailed response format for token efficiency, and the server works in demo/sandbox mode without an Oura account.
Ask your Oura Ring anything. In ChatGPT or Claude, in any language.
A remote MCP server that connects Oura Ring data to any MCP client. No UI, no app, no model of its own: the assistant you already pay for calls the tools and explains your data in whatever language you speak.
You: how did I sleep this week?
ChatGPT: Your week was uneven, averaging 65/100. Best night was June 29 (77) with strong deep sleep. The rough one was July 2 (47): little REM, low efficiency, and your bedtime drifted way off schedule. The main pattern to fix is sleep timing.
Get started in two clicks: download oura-mcp.mcpb from the latest release and double-click it — Claude Desktop installs the extension, and demo mode works instantly with zero setup (fake sample data, no Oura account needed). Connecting your own ring takes ~5 minutes: Run locally.
Things to try once connected:
Should I train hard today or take it easy?
Compare my sleep on workdays vs the weekend.
Did the late coffee I tagged yesterday show up in my night heart rate?
Какой у меня был пульс сегодня днём?flowchart LR
A["ChatGPT / Claude"] -- "MCP (Streamable HTTP)" --> B["oura-mcp"]
B -- "REST, read-only" --> C["Oura API v2"]One small Node.js process, stateless — a fresh MCP server instance per request. The client model picks the right tools, the server returns compact, pre-shaped JSON, the model does the talking. Curious how it's put together and why? See docs/ARCHITECTURE.md.
When you don't need this: if you want dashboards and charts, the Oura app already does that; if you want raw data for scripts, call the Oura API directly. This server exists for one thing: making your ring data conversational in the chat client you already use.
Related MCP server: Oura MCP Server
Tool | Ask things like |
| "How did I sleep this week?" |
| "When did I fall asleep? How much deep sleep? Night heart rate?" |
| "Should I train today? Is my temperature elevated?" |
| "How many steps and calories yesterday?" |
| "How stressed was I on Monday?" |
| "What's my SpO2, VO2 max, cardiovascular age?" |
| "How was my run? Did I meditate this week?" |
| "Did coffee affect my sleep?" (reads tags you log in the Oura app) |
| "What was my pulse this afternoon?" (hourly aggregates) |
| "How charged is my ring?" |
All tools are read-only and marked with readOnlyHint, so ChatGPT does not nag you for confirmation on every call.
Task-oriented tools, not 1:1 endpoint wrappers. 18 Oura endpoints grouped into 10 tools that match how people actually ask questions.
Token-efficient responses. Durations converted to minutes server-side, units baked into field names (deep_min, efficiency_pct), raw time series and internal IDs stripped. A tool response is 0.2–3 KB, not 50.
response_format: concise | detailed on data-heavy tools. Concise by default, breakdowns on demand.
Actionable errors. A too-wide heart rate query returns "ask for 3 days or less, or use oura_get_readiness for trends", not a 400.
Sane defaults. Every tool works with zero arguments (last 7 days).
An Oura Ring with an active Oura subscription (the API returns 403 without one) — or nothing at all for the sandbox demo mode
Node 22+ or Docker
5 minutes to register your own Oura OAuth app (below)
Only for the remote path (ChatGPT, claude.ai web): any host with public HTTPS — a free-tier VM behind Caddy works fine. Avoid free tiers that sleep between requests: ChatGPT times out on cold starts
Oura deprecated personal access tokens in December 2025, so an OAuth app is the only supported way to access your data — this is Oura's rule, not this project's. Registering one is free, instant, and needs no review for personal use. It is also the best part of the design: your tokens are issued to your app and live on your server, so your health data never depends on anyone else's infrastructure — including mine.
No server to deploy: Claude Desktop starts oura-mcp itself as a local process.
Install (two clicks): download oura-mcp.mcpb from the latest release, double-click it, press Install. Done — demo mode works immediately (fake sandbox data, no Oura account), so you can try every tool before any setup. Claude will remind you the numbers are samples.
Connect your real ring (~5 minutes):
Create your own Oura app (free, instant, no review) at developer.ouraring.com/applications — set the redirect URI to exactly http://localhost:8888/callback
In Claude Desktop: Settings → Extensions → oura-mcp → Configure → paste the app's Client ID and Client Secret (the secret is stored in your OS keychain)
Ask Claude a health question — your browser opens the Oura consent page. Approve, ask again, and you're looking at your own data. Tokens stay on your machine (~/.oura-mcp/, chmod 600).
Prefer a config-file setup, or using a different stdio client? The docker route works everywhere:
{
"mcpServers": {
"oura": {
"command": "docker",
"args": ["run", "-i", "--rm", "ghcr.io/rajskij/oura-mcp:latest", "node", "dist/src/stdio.js"]
}
}
}Ask Claude "how did I sleep this week?" — you'll get answers from Oura's sandbox data, which is exactly how the real thing behaves.
Register an OAuth app at developer.ouraring.com/applications (redirect URI http://localhost:8888/callback) and put the credentials in an .env file next to a copy of docker-compose.yml
One-time browser consent, saves tokens to ./data: docker compose --profile setup up get-token
Point the same config at your credentials and tokens:
{
"mcpServers": {
"oura": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"--env-file", "/absolute/path/to/.env",
"-v", "/absolute/path/to/data:/app/data",
"ghcr.io/rajskij/oura-mcp:latest",
"node", "dist/src/stdio.js"
]
}
}
}Running from source instead of Docker: npm install && npm run build, then use "command": "node", "args": ["/path/to/oura-mcp/dist/src/stdio.js"] (with cwd at the repo so data/tokens.json resolves).
# 1. Register an OAuth app at developer.ouraring.com/applications
# Redirect URI: http://localhost:8888/callback
# 2. Configure
curl -O https://raw.githubusercontent.com/Rajskij/oura-mcp/main/docker-compose.yml
curl -o .env https://raw.githubusercontent.com/Rajskij/oura-mcp/main/.env.example
# fill in .env: client id/secret, generate MCP_PATH_SECRET (openssl rand -hex 24)
# 3. Connect an Oura account (one-time browser consent on this machine)
docker compose --profile setup up get-token
# 4. Run
docker compose up -dKeep PORT=3000 in .env (or adjust the compose port mapping to match).
Needs Node 22+.
# 1. Register an OAuth app at developer.ouraring.com/applications
# Redirect URI: http://localhost:8888/callback
# 2. Configure
cp .env.example .env # fill in client id/secret, generate MCP_PATH_SECRET
# 3. Connect an Oura account (one-time browser consent)
npm install
npm run get-token
# 4. Run
npm run devWant to hack on it without a ring? OURA_SANDBOX=1 npm run dev serves Oura's sandbox data, no account needed.
Your MCP endpoint is https://your-host/mcp/<MCP_PATH_SECRET>.
Settings → Apps → Advanced settings → enable Developer mode
Settings → Apps → Create: name it, paste your MCP endpoint URL, auth = No auth
In a conversation, open the + menu → Developer mode → enable the app
Set up on desktop web; the app then works in mobile conversations too.
Settings → Connectors → Add custom connector
Paste your MCP endpoint URL → Add
Claude connects from Anthropic's cloud, so the server must be publicly reachable (no localhost).
Clients that only speak stdio can use the mcp-remote bridge:
{
"mcpServers": {
"oura": {
"command": "npx",
"args": ["mcp-remote", "https://your-host/mcp/<MCP_PATH_SECRET>"]
}
}
}Variable | Required | Purpose |
| yes | Your Oura app's client id |
| yes | Your Oura app's client secret |
| yes | Long random URL path segment ( |
| no | HTTP port, default 3000 |
| no |
|
403 from every tool — no active Oura subscription on the connected account. The API requires one.
401 / "token expired, needs a reconnect" — the stored refresh token was lost or invalidated (Oura rotates it on every refresh; never run two copies of the server against the same data/tokens.json). Re-run get-token.
404 when connecting — the path secret in the URL doesn't match MCP_PATH_SECRET. Copy the full endpoint URL again.
ChatGPT: "Error creating connector" / timeouts — your host is asleep. ChatGPT aborts on cold starts (~60 s budget); use an always-on host.
resilience / vo2_max come back empty — Oura computes these after ~2 weeks of wear / a fitness test; the tools work, the account has no data yet.
OAuth tokens never leave your server; the MCP client only sees tool results.
Read-only scopes; the Oura API has no write endpoints for health data, and neither does this server.
Your email is never returned by any tool.
The optional usage log records tool names and timings only, never health values.
Prompt injection: treat health conversations as sensitive. If a chat mixes this connector with untrusted content (web browsing, pasted documents), a malicious page can try to steer the model into calling tools and echoing your data into a reply it controls. The blast radius here is bounded — read-only tools, your own data — but the cleanest habit is simple: ask health questions in chats that aren't also browsing the web.
Self-hosted and single-user by design: your data flows directly between your server and Oura, which is also what Oura's API terms expect from personal integrations. It runs my household's ring today.
Coming next: a one-click Claude Desktop extension (.mcpb) and a free-tier Cloudflare Workers deploy button — same server, no VM needed. Open an issue if you want one of these sooner.
Daily activity: score (0-100), steps, active and total calories. response_format 'detailed' adds minutes by intensity (high/medium/low), sedentary and resting minutes, walking distance. Use for "how many steps", "how active was I", "did I move enough". Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. | |
| response_format | No | Verbosity. 'concise' (default) returns the key numbers; 'detailed' adds full breakdowns. Use 'concise' unless the user asks for specifics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds context about default date ranges and response format behavior, but does not disclose any additional behavioral traits like 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it starts with the core data returned, then explains the detailed format, and ends with example use cases. It is concise without being terse, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return values for both 'concise' and 'detailed' formats. It also mentions the default time range and provides use case examples, making it complete for an activity summary tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by recommending 'concise' as default for response_format, and clarifying the default date ranges beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns daily activity data including score, steps, calories, and optionally detailed breakdowns by intensity. It distinguishes itself from sibling tools by listing specific fields and example queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides example queries like 'how many steps', 'how active was I', which clarifies when to use this tool. It doesn't explicitly state when not to use it, but the sibling context makes it clear that this is for activity data, not heartrate or sleep.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Heart rate aggregated per hour (avg/min/max bpm and sample count) across day and night. Use for "what was my pulse today/this afternoon". For sleep-time heart rate prefer oura_get_sleep_detail. Range is capped at 3 days; defaults to the last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| end_datetime | No | Range end, ISO 8601. Default: now. | |
| start_datetime | No | Range start, ISO 8601 (e.g. 2026-07-02T00:00:00Z). Default: 24 hours ago. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so description doesn't need to restate. It adds valuable behavioral details: aggregation per hour, included metrics (avg/min/max bpm, sample count), and range limits (3-day cap). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the purpose and output, the second gives usage guidance and alternatives. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with two simple parameters and no output schema, the description adequately covers what is returned, the time range behavior, and when to use alternative tools. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value by stating the 3-day range cap (not in schema) and reinforcing defaults. However, it does not add new semantics beyond what schema already provides for the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns heart rate aggregated per hour with avg/min/max bpm and sample count. It specifies the scope (across day and night) and distinguishes from sibling oura_get_sleep_detail for sleep-time heart rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use for 'what was my pulse today/this afternoon' and advises to prefer oura_get_sleep_detail for sleep-time heart rate. Also notes the range is capped at 3 days and defaults to the last 24 hours.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
User profile (age, biological sex, height in meters, weight in kg) plus ring info: model, size, firmware and current battery level. Use for "how charged is my ring", "what does Oura know about me". Email is never returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds value by specifying that email is never returned, clarifying data safety and privacy behavior beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. Front-loads key output fields and examples. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description fully covers what is returned, including specific fields and a privacy note. Complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (empty schema). Baseline for 0 parameters is 4, and description correctly adds no param info as none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns user profile (age, biological sex, height, weight) and ring info (model, size, firmware, battery level). Explicitly excludes email. Distinguishes from sibling tools which focus on other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides example use cases like 'how charged is my ring' and 'what does Oura know about me', indicating when to use. Does not explicitly state when not to use or compare to siblings, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily readiness scores (0-100) showing how recovered the body is, with contributors (HRV balance, resting heart rate, sleep balance, body temperature) and temperature deviation in °C. Use for "how recovered am I", "should I train today", "is my temperature elevated". Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds behavioral details like temperature deviation in °C, which is valuable. No contradictions or misleading statements. Could be improved by disclosing how contributors are derived, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The first sentence conveys the core purpose, the second gives usage context, and the third states defaults. Structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description explains the return values: a 0-100 score, contributors (HRV balance, etc.), and temperature deviation in °C. This is adequate for an agent to understand what to expect. Minor gap: no mention of potential missing data or pagination, but acceptable for a simple daily metric tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both start_date and end_date already described. The description only adds the default behavior ('Defaults to the last 7 days'), which is useful but does not significantly enhance parameter understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'daily readiness scores (0-100)' and lists contributors, using a specific verb ('showing') and resource ('readiness scores'). It distinguishes from sibling tools like oura_get_activity and oura_get_heartrate by focusing on readiness. The scope ('last 7 days' default) is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use this tool with example queries ('how recovered am I', 'should I train today', 'is my temperature elevated'), providing clear context. However, it does not explicitly mention when not to use or suggest alternatives among siblings, slightly lowering the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily sleep scores (0-100) with contributor scores (deep sleep, REM, latency, timing, etc.). Use for "how did I sleep" questions. For bedtimes, sleep stages in minutes, or night heart rate use oura_get_sleep_detail instead. Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=true; description adds default date range of last 7 days and score range 0-100, providing additional behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states what it does, second gives usage guidance. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 self-documenting parameters, read-only annotation, and clear sibling differentiation, the description covers all needed context for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% so parameters are well-documented; description adds default values (start_date defaults to 7 days ago, end_date to today) which are not in schema, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States daily sleep scores (0-100) with contributor scores, and clearly distinguishes from sibling tool oura_get_sleep_detail by specifying what the latter covers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for "how did I sleep" questions' and provides exclusion: 'For bedtimes, sleep stages in minutes, or night heart rate use oura_get_sleep_detail instead.' Names alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-night sleep sessions: bed and wake times, sleep stages in minutes (deep/REM/light/awake), latency, efficiency, night heart rate, HRV and breathing rate. Also returns bedtime recommendations when Oura has them. Use for "when did I fall asleep", "how much deep sleep", "what was my pulse at night". Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. | |
| response_format | No | Verbosity. 'concise' (default) returns the key numbers; 'detailed' adds full breakdowns. Use 'concise' unless the user asks for specifics. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds behavioral details: default date range (last 7 days), inclusion of bedtime recommendations when available, and specifics on heart rate and HRV. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first enumerates returned data types, second provides usage examples and defaults. No filler; every sentence adds value. Front-loaded with key content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional parameters, no output schema, and read-only annotation, the description sufficiently covers expected output (sleep stages, heart rate, etc.), default behavior, and typical queries. It is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions date range defaults but does not add new semantic info beyond what the schema descriptions provide (e.g., no mention of response_format). Thus, it meets but does not exceed baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Per-night sleep sessions' with specific metrics (bed/wake times, sleep stages, heart rate, etc.), which distinguishes it from sibling tools like 'oura_get_sleep' (likely a summary). It also provides example queries like 'when did I fall asleep', grounding its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases ('Use for "when did I fall asleep"...') and mentions the default scope (last 7 days). However, it does not exclude scenarios where sibling tools should be used instead, such as when only aggregate sleep scores are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily stress summary: minutes of high stress, minutes of high recovery, and a day verdict (e.g. 'restored', 'normal', 'stressful'). Use for "how stressed was I", "did I recover today". Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation: it specifies default date range and the exact output fields (minutes, verdict). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information. Every word adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with 2 parameters and no output schema, the description fully explains what is returned and default behavior. Sibling tools provide context for differentiation, but the description is self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have descriptions in the schema (100% coverage). The description reiterates defaults but does not add significant new meaning beyond stating 'last 7 days'. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' (implied by tool name) and resource 'daily stress summary', detailing the specific metrics (minutes of high stress, recovery, verdict). It differentiates from sibling tools like oura_get_activity by specifying stress-specific output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides use cases ('how stressed was I', 'did I recover today') and default behavior (last 7 days). Does not explicitly state when not to use or mention alternatives, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tags the user logged in the Oura app: caffeine, alcohol, sickness, medication, custom notes, etc. Useful context when explaining why sleep or readiness changed. Read-only: tags can only be created in the Oura app. Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. The description reinforces this with 'Read-only: tags can only be created in the Oura app.' It also adds the default time range (last 7 days) and explains the nature of tags (user-logged entries), providing context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous words. First sentence introduces the tool's purpose and examples, second adds usage guidance and default. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description covers purpose, example content, use case, read-only constraint, and default range. Sibling tools are distinct so no further comparison needed. Everything an agent needs is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for each parameter. The description adds the default behavior 'Defaults to the last 7 days', which complements the schema by specifying the overall range. This adds meaningful context beyond the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Tags' and the resource 'user logged tags in the Oura app'. It lists example tag types (caffeine, alcohol, sickness) and states they provide context for sleep/readiness changes, clearly distinguishing from sibling tools that focus on other specific data metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('useful context when explaining why sleep or readiness changed') and notes that tags are read-only (cannot be created via API). Implicitly guides against creating tags through other tools, but does not explicitly mention when not to use or alternative tools for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Slow-moving health metrics in one call: blood oxygen (SpO2 average % and breathing disturbance index), resilience level (how well the body handles stress long-term), cardiovascular age, and VO2 max. Use for "what is my SpO2 / vascular age / VO2 max / resilience". Sections the ring does not measure come back empty. Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by noting that sections the ring does not measure return empty, and that data defaults to the last 7 days. This provides behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous words. Every sentence provides essential information: what the tool returns, its use case, handling of missing data, and default range.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the key return fields (SpO2, resilience, etc.) and mentions empty sections. It covers the tool's scope adequately, though a brief note on response format would be nice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described with dates and defaults). The description adds that it defaults to 'last 7 days', which supplements the schema's default values and clarifies behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'slow-moving health metrics' like SpO2, resilience, cardiovascular age, VO2 max. It distinguishes from siblings by specifying these exact metrics, which are absent in other Oura tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for what is my SpO2 / vascular age / VO2 max / resilience', which tells the agent when to invoke this tool. While it does not provide explicit when-not scenarios, it implies that other tools (e.g., oura_get_heartrate) are for different metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Workouts (activity type, intensity, calories, distance, start/end times) plus mind-body sessions (meditation, breathing, relaxation). Use for "how was my run", "did I work out", "did I meditate". Defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | Last day, YYYY-MM-DD. Default: today. | |
| start_date | No | First day, YYYY-MM-DD. Default: 7 days ago. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context about the data returned (activity type, intensity, etc.), which is consistent and helpful. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. Could be slightly more compact, but it is efficient and front-loaded with key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description lists returned fields (activity type, intensity, etc.) and default date range, covering the essential information for a simple read tool with two optional params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are fully documented. The description adds default behavior (last 7 days) which is already implied by the schema defaults, providing minimal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves workouts and mind-body sessions, with specific examples like 'how was my run' and 'did I meditate'. It distinguishes from siblings like oura_get_activity by explicitly covering both workouts and sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides sample queries ('use for...') and default time range, but does not explicitly state when to avoid this tool or mention alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0oura_get_activityoura_get_heartrateoura_get_profileoura_get_readinessoura_get_sleepoura_get_sleep_detailoura_get_stressoura_get_tagsoura_get_vitalsoura_get_workoutsEach tool targets a distinct health metric (activity, heartrate, profile, readiness, sleep, sleep detail, stress, tags, vitals, workouts) with clear usage instructions, eliminating ambiguity.
All tools follow the consistent pattern 'oura_get_<noun>', using lowercase with underscores, making them predictable and easy to remember.
With 10 tools covering the main Oura features, the count is well-scoped for a health data API, not overwhelming nor insufficient.
The set covers all major Oura data types (activity, sleep, readiness, heartrate, stress, vitals, tags, workouts, profile), leaving no obvious gaps for typical health queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Connect your Oura Ring account securely in minutes. Enable authorized access to your sleep, activi…
Garmin data in Claude & ChatGPT via the Garmin Health API. OAuth sign-in, no password sharing.
63 tools for Apple Health, Fitbit, Oura & Health Connect data in Claude, ChatGPT, Grok & Mistral.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Rajskij/oura-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
