Oura MCP server

Server Quality Checklist

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

Latest release: v1.1.0
Disambiguation5/5
Each tool targets a unique Oura data domain (sleep, stress, ring, readiness, etc.) with clear, specific descriptions. The daily_summary tool is explicitly positioned as an overview and directs to more specific tools, avoiding overlap. No two tools appear to serve the same purpose.
Naming Consistency5/5
All tools follow the identical 'oura_' prefix followed by a descriptive snake_case noun or phrase (e.g., oura_sleep_time, oura_heart_rate). The pattern is consistent and predictable, making it easy for an agent to infer the tool's function.
Tool Count4/5
At 18 tools, the set is slightly above the typical 3-15 sweet spot, but it remains well-scoped because each tool corresponds to a distinct Oura data API endpoint. The count reflects the breadth of health metrics Oura tracks, and every tool earns its place without redundancy.
Completeness5/5
The tool set covers all major Oura data categories: sleep, readiness, activity, stress, resilience, heart rate, SpO2, workouts, meditation sessions, tags, rest mode, personal info, ring info, and analytical summaries. There are no obvious gaps in the lifecycle or data access needs, and the daily_summary provides a convenient aggregation.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read operation. The description adds the date parameter default ('defaults to today') and the 'daily' scope, which is useful but does not go beyond what annotations imply. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus an argument list, with the main purpose first. It is front-loaded and avoids fluff. It could be even more compact (e.g., moving the arg spec into the schema), but it is appropriately sized for a simple tool.
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?
The tool is simple (one optional parameter, no required args) and an output schema exists (though not shown). The description covers the purpose and the parameter format/default. It does not mention potential timezone implications or response structure, but given the output schema presence, this is acceptable.
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?
The schema has zero description coverage for the 'date' parameter, so the description carries the full burden. It provides the format (YYYY-MM-DD) and default behavior (defaults to today), which are not present in the schema. This is necessary and helpful for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get daily stress and recovery time for a date.' This is specific and matches the tool name. It does not explicitly differentiate from the many sibling oura_* tools, but the metric (stress and recovery time) is distinct enough for an agent to infer its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many siblings (oura_readiness, oura_resilience, oura_daily_summary, etc.). The description only states what it does, not when to prefer it or what alternatives exist. An agent must guess which tool fits based solely on names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond that—it mentions 'contributors' and a default date—but does not disclose any additional behavior such as rate limits, authentication, or data freshness. Since annotations carry the safety burden, a 3 is appropriate; there is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, fully front-loaded with the purpose, and includes only necessary parameter documentation. Every word earns its place—there is no filler or redundant explanation. It achieves high clarity with minimal text.
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?
For a simple read-only tool with one optional parameter and an existing output schema, the description is sufficiently complete. It states the purpose, the parameter format, and the default behavior. It does not explain what the 'contributors' are, but that is likely covered by the output schema. The only minor gap is the lack of explicit mention of the response granularity (per-day), which is implied by the date argument.
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?
The input schema has one optional parameter with a default of null and no description. The tool description explicitly provides the expected format ('YYYY-MM-DD') and the actual default ('today'), which adds meaning the schema lacks. With 0% schema description coverage, the description compensates well by clarifying the parameter's format and semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and a specific resource ('the readiness score and its contributors') for a date. This distinguishes it from sibling tools like oura_sleep or oura_stress, though it does not explicitly name alternatives. The purpose is unambiguous and likely to route an agent correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of when not to use it. The only contextual hint is the default to 'today', which implies typical usage but does not explain scenarios where another Oura tool would be more appropriate. The description does not help the agent decide between readiness and other metric tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description adds minimal extra context, such as that sessions can be guided or unguided, but does not disclose other behavioral traits like pagination, rate limits, or what happens when no sessions exist. Since annotations cover the core, a 3 is appropriate.
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 one clear sentence plus a concise Args block. It fronts the purpose immediately and provides parameter details in a structured way. There is no wasted text; every sentence earns its place.
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?
Given the tool is simple (one parameter, output schema present), the description covers the core usage sufficiently. It explains what sessions are retrieved and the date argument, but does not elaborate on the output structure or potential edge cases. Since the output schema exists, this is acceptable and complete enough for an agent to call correctly.
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?
The input schema for 'date' has no description (coverage 0%). The description compensates by specifying the format 'YYYY-MM-DD' and the default ('defaults to today'). This adds meaningful meaning beyond the schema's type and default, which otherwise would be ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('meditation, breathing and relaxation sessions') for a given date. It is clear and distinct from sibling tools like 'oura_sleep' or 'oura_activity', but it does not explicitly mention alternatives or differentiate itself, which prevents a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any excluded scenarios or compare with sibling tools. Usage is only implied by the tool name and the action of retrieving sessions, but no explicit context or alternative routing is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no behavioral context beyond the purpose: 'for a date' merely reflects the parameter, not additional behavior like return format, pagination, or side effects. With annotations covering safety, the description should still add nuance (e.g., that it returns a single value per date), but it does not.
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 extremely concise: one line for purpose and one line for the argument. The purpose is front-loaded, and there is zero filler. It earns its place by providing the essential format and default for the parameter without redundancy.
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?
Given the tool's simplicity (1 parameter) and that an output schema exists (so return values are documented separately), the description is sufficient. It covers the only parameter and relies on annotations for safety. The only minor gap is not explaining what 'estimated vascular age' or 'pulse wave velocity' mean, but this is likely domain knowledge and not necessary for invocation.
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?
Schema description coverage is 0% for the 'date' parameter, so the description must compensate. It does so by specifying the format 'YYYY-MM-DD' and the default 'today', which are not present in the input schema. This gives the agent clear guidance on how to construct the argument, fully covering the single parameter.
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 explicitly states the action 'Get' and the specific resource 'estimated vascular age and pulse wave velocity', making it clear what the tool returns. The resource is unique among siblings (no other tool mentions cardiovascular age), so it is easily distinguished without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling tools (oura_sleep, oura_stress, etc.). There is no mention of prerequisites, alternative tools, or conditions that would make this the appropriate choice. The only clue is the resource name, which implies it is for cardiovascular data but does not explicitly route the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the default-date behavior and the specific output structure (level + contributors), which are useful context not captured in annotations. However, it does not mention any potential pitfalls (e.g., data availability for past dates) or response limitations, so it stays at an adequate but not rich level.
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 extremely concise: one purpose sentence plus a clearly formatted Args block. It front-loads the core functionality and parameter details with zero redundancy. Every sentence carries essential information, and the structure makes it easy to parse for an agent.
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?
For a tool with one optional date parameter, read-only semantics, and an output schema present, the description is nearly complete. It covers the purpose, the specific data returned (level and contributors), and the parameter format/default. It does not describe error cases or edge scenarios, but given the tool's simplicity and the presence of an output schema, those are not critical gaps.
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?
The only parameter 'date' is undefined in the input schema (coverage 0%). The description compensates by stating the expected format 'YYYY-MM-DD' and the default behavior 'defaults to today', which are essential for correct invocation. It also clarifies that the tool returns data for a single date, aligning the parameter with the purpose. This goes beyond the bare type definition and is sufficient for an optional parameter.
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 states a specific action ('Get the long-term resilience level'), identifies the resource ('for a date'), and enumerates the expected outcome categories (limited/adequate/solid/strong/exceptional) and the components (sleep recovery, daytime recovery, stress). This clearly distinguishes it from siblings like oura_sleep or oura_stress by focusing on a composite resilience metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios where resilience is more appropriate than sleep, stress, or readiness, nor does it reference the sibling tools. The only usage cue is 'for a date', which is generic. The exact trigger conditions are left entirely to the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat safety traits. It adds some behavioral context by specifying 'average nightly' and the default date behavior, but doesn't elaborate on edge cases like missing data or timezone handling. This is adequate given the annotation coverage, but not rich.
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 a single concise sentence stating the purpose, followed by a minimal parameter explanation. It is front-loaded with the core functionality and contains zero redundancy. Every element earns its place.
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?
For a simple one-parameter tool with output schema present, the description adequately covers the essential details: what data is returned and how to specify the date. It doesn't mention finer points like how 'nightly' is defined or timezone handling, but these are minor for a straightforward retrieval tool. The presence of an output schema reduces the burden of describing return values.
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?
Schema description coverage is 0%, so the description must compensate for the 'date' parameter. It does so by providing the format ('YYYY-MM-DD') and the default value ('defaults to today'), which the schema lacks. This adds meaningful semantics beyond the bare schema definition, though it could mention accepted ranges or validation constraints.
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 specific operation ('Get') and the resource ('average nightly blood oxygen (SpO2) percentage for a date'). It uniquely identifies the metric (SpO2) which distinguishes it from all sibling tools that handle other Oura data types, so there is no ambiguity about what this tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any exclusions, conditions, or relationships with sibling tools like oura_sleep or oura_daily_summary. An agent must infer from the metric name alone that this is for blood oxygen data, but no explicit selection guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the default-date behavior but does not disclose additional traits like response granularity or any edge cases. This is acceptable given annotation coverage.
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 compact sentences with no filler. The core purpose is stated immediately, followed by a brief parameter specification. Every element earns its place.
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?
For a simple read-only tool with one optional parameter and an output schema, the description covers the essentials: what data is returned and how to specify the date. The existing output schema handles return value details. It is complete for practical use, though it could mention the scope (e.g., per-day vs. aggregate) explicitly.
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?
The schema provides only the parameter type and default (string/null, default null). The description adds the required format 'YYYY-MM-DD' and clarifies that it defaults to today, which is essential for correct invocation. This meaningfully supplements 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 specifies a clear verb ('Get'), a resource ('daily activity data'), and enumerates the data fields (score, steps, calories, distance, activity time breakdown). It is distinct from sibling tools like oura_sleep or oura_stress, which cover different domains.
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 usage context: when activity data is needed for a date. However, it offers no explicit guidance on when to prefer this tool over siblings such as oura_daily_summary or oura_workouts, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description carries a low burden. The description consistently says 'Get' and does not contradict annotations, but it adds no additional behavioral context (e.g., authentication, rate limits, or what happens if the profile is incomplete). Since annotations cover the core safety profile, a score of 3 is appropriate.
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?
A single, front-loaded sentence that states the action, resource, and fields with zero wasted words. The content is immediately useful to an agent deciding whether to call this tool.
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?
For a zero-parameter tool with an output schema and a clear description of returned fields, nothing is missing. The agent knows exactly what this tool does and what data it retrieves, and the low complexity means the description is fully sufficient.
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?
The tool has zero parameters, and the schema coverage is 100% (no properties). According to the rubric, a 0-parameter tool receives a baseline score of 4. The description appropriately lists the fields returned, which adds value beyond the empty schema by clarifying what the response contains.
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?
States a specific verb ('Get') and resource ('account profile') and enumerates the exact fields returned (age, weight, height, biological sex, email). This clearly distinguishes it from sibling tools like oura_sleep or oura_activity, which focus on specific health metrics rather than the user's profile.
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 does not explicitly state when to use this tool versus alternatives, and no exclusions or alternatives are mentioned. However, the name and content make the intended use obvious (retrieving the user's profile), so usage is implied rather than stated, which meets the baseline for implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to restate safety. It adds context about what rest mode is (relaxes activity goals and readiness contributors), which is semantically useful but doesn't disclose additional behavioral traits such as pagination, rate limits, or response format. Given the annotations, this is adequate.
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 extremely concise—two short sentences plus a parameter line. The main purpose is front-loaded, and the additional clarification about rest mode is valuable without being verbose. No filler or redundancy.
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?
The tool is simple (one optional parameter) and has an output schema, so return-value details are likely covered there. The description provides the necessary context about the parameter format, default behavior, and the meaning of the data. It lacks explicit notes on edge cases (e.g., no rest periods on the date) but these are likely inferable. Slightly more detail could be added, but it's nearly complete.
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?
The schema only lists a 'date' parameter with a default of null and no description. The description adds critical semantics: it specifies the date format (YYYY-MM-DD) and that it defaults to today. Since schema description coverage is 0%, the description fully compensates for the parameter documentation gap.
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 states a specific verb ('Get') and resource ('rest mode periods'), and clarifies what rest mode means (illness/injury/recovery mode). This is distinct from sibling tools like oura_readiness or oura_sleep, and the phrasing makes the tool's scope obvious.
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 usage is implied by the resource name and description—if you need rest mode data, use this tool. However, there is no explicit guidance on when to prefer this over alternatives, nor are any sibling comparisons or exclusions mentioned. The context is clear but not elaborated.
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 cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true), lowering the burden. The description adds useful context beyond annotations by clarifying what data is fetched and the semantic relationship (the score is 'built from' the raw periods). No contradiction with annotations; the read-only framing is consistent.
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 compact and front-loaded, opening with the core purpose before adding the parameter note. Every sentence earns its place, and the Args block is a clean addition rather than repetition.
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?
For a one-parameter read tool with an output schema and safety annotations, the description covers the essentials: what's returned, the date parameter, and default behavior. Minor gaps include no explicit differentiation among overlapping siblings (sleep_time, readiness, daily_summary) and no note on result scope/size, but nothing an agent needs to call correctly is missing.
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?
Despite 0% schema description coverage, the description's Args section fully documents the lone 'date' parameter: its format (YYYY-MM-DD) and its default semantics (null → today). This completely compensates for the bare schema and disambiguates a potential null-means-optional ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed sleep data for a date'), and enumerates exactly what's returned: the daily sleep score, its contributors, and raw sleep periods with duration, stages, heart rate, and HRV. This detailed data listing effectively separates it from siblings like oura_sleep_time and oura_readiness, though it never explicitly names a sibling it is not.
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?
Usage context is only implied through the data-content description — an agent can infer it's for when detailed sleep breakdown is needed. There is no explicit 'use this when' or 'don't use this when' guidance, and no alternative tools are named. This is adequate but leaves routing to inference.
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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral trait of sparsity, informing the agent that results may be absent on certain dates, which is valuable beyond the annotations. It does not elaborate on exact return structure, but the presence of an output schema mitigates that.
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 sentences plus a parameter note, with no wasted words. The core purpose is front-loaded, the sparsity warning is concise, and the parameter details are neatly placed. It is a model of efficiency.
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?
Given a single optional parameter, a clear output schema, and safety annotations, the description covers essential calling context. The sparsity note handles data availability, and the parameter default is explicit. It lacks only a statement about handling empty responses, but the sparsity warning implies that possibility, making it sufficiently complete.
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 0% schema description coverage, the description fully compensates by explaining the `date` parameter's format (YYYY-MM-DD) and default behavior (defaults to today). This adds meaningful semantics beyond the raw schema, making the parameter clear and actionable.
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 states a specific verb ('Get'), a resource ('Oura's recommended bedtime window'), and the comparison with last night's actual bedtime. It clearly distinguishes from sibling tools like oura_sleep, which likely covers broader sleep data, by focusing on the recommendation window.
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 usage for retrieving sleep-time recommendations but does not explicitly state when to use this tool over alternatives like oura_sleep. The sparsity note ('only populated on days Oura had enough history') provides a context cue about data availability, but no explicit routing or exclusion guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by explaining that the tool aggregates both legacy and enhanced tags, including time spans. It does not mention any additional caveats, rate limits, or authentication requirements, but with annotations covering safety and the simplicity of the tool, this is adequate.
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, front-loading the purpose and then detailing the parameter. Every sentence adds value—no fluff, no redundancy. It is concise and well-structured.
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 tool is low-complexity (one optional parameter), has an output schema (so return values are defined there), and the description covers the purpose, scope, and parameter format/default. Nothing an agent needs to invoke it correctly is missing. It is complete for the given context.
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?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. The description fully explains the date parameter, including format (YYYY-MM-DD) and default (today). This entirely compensates for the schema's lack of descriptive text, making the parameter semantics excellent.
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 a specific verb ('Get') and resource ('tags logged for a date'), enumerates what tags are included (built-in and custom, e.g. illness, alcohol, travel, named events), and differentiates itself from siblings by noting it covers both legacy and enhanced tag types. This is precise and unambiguous.
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 usage context (for tags, not other Oura metrics) by naming the resource, and explains the scope (legacy vs enhanced endpoints). However, it does not explicitly mention alternatives or when-not-to-use conditions. Since sibling tools are all other data types, the purpose is clear enough that an agent would know when to call this tool, but no explicit routing 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 read-only and idempotent behavior. The description goes beyond these by warning that data is sparse (computed periodically) and clarifying that a null/default date resolves to today. This adds valuable behavioral context that annotations do not convey, though it does not detail error handling or empty-result behavior, which is mitigated by the presence of an output schema.
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 sentences plus a brief Args section, with no filler. The primary action is front-loaded, the sparse warning is directly relevant, and the parameter explanation is concise. Every sentence earns its place.
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 only one optional parameter, an output schema, and annotations covering safety, the description is complete. It covers the essential behavioral caveat (sparse data) and the default date meaning. Nothing needed for an agent to call the tool correctly is missing.
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?
The input schema has zero description coverage, so the description carries the full burden. It explicitly defines the date format (YYYY-MM-DD) and that it defaults to today, which is not clear from the schema alone (schema shows default null). This fully clarifies the sole parameter's semantics.
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 the estimated VO2 max for a date, using a specific verb and resource. It distinguishes itself from sibling tools like oura_cardiovascular_age or oura_activity by focusing solely on VO2 max, and the sparse-data warning adds specificity to what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool versus alternatives, nor does it provide explicit exclusion conditions. The sparse-data note is about the nature of the data, not about choosing between tools. With 17 sibling tools, some usage guidance would be helpful, but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds nothing beyond that—it does not mention data granularity, rate limits, or any behavioral constraints. Given the strong annotation coverage, this is acceptable but adds no extra value.
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: a purpose statement plus a use case, followed by parameter documentation. The critical information is front-loaded, and every sentence earns its place. No redundancy or fluff.
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?
The description covers the tool's purpose, use case, and both parameters. An output schema exists (as indicated by context signals), so return-value details are managed by that schema. The only minor gap is the lack of any mention of time range constraints or data resolution, but these are not critical for basic invocation.
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?
Schema description coverage is 0%, so the schema provides only types and titles. The description fully compensates by documenting both parameters with ISO 8601 format and concrete examples for start_datetime and end_datetime. This allows an agent to construct valid datetime strings without ambiguity.
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 states 'Get continuous heart rate samples for a time window,' which precisely identifies the verb (get), resource (continuous heart rate samples), and scope (time window). This clearly distinguishes it from sibling tools like oura_sleep or oura_activity, which cover different physiological domains.
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 provides a concrete use case ('correlating with untracked activity or workouts'), giving context on when this tool is appropriate. It does not explicitly mention alternatives or when not to use it, but the use case implicitly guides selection.
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, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful context beyond that: it states the tool returns specific data types (heart rate, calories, duration, intensity), that it includes auto-detected and manually logged entries, and that the date parameter defaults to today. This enriches the agent's understanding of what to expect.
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 extremely concise: two sentences, with the main purpose front-loaded and the parameter explanation following. There is no extraneous information, and every word earns its place.
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?
For a simple read-only tool with one optional parameter and an existing output schema, this description is complete. It specifies the date format and default, and the output schema presumably covers the return values. There is nothing an agent needs to know to call this tool correctly that is missing.
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?
The schema has no descriptions (0% coverage), so the description carries the full burden. The single parameter 'date' is explained with format (YYYY-MM-DD) and default behavior (defaults to today). This fully compensates for the missing schema description and leaves no ambiguity about how to use the parameter.
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 a specific verb ('Get') and resource ('workouts'), and further specifies that it covers both auto-detected and manually logged workouts, along with the data fields returned (heart rate, calories, duration, intensity). This is distinct from the sibling tools like oura_sleep or oura_activity, so an agent can immediately recognize its purpose.
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 does not explicitly mention when to use this tool versus alternatives, nor does it give any exclusions or prerequisites. However, the name and content make it obvious that this is the tool for workout data, so the usage is implied rather than spelled out. There is no misleading guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only that it is an 'overview', which is more about scope than behavior, and does not disclose additional side effects, permissions, or rate limits. With annotations covering the safety dimension, a 3 is appropriate.
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 concise (three sentences plus a parameter list) and front-loaded with the key purpose. The usage guidance follows immediately, then the parameter detail. Every sentence contributes value with no redundancy or filler.
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 that an output schema exists and the parameter is well-documented in the description, everything an agent needs to correctly call and interpret the result is present. The description covers what data is returned, when to use it, and the parameter semantics. Complete for a one-call overview tool.
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?
Schema description coverage is 0%, but the description fully compensates by specifying the format ('YYYY-MM-DD') and default ('defaults to today') for the date parameter. This adds meaning well beyond the bare schema type and default null, making the parameter usage clear.
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 a specific verb ('Get') and resource ('a one-call overview') and enumerates the data it returns (sleep score, raw sleep periods, readiness score, daily activity). It also explicitly distinguishes itself from more specific sibling tools by framing itself as an overview, making its purpose unambiguous.
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?
Provides explicit usage guidance: 'Use the more specific tools for fields not covered here.' This tells the agent when to use this tool versus alternatives, which is exactly the kind of routing information needed. No exclusions or caveats are missing.
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 define readOnlyHint, idempotentHint, and destructiveHint as safe. The description adds that the tool returns all rings and battery readings, and specifies the datetime defaults. It does not contradict annotations and provides useful output details beyond what annotations cover, such as the exact fields returned.
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 crisp lines: a one-sentence overview and a brief 'Args' list. No filler or redundancy. The core purpose is front-loaded, and the parameter details are clear and minimal, following standard docstring structure.
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?
For a read-only, idempotent tool with no required parameters and an output schema (not shown but present), the description covers the essential purpose and parameter behavior. It explains the purpose, time window defaults, and what data is returned. An agent can call it correctly without additional information.
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?
Schema descriptions cover 0% of parameters, so the description must fully explain them. It does so by defining both start_datetime and end_datetime as ISO 8601 with defaults (24 hours ago and now). This gives agents everything needed to construct valid arguments, compensating entirely for the missing schema descriptions.
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 ring hardware details (model, color, size, firmware) and battery readings for a time window. The specific verb 'Get' and resource 'every ring ever paired' make it unambiguous and distinct from siblings like oura_sleep or oura_activity, which focus on health metrics.
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 implies usage context: when you need ring hardware info or battery data. It provides defaults for the time window, which indicates usage. However, it does not explicitly mention alternatives or when not to use it. Since the tool is uniquely about the ring itself, usage is easily inferred, but a direct comparison to siblings would elevate it to 5.
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, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat safety. It adds the behavioral detail that results are ordered 'most recent last' and that the default lookback is 7 days, which is valuable beyond the structured data.
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 sentences with no fluff. The core purpose is front-loaded, and the parameter is explained immediately after. Every word adds value, and it's appropriately sized for a single-parameter read-only tool.
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's simple interface (one optional integer parameter) and the presence of an output schema (which covers return structure), the description covers all necessary aspects: purpose, parameter semantics, default behavior, and result ordering. There are no missing execution details.
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?
Schema coverage is 0%, so the description fully carries the parameter burden. It explicitly explains 'days' as 'Number of days to look back, including today' and documents the default (7), which the schema only provides as a bare integer. There is only one parameter, and this is complete.
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 action ('Get') and the resource (daily sleep, readiness, activity and stress scores) and specifies the temporal scope ('over a range of days'). It differentiates from siblings by covering multiple metrics at once, unlike single-metric tools like oura_sleep or oura_activity.
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 implies the use case: retrieving a trend of multiple daily scores over a period. It gives clear context but does not explicitly mention when not to use it or list alternative tools. However, the contrast with sibling names (e.g., oura_sleep, oura_stress) makes the intended usage reasonably obvious.
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 MCP server](https://glama.ai/mcp/servers/rollecode/oura-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rollecode/oura-mcp)

Score Badge

Copy to your README.md:

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

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/rollecode/oura-mcp'

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