Oura MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.2
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.
Average 4.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on July 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![oura-mcp-server MCP server](https://glama.ai/mcp/servers/echocharlie/oura-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/echocharlie/oura-mcp-server)

Score Badge

Copy to your README.md:

[![oura-mcp-server MCP server](https://glama.ai/mcp/servers/echocharlie/oura-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/echocharlie/oura-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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