Oura MCP

Server Quality Checklist

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

Latest release: v0.7.2
Disambiguation5/5
Each tool targets a distinct data type or action: readiness, SpO2, heart rate, sessions, sleep, tags, workouts, onboarding, profile get, and profile update. No two tools have overlapping purposes.
Naming Consistency5/5
All tools follow a consistent 'oura_verb_noun' pattern using snake_case, with verbs like 'list', 'onboarding', 'profile_get', 'profile_update'. The naming is uniform and predictable.
Tool Count5/5
10 tools is well-scoped for an Oura API wrapper, covering the main data endpoints and additional profile management without being excessive or too sparse.
Completeness5/5
The tool set covers all major Oura data retrieval operations (readiness, SpO2, HR, sleep, sessions, tags, workouts) and includes a complete profile management subsystem with onboarding, get, and update.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on August 29, 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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

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. The description adds no behavioral context beyond this, merely restating scope requirements.
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?
Two sentences, no fluff. Purpose and a key prerequisite are front-loaded. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple read operation given existing annotations and output schema, but it lacks guidance on parameters like privacy_mode and response_format, which affect output behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any of the three parameters. Schema description coverage is 67%, meaning two parameters have descriptions in the schema. The tool description adds no additional meaning to the parameters.
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 it retrieves personal profile fields from Oura, with a specific verb 'Get' and a clear resource. It distinguishes from sibling tools like data retrieval tools, though a similar sibling 'oura_profile_get' exists, causing minor ambiguity.
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 specifies the required 'personal' scope as a prerequisite but provides no explicit guidance on when to use this tool versus alternatives like 'oura_profile_get' or other data 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 the tool read-only, idempotent, and non-destructive, so the bar for additional behavioral disclosure is lower. The description adds useful context about the OAuth scope requirement and the data-availability caveat ('where available'). It does not describe pagination or output shape, though the limit parameter description compensates substantially.
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 top-level description is short and front-loaded with the purpose and content, followed by the auth requirement and a disclaimer. Every sentence earns its place, though 'Not medical advice' is a generic disclaimer that is not directly actionable for tool invocation.
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 definition benefits from a very rich input schema and an output schema, with the limit parameter explaining the hardest behavioral details such as oldest-first ordering and pagination. The description adds the auth prerequisite and availability caveat. The main gap is the lack of an explicit relationship to sibling tools like oura_list_daily_sleep.
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 high at 89%, and the parameter descriptions are unusually detailed, especially the limit and next_token fields, which explain oldest-first ordering, truncated/has_more semantics, and cursor constraints. The top-level description adds no direct parameter meaning beyond what the schema already provides, so it stays at the baseline for high schema coverage.
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 identifies a specific resource ('detailed Oura sleep period records') and a clear action ('List'), and mentions the distinguishing content ('sleep stages and timing where available'). It is clear enough, but it does not explicitly contrast this tool with the sibling oura_list_daily_sleep, so differentiation is implicit rather than stated.
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 gives no guidance on when to use this tool over alternatives such as oura_list_daily_sleep or oura_daily_summary. It states the auth prerequisite ('Requires the daily scope') and includes a disclaimer, but no when-to-use or when-not-to-use context.
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. The description adds context about the local SQLite cache and its enabling conditions, but does not detail what the output contains or error scenarios, which is acceptable given the low complexity.
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, front-loaded with the core purpose, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and enabling conditions, and an output schema exists to define return values. However, it does not explain the parameter or what 'status' means (e.g., enabled/disabled, cache size), leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (response_format) with an enum but no schema description. The tool description does not explain this parameter or its effect, leaving the agent to infer its meaning from the enum values alone. With 0% schema coverage, the description should compensate.
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 'Show optional local SQLite cache status,' which clearly identifies the action (show) and resource (cache status). It distinguishes from sibling tools that mostly retrieve data or manage connections, but could be more specific about what aspects of status are reported.
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 used to check cache status, and mentions enabling conditions, but does not explicitly specify when to use this tool versus alternatives or mention any prerequisites or caveats.
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, destructiveHint. The description adds context on profile contents but does not introduce new behavioral traits beyond the 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 concise with the core action in the first sentence and additional details in subsequent sentences. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and output fields adequately for a read-only tool with annotations, but fails to explain the response_format parameter, limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'response_format' lacks schema description (0% coverage) and is not mentioned in the description. While optional and self-explanatory, the description adds no value for parameter 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 'Read the shared Delx wellness profile' with a verb+resource, lists the contents, and mentions cross-connector availability. It does not explicitly differentiate from the sibling update tool.
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 provides context about cross-connector availability and implies read-only use, but lacks explicit when-to-use vs when-not-to-use guidance or direct alternatives.
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 false, so the safety profile is covered. The description adds a useful auth prerequisite ('Requires daiily scope') and a medical disclaimer, but does not disclose pagination, sorting, or truncation behavior beyond what parameter docs already state. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The action is front-loaded ('List Oura readiness summaries and contributors'), followed by the scope requirement and disclaimer. 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?
For a tool with a rich input schema, output schema, and strong annotations, the description is mostly sufficient. It names the resource and required scope, while the schema and parameter docs handle pagination, privacy modes, and return details. The main gap is lack of tool-selection guidance, but that is a usage_guidelines issue, not a completeness issue.
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 89%, well above the 80% threshold, so the baseline is 3. The top-level description adds no parameter detail; the schema itself thoroughly documents after/before, limit, next_token, privacy_mode, and related parameters.
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 ('List') with a clear resource ('Oura readiness summaries and contributors'), so an agent knows what the tool returns. It does not explicitly distinguish this from sibling list tools like oura_daily_summary or oura_list_daily_activity, but the resource noun is specific enough.
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 only context is a prerequisite ('Requires daily scope') and a disclaimer ('Not medical advice'), with no guidance on when to prefer this tool over alternatives such as oura_daily_summary or oura_list_daily_activity. No exclusions or alternative routing are mentioned.
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 behavioral context beyond annotations: it discloses that the user must have granted daily or sleep data access. It does not mention pagination or privacy nuances, but those are documented in the schema.
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 definition is short and front-loads the main purpose in the first sentence. The access requirement is useful; however, 'Not medical advice.' does little to help selection or invocation and does not earn its place, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has nine parameters, pagination behavior, privacy controls, and many siblings, so a richer description would normally be expected. However, the input schema is very detailed and an output schema exists, which offsets much of the complexity. The main contextual gap is lack of usage differentiation among the many related Oura tools.
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 high (89%), so the schema already explains the parameters in detail. The tool description itself adds no parameter-specific meaning beyond the notion of 'daily sleep score summaries,' which matches the baseline of 3 for schema-heavy tools.
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: 'List daily Oura sleep score summaries.' This is specific enough to indicate the tool's basic purpose, but it does not explicitly distinguish itself from sibling tools like oura_list_sleep or oura_list_daily_readiness, so it falls short of full differentiation.
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 gives an access prerequisite and a medical disclaimer but provides no guidance on when to choose this tool over siblings such as oura_list_sleep, oura_list_daily_readiness, or other Oura data tools. An agent is left to infer the appropriate selection context.
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 annotations (readOnly, idempotent, non-destructive), the description adds that secret values are not revealed, which is critical for privacy audit. It also lists the categories of information 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?
Single sentence, front-loaded with the key action 'Return', and every word adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be described. However, the description omits the optional parameter's effect and doesn't differentiate from sibling tools like oura_cache_status, which may cause confusion. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the response_format parameter but does not. It only describes the tool's output, not the input. The parameter's purpose (choosing output format) is left implicit.
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 returns local privacy, cache, token-path, and env-presence posture, and explicitly says it avoids revealing secret values. This distinguishes it from siblings like oura_cache_status or oura_connection_status.
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. It does not mention prerequisites, exclusions, or context for use. The description is purely declarative.
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, openWorldHint, and destructiveHint. The description adds that the tool normalizes data into a shared shape, which is consistent but does not reveal additional behavioral details beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and target, no unnecessary words. Efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain the shape or structure of the returned wellness context. It also fails to describe how the 6 input parameters influence the output. For a normalization tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), but the description does not explain how parameters like days, notes, soreness, etc., affect the normalization. The description mentions readiness, sleep, and activity load but does not map them to parameters, leaving agents uncertain about their use.
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's function: normalizing Oura readiness, sleep, and activity load into a shared wellness_context shape specifically for recommendation engines. This distinguishes it from sibling tools that provide raw data or other processed views.
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 recommendation engines but does not explicitly state when to use this tool versus siblings like oura_list_daily_activity. No exclusion criteria or alternatives 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 establish readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the auth requirement (workout scope) and that results are summaries, but it does not disclose ordering or pagination behavior in prose; those appear later in parameter descriptions.
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 with no filler. Every word earns its place: the verb-resource statement and the scoping/auth requirement. It is appropriately front-loaded and concise.
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 definition is operationally complete because the schema describes pagination, ordering, privacy, and cursor behaviors, and an output schema exists so return values do not need prose explanation. The main gap is the absence of explicit wanneer-to-use guidance among the many sibling tools, but this does not prevent a knowledgeable agent from selecting it correctly.
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 89% and the individual parameter descriptions are very detailed (oldest-first ordering, cursor semantics, limit truncation, privacy modes). The main description adds no parameter-level meaning, so with high schema coverage the appropriate baseline is 3.
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 starts with a clear verb and resource: 'List Oura workout summaries.' The resource is specific enough to differentiate it from sibling tools like oura_list_sleep and oura_list_daily_activity, and the additional scope requirement narrows 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?
The only usage guidance is the implicit prerequisite 'Requires workout scope.' There is no statement about when to prefer this over sibling list tools, no exclusion criteria, and no mention of alternatives. The agent must infer use from the name.
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, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds useful context about the content it explains (data, privacy, workflow, links), which goes beyond the annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key purpose. Every word is meaningful and there is no 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?
For a meta-capabilities tool, the description covers the main areas (data, privacy, workflow, links). Although it omits the optional parameter, the overall context is adequate given the presence of an output schema (which explains return values). The description could mention usage timing (e.g., start here) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter (response_format) with enum values, but schema description coverage is 0%. The description does not mention this parameter or clarify its purpose (e.g., controlling output format). Since the description fails to compensate for the lack of schema descriptions, the score is low.
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 uses a specific verb ('Explain') and clearly identifies the resource ('supported Oura data, privacy boundaries, recommended agent workflow and project links'). This distinguishes it from sibling tools that focus on specific data endpoints or auth flows.
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 understanding capabilities, but it does not explicitly state when to use this tool versus alternatives (e.g., before calling other tools). No guidance on prerequisites or context 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 readOnly, openWorld, idempotent, and non-destructive, and the description's 'List' verb is consistent with those. The description adds the session-scope auth context, but does not disclose behavior like pagination order, truncation, or privacy overrides—though those are richly covered in parameter descriptions.
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 with no filler. Every word earns its place, and the key resource and scope condition appear immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and a large sibling family, the definition relies heavily on the schema and annotations; the description adds only one sentence. Output schema is present, but an agent would benefit from a sentence on session data vs other resources or on pagiation behavior to be fully self-sufficient.
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 89%, so the input schema carries nearly all parameter meaning; the tool description itself adds no parameter semantics. Baseline 3 is appropriate because the schema does the work and the description does not hinder.
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 ('List'), a precise resource ('guided and unguided Oura app sessions'), and a boundary condition ('when the user granted session scope'). This is enough to distinguish it from sibling list_* tools for sleep, workouts, heartrate, and tags.
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 only usage signal is the auth prerequisite that session scope was granted; it does not explicitly say when to choose this over sibling list tools or when not to use it. No exclusions or alternatives are given, so the agent must infer routing from the resource name.
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, idempotentHint, and non-destructive behavior. The description adds value by stating 'non-medical' (important disclaimer) and 'when available' (indicates data availability may vary). This context beyond annotations justifies a score above 3.
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?
Two sentences front-load the purpose and key constraints ('read-only, non-medical'). No redundant phrases; every word contributes to understanding. Ideal conciseness for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers data sources and safety, it misses explaining the time range (days parameter defaults to 7, but tool is called 'daily summary') and does not mention output format options (schema covers that). With an output schema present, return values are documented elsewhere, but the time range ambiguity reduces completeness.
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 67% (2 of 3 parameters have descriptions in the schema itself), so the baseline is 3. The tool description does not add any parameter-specific meaning beyond the schema's built-in descriptions, so it neither improves nor harms parameter clarity.
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 builds a 'practical daily summary' and lists the specific data sources (readiness, sleep, activity, heart-rate, SpO2) when available. This is a specific verb+resource that distinguishes it from sibling tools like individual listing tools or the weekly summary.
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 a consolidated daily overview but does not explicitly state when to use this tool versus alternatives like oura_weekly_summary or individual data listers. No when-not-to or prerequisite guidance is given, though the context of 'daily summary' provides some direction.
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; description adds valuable context: 'does not call Oura APIs or expose user data', clarifying privacy and safety boundaries.
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?
Two sentences, front-loaded with core purpose, additional boundary information in second sentence. No unnecessary words.
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?
Covers main purpose, safety, and output type (via output schema). Could mention parameter effect, but overall complete for a metadata tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (response_format) is not described in the description. Schema coverage is 0%, and while the parameter is self-explanatory, the description should explicitly state that it controls output format.
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 inventories supported Oura data domains, auth scope requirements, privacy boundary, and recommended first calls. Differentiates from sibling tools that retrieve actual data.
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?
Implies use as a discovery tool before making data calls, but lacks explicit guidance on when to use versus sibling tools like oura_quickstart or oura_capabilities.
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 provide readOnlyHint, idempotentHint, etc. The description adds 'Read-only and non-medical' which reinforces safety and adds non-medical disclaimer. No contradictions; the description provides modest additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads key information (weekly scorecard components, read-only, non-medical). Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description names output components but does not explain the comparison feature (compare_days parameter) or clarify that 'days' can exceed 7, making it not strictly weekly. With output schema present, return values are covered, but missing context about parameter interplay leaves gaps.
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 75% (3 of 4 parameters described). The description does not add meaning beyond what the schema provides, so it meets the baseline expectation without extra value.
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 builds a weekly Oura scorecard with specific components (readiness, sleep, activity, HRV, bottlenecks, actions). It distinguishes from siblings like oura_daily_summary and includes the read-only and non-medical nature, making the 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies weekly use but does not explicitly state when to use this tool vs alternatives like oura_daily_summary or oura_wellness_context. No guidance on when not to use or prerequisites is provided, leaving the agent to infer from the tool name.
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?
The description confirms the tool returns examples (non-destructive, read-only), aligning with annotations (readOnlyHint: true, destructiveHint: false). It adds value by naming the specific payloads returned, beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and usage context without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple schema (1 param, no output schema), the description identifies the returned payloads by name but does not detail the contract's structure or contents. It is adequate but could provide more insight into the example data format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (response_format) with 0% coverage in the description. The description does not mention the parameter or its effect on output, failing to compensate for the lack of schema documentation. The parameter is self-explanatory but should be acknowledged.
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 that the tool returns realistic example payloads of three specific sibling tools, providing a concrete verb (returns) and resource (example payloads). It effectively distinguishes itself from siblings as a demo tool.
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 by stating 'so agents see the contract before calling real Oura APIs', suggesting it should be used as a precursor to real tool calls. However, it does not explicitly exclude alternative uses or specify when not to use it.
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 readOnly=true, idempotent=true, destructive=false. Description adds that it generates a URL, aligning with annotations. Some behavioral context (first step) but doesn't elaborate 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?
Two sentences, front-loaded purpose, no wasted words. Perfectly concise.
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 an OAuth URL generation tool with rich annotations and output schema, the description is sufficient. Lacks explanation of what to do with the URL, but overall adequate.
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?
Input schema covers all three parameters with descriptions. Tool description does not add meaning beyond schema, so baseline score of 3.
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 verb 'Generate' and resource 'Oura OAuth authorization URL', with usage hint. Distinguishes from siblings like oura_exchange_code by implying it's the first step.
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?
Explicitly says 'Use this first when no local token exists', providing clear context. Lacks explicit alternatives or when-not-to-use, but the hint is strong enough.
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?
With strong annotations (readOnly, idempotent, non-destructive), the bar for additional disclosure is lower. The description adds meaningful behavioral context by stating the required auth scope and that records exist only when SpO2 was measured during sleep. This goes beyond the safety profile already conveyed by annotations, though it does not discuss pagination ordering or truncation behavior.
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?
Three short sentences with no filler. The core behavior and scope requirement are front-loaded, and the disclaimer is a single not-infrusive clause. Every sentence earnts its place without duplicating schema content.
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 pagination complexity and rich schema descriptions, the description does not need to repeat cursor or threshold details. It covers purpose, availability conditions, and auth scope, which is enough for an agent to select and invoke it correctly. The only small gap is the lack of explicit guidance on how to route among sibling summary tools.
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?
The input schema already provides comprehensive descriptions for all parameters, including detailed semantics for limit, next_token, all_pages, and privacy mode. The description itself adds no parameter-level meaning beyond the schema, so a baseline score of 3 is appropriate.
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 identifies the operation (list) and the resource (daily Oura SpO2 averages) while adding the context that data is recorded during sleep and only available when present. It doesn't explicitly name or contrast with sibling tools, but the specificity of the resource makes the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It communicates a clear prerequisite (Requires spo2 scope) and a condition for data availability ('when available'), which helps an agent decide to call it for daily SpO2 needs. It does not explicitly describe when not to use it or name alternatives, but the resource ispecificity provides adequate routing context.
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 mark readOnly, idempotent, non-destructive. Description adds the critical fact that it does not call Oura or expose secrets, which is valuable beyond annotations. 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?
Single sentence packs purpose and a key behavioral constraint with zero wasted words. Front-loads essential info.
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 (2 optional enum params, output schema exists), the description provides enough for basic use. Could mention that output is a manifest with install/runtime guidance, but annotations and context signals fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Two parameters with enums but 0% schema coverage. Description says nothing about 'client' or 'response_format' — their meanings, defaults, or how they affect the output. Agents must guess their purpose.
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?
Description clearly states the tool provides machine-readable guidance for AI agents, not actual Oura data. This distinguishes it from siblings like oura_get_personal_info which make API calls.
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?
Explicitly says 'Does not call Oura or expose secrets,' guiding agents to use this when they need manifest info rather than data. Could be improved by noting when to use alternatives, but context signals with many data-retrieval siblings make it clear.
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 flag the call as readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds useful non-obvious behavior: it requires the `heartrate` OAuth scope and warns that data availability depends on ring hardware and membership tier. 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 short and front-loaded with the verb and resource. The first two sentences earn their place; 'Not medical advice' is minor boilerplate but does not meaningfully hurt clarity or structure.
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 read-only list tool with a rich input schema and an output schema, the description covers the selection-critical context: what data it lists, the required scope, and the device/membership caveat. Pagination, privacy mode, and cursors are handled in the parameter descriptions, so nothing blocking correct invocation is missing.
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 89% and the parameter descriptions are unusually detailed, especially for `limit`, `next_token`, and `all_pages`. The tool description itself adds no parameter-level meaning, so the baseline score of 3 applies.
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 ('List') and a specific resource ('Oura heart-rate time-series records'), and adds the availability condition that the ring and membership must expose them. This clearly distinguishes the tool from siblings such as oura_list_daily_sleep or oura_list_workouts by naming the exact data resource.
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 gives clear context: use this tool for hear-rate time-series data when the user's ring/membership expose it and when the `heartrate` OAuth scope is available. It does not explicitly name alternative tools or exclusion conditions, but the resource and precondition are specific enough that an agent can select it correctly.
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 safety profile is covered. The description adds an auth-related detail beyond annotations by noting that tag scope must have been granted. It does not elaborate on pagination or output, but those are handled extensively in parameter descriptions and the output schema, and the operation is a non-destructive read.
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 front-loaded sentence that states the operation, the resource, and the key precondition with no filler or repetition of schema fields.
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 read-only collection tool with rich annotations, nine parameters comprehensively documented in the schema, and an output schema, the one-sentence description is mostly sufficient. It includes the critical scope precondition, though it leaves the exact behavior when tag scope is absent to inference.
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 89%, well above the 80% threshold, so the schema already documents the parameters in detail (e.g., limit ordering, next_token semantics, privacy_mode overrides). The tool description itself adds no parameter-specific meaning, but it is not required to compensate because the schema carries the burden.
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 uses the specific verb 'List' with the resource 'user-entered Oura tags,' which clearly identifies the operation and distinguishes it from sibling list tools targeting other Oura resources (sleep, workouts, heartrate, etc.). The qualifier 'when the user granted tag scope' adds a precise precondition without obscuring the core purpose.
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 clear context for use: this endpoint is appropriate only when the user has granted tag scope. It does not explicitly name alternative tools or state when not to use it, but the resource-specific wording plus the scope condition supplies adequate situational guidance.
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 indicate a mutation (readOnlyHint=false), and the description adds that tokens are stored locally with 0600 permissions and never returned, which goes beyond the structured data. However, it does not disclose error handling or failure modes.
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?
Two sentences no fluff. First sentence states the core action, second provides essential behavioral and usage context. Every word 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's simplicity and the presence of an output schema, the description covers the main behavioral aspects. It could mention idempotency or one-time use, but it is largely complete for typical usage.
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 50% with only the 'code' parameter described. The description does not elaborate on parameters beyond the schema, but the 'code' parameter is clearly implied in the tool's purpose. The 'response_format' enum is simple and self-explanatory.
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 'Exchange an Oura OAuth authorization code for local tokens,' which is a specific verb+resource. It clearly distinguishes this tool from siblings like oura_get_auth_url and oura_revoke_access by focusing on the token exchange step.
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?
The description explicitly states when to use the tool: after the user completes browser OAuth and provides the code. It also warns against inventing codes, providing clear usage boundaries.
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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds valuable behavioral context: it performs local checks without calling Oura and without exposing secrets, which goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key information. Every word serves a purpose, and there is no fluff. It efficiently conveys the scope and constraints.
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 simplicity (diagnostic check), with annotations covering safety, parameters optional with defaults, and an output schema present, the description covers what the tool checks and its constraints. It is complete for the tool's function.
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 0%, so the description does not explain the two optional parameters (client and response_format). However, both parameters have enums and defaults, making them somewhat self-documenting. The tool is simple, so a score of 3 is acceptable as the minimum viable, but the description could add meaning.
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 checks multiple specific local resources (config, token, Node version, privacy mode, cache, MCP client) and distinguishes itself from siblings by explicitly saying it does not call Oura or expose secrets. The verb 'check' and list of resources make the purpose very 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 implies this is a diagnostic/readiness check for local setup, and mentions it doesn't call Oura or expose secrets, which helps the agent know when to use it. However, it does not explicitly compare to sibling tools like oura_cache_status or oura_privacy_audit, so there is some room for improvement.
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?
The annotations already declare read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by calling out start/end date filters and Oura cursor pagination, which implies paged results. It does not contradict any annotation.
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?
Two concise, front-loaded sentences communicate the operation, the resource, and the two core invocation concepts. There is no filler or repetition of schema details.
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 rich input schema, annotations, and output schema handle per-parameter nuance, safety, and return-value shape. The description supplies the essential orientation, so an agent has enough context to select and invoke the tool 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?
With 89% schema description coverage, the schema carries detailed parameter semantics. The description adds a valuable high-level framing by labeling after/before as start/end date filters and by naming cursor pagination as the pagination mechanism, which helps an agent understand the main parameters without restating every detail.
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 opens with a specific verb and resource: 'List daily Oura activity summaries.' It clearly distinguishes this endpoint from sibling tools like oura_list_daily_sleep and oura_list_daily_readiness by naming 'activity' as the domain.
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 usage context: the tool lists daily activity summaries and supports date filtering via after/before and cursor pagination. It does not explicitly name when-not-to-use scenarios or alternative endpoints, so it stops short of a 5.
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?
The description discloses writing to a specific file, the requirement for explicit user intent, and the rejection of secret-shaped fields. It adds significant behavioral context beyond the annotations, which already indicate non-read-only and non-destructive.
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: two sentences plus a bullet list of fields. It is front-loaded with the core action and contains no filler.
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 complexity (3 params, nested objects) and no output schema, the description covers what it stores and rejects. It could mention typical return values, but it's fairly complete for a mutation tool.
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 description adds meaning by explaining the patch parameter is partial and listing allowed keys, and clarifying the explicit_user_intent parameter must be true after user confirmation. With 67% schema coverage, this adds value 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 the tool persists a partial patch to a shared wellness profile file, listing the specific top-level fields it can store. It distinguishes itself from sibling tools like oura_profile_get by focusing on updates.
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 explicitly requires explicit_user_intent=true, indicating when to use the tool. However, it does not directly contrast with alternatives (e.g., oura_profile_get) or specify when not to use it.
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?
The annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that it 'deletes the local token file,' which explains the destructive nature beyond annotations. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both essential. First sentence states the action, second gives usage condition. No wasted words.
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?
With annotations (destructiveHint, openWorldHint) and an output schema (present but not shown), the description covers the core behavior and usage. However, it could briefly mention what the user experiences post-revocation (e.g., disconnection confirmed). Still, it is adequately complete for a simple destructive 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 50%: only explicit_user_intent has a description in the schema. The description reiterates the intent parameter but adds no new detail for response_format, which has an enum and default. The schema's own description for explicit_user_intent is already clear ('Must be true after the user explicitly asked to disconnect'). The description adds marginal value: it repeats the gate requirement but does not explain response_format.
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: 'Revoke the current Oura OAuth grant and delete the local token file.' It specifies the verb (revoke) and the resource (OAuth grant, token file), distinguishing it from related tools like oura_connection_status and oura_get_auth_url.
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?
The description explicitly states when to use: 'Use only when the user explicitly wants to disconnect Oura.' It also notes the gate: 'Gated by explicit_user_intent: true (requires explicit user intent).' This provides clear context and exclusion criteria.
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, idempotentHint, and destructiveHint. The description adds behavioral traits: adapts to current state (env vars, token), which is useful beyond annotations. 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?
Two sentences, no wasted words. Front-loaded with purpose and usage. 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's low complexity (one optional param, clear annotations), the description is fully adequate. No need for output schema or nested objects.
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 coverage is 0% but there's only one optional parameter with an enum and default. The description doesn't add parameter details, but the schema is self-explanatory. Baseline 3 plus a point for simplicity.
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's a personalized 3-step setup walkthrough for connecting Oura, distinguishing it from sibling tools like oura_connection_status or oura_get_auth_url. The verb 'walkthrough' and resource 'setup' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this first when the user asks how do I connect Oura?' providing clear when-to-use guidance. No mention of when not to use, but the context makes it obvious.
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?
Declares read-only behavior, matches annotations (readOnlyHint, idempotentHint, non-destructive), and adds context about subsequent update step. 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?
Three sentences, front-loaded with main purpose, no wasted words. Efficient and 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?
With no output schema, the description clarifies return content (flow + profile state + missing fields) and usage pattern, plus relates to sibling tools. Complete for a read-only onboarding retrieval tool.
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 covers 50% of params with descriptions (locale has description, response_format has default and enum but no description). Description adds that locale can be 'en' or 'pt-BR' and that response_format defaults to markdown, plus context about the flow. Adds value beyond 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?
Clearly states it returns the 11-question wellness onboarding flow plus profile state and missing fields, and distinguishes from sibling tools by noting that all connectors share the same profile and questions.
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 guidance: the agent should ask questions one-by-one, then call oura_profile_update. Also explains when to use this vs other connector onboarding tools.
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/davidmosiah/oura-mcp/badges/card.svg)](https://glama.ai/mcp/servers/davidmosiah/oura-mcp)

Score Badge

Copy to your README.md:

[![oura-mcp MCP server](https://glama.ai/mcp/servers/davidmosiah/oura-mcp/badges/score.svg)](https://glama.ai/mcp/servers/davidmosiah/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/davidmosiah/oura-mcp'

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