oura-mcp
This server provides read-only access to all 19 Oura Ring v2 API collections via MCP, with three tools:
oura_collections: List all 19 collections, their descriptions, and accepted parameters.oura_query: Fetch data from any collection with inclusive date ranges (or a single day), field filtering, JSON/CSV output, and automatic pagination to retrieve the full dataset. It corrects Oura's inconsistentend_datehandling and reports issues like ignored fields, rate limits, or synthetic data. Supportslatest=trueforheartrateandring_battery_level.oura_check: Verify credentials and API connectivity without exposing tokens (only token length and scopes shown).
Available collections include daily summaries (sleep, readiness, activity, etc.), detailed records (sleep_time, workout, session, etc.), high-resolution streams (heartrate, ring_battery_level), and profile info (personal_info, ring_configuration).
The server does not analyze data—it returns raw results as-is.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@oura-mcpShow me my sleep data for the last 7 days"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
oura-mcp
English | 简体中文 | 한국어 | Español
The Oura v2 API as an MCP server. All 19 collections, four tools, no dependencies beyond the MCP SDK.
One local day of heart rate is 1,231 samples across 2 pages
A client that doesn't follow Oura's next_token returns 1,000 of them — 81%,
looking complete, with nothing saying otherwise. Measured against the real API
on 9 August 2026, one person, one ring, 24 hours.
The test to apply to any Oura MCP server, including this one: does it take
next_token — or a cursor, or a limit — as a tool parameter? If it does,
pagination is the model's job, and a model that forgets to ask again produces a
confident answer off partial data. This server paginates to exhaustion before it
returns, and tells you how many pages it took.
That's one of four ways Oura under-delivers without saying so. All four are measured below, and all four are corrected here.
Install
Download oura-mcp.mcpb from the
latest release and
double-click it. Claude Desktop does the rest — no terminal, no Python, no Node.
It runs on Oura's official sample data out of the box, and every sample response
says so, so nothing can pass for your own sleep.
Prefer the command line? uvx --from mcp-oura oura-mcp.
Prefer no Python on your machine at all?
docker run -i --rm -e OURA_SANDBOX=1 ghcr.io/proscar87/oura-mcp-i is not optional: an MCP server speaks over stdin and stdout, not over a
port. Without it the container has no stdin, the handshake never arrives, and
the client reports a server that doesn't show up.
The problem, measured
Oura does not return errors when it can't give you what you asked for. It returns something different, shaped like a correct response. These are the four we found by measuring against the real API on 9 August 2026:
1. Skip the pagination and you get a fraction
{ "data": [ ... ], "next_token": "eyJ0eXAiOi..." }If next_token comes back and you don't follow it, you receive the first page
and nothing warns you. One local day of heartrate — one person, one ring,
24 hours — is 1,231 samples across 2 pages. A client that doesn't paginate
gets 1,000 of 1,231: 81%, looking complete. A month is ~37,000.
2. Asking for a single day returned zero records
end_date does not behave the same across collections:
Exclude the last day requested | Include it |
|
|
And on top of that, workout filters by UTC date while reporting day in
local time: at -06:00, asking for July 16–18 returned records from the 15th
and 16th — before the requested start.
Here the range is inclusive on both ends, always. Two extra days are requested on each side and then trimmed, which is correct whichever way a given collection behaves — and stays correct when Oura changes it.
3. latest=true is ignored where it doesn't apply
Only heartrate and ring_battery_level honor it. In the other seventeen Oura
doesn't error: it returns the entire collection. You ask for the latest
record, you get ten, and you believe it's one. Here it's rejected before the
request goes out.
4. A field that doesn't exist is silently ignored
fields=does_not_exist returns the complete record — the projection never
happens — and fields=score,does_not_exist applies the good one and drops the
bad one without a word. Here, fields that never appeared are reported under
ignored_fields.
The pattern is always the same: you ask for one thing, you get another, and nothing warns you. That's why this package would rather shout than quietly under-deliver.
Related MCP server: oura-mcp-server-enhanced
Installation
Try it with no credentials
pip install mcp-oura
OURA_SANDBOX=1 oura-mcp --checkThe sandbox is official — it's in Oura's OpenAPI spec, with 34 mirror routes —
and serves synthetic data without authentication. 18 of the 19 collections work
there: personal_info doesn't, which makes sense, since it's the one returning
email, age, weight and height.
This is the right order: first you watch the server work and learn the shape of the data, then you go get credentials.
With your own data
Oura stopped issuing Personal Access Tokens in December 2025. Existing ones still work; new ones can't be created. So there are two paths:
a) OAuth2 — the one that works today. Register an application at
cloud.ouraring.com/oauth/applications
with the redirect http://localhost:9876/callback/ — the trailing slash is
required, the portal rejects the other form with invalid_redirect_uri.
If you registered on
developer.ouraring.cominstead, your app belongs to Oura's newer portal, whose token endpoint is a different one. The legacy endpoint rejects those apps on every refresh — so the registration works exactly once, until the first access token expires, and then fails forever with nothing explaining why. This server tries the legacy endpoint and falls back to the new one automatically; nothing to configure either way.
export OURA_CLIENT_ID="…"
export OURA_CLIENT_SECRET="…"
oura-mcp --authorize # opens the browser, waits for the callback
oura-mcp --authorize --manual # headless machines: you paste the URL backThe token is stored in ~/.config/oura-mcp/credenciales.json with mode 600 — or
in the system keychain if you happen to have keyring installed, which is not a
dependency of this package — and refreshes itself. oura-mcp --forget erases
it.
b) A personal token, if you already had one.
export OURA_PAT="your-token"
oura-mcp --check--check is the self-check: it reports which credential you're using, which
scopes were granted and how long the access has left, without returning the
token or a single health value. It reports the token's length, never the
token. Error messages get copied and pasted into chats and issues; they have no
business carrying anything else.
Connecting it to Claude Code
With the package installed (pip install mcp-oura):
claude mcp add -s user oura --env OURA_SANDBOX=1 -- oura-mcpDrop OURA_SANDBOX once you've run oura-mcp --authorize.
If you use uv, nothing needs to be installed permanently:
claude mcp add -s user oura --env OURA_SANDBOX=1 -- uvx --from mcp-oura oura-mcpThe --from is required because the distribution is named mcp-oura and the
executable oura-mcp. (This needs uv; without it the command above fails
with "command not found", and pip install is the path to take.)
As a Claude Code plugin:
claude plugin marketplace add proscar87/oura-mcp
claude plugin install oura@oura-mcpConnecting it to Claude Desktop
One click: download oura-mcp.mcpb from the
releases page and double-click
it. Claude Desktop installs it — no terminal, no JSON, no Python. It ships with
sample data turned on, so it works before you have any credential at all.
When you want your own data, just ask it for something: it opens Oura's authorization page through Claude, waits for the callback, and retries what you asked. No terminal. That works because MCP has a mode for precisely this — URL elicitation — and the client does the opening.
The one thing Oura still requires is that every application be registered, so you
need a client ID and secret from
cloud.ouraring.com/oauth/applications
once. That's Oura's rule, not this server's. oura-mcp --authorize remains for
terminal users and for clients that can't show a URL.
Or by hand, in ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"oura": {
"command": "/full/path/to/oura-mcp",
"env": { "OURA_SANDBOX": "1" }
}
}
}which oura-mcp gives you the full path. Claude Desktop does not inherit your
terminal's PATH, so a bare name there fails silently — one of the most common
mistakes when configuring an MCP server.
The tools
| All 19, what each one carries and which parameters it takes |
| One collection in full over a range, paginating to the end |
| Last night's sleep and today's readiness, with the days before them |
| Self-check that exposes nothing |
Four, not nineteen. A server with one tool per collection forces the model to pick among 19 similar names before knowing what any of them contain. Here the collection is a parameter and the catalog is consulted when needed.
All four declare themselves read-only, and that isn't a promise: there is no
POST, PUT or DELETE anywhere in the package, and a test reads the source to
keep it that way.
oura_today is the only one that exists for convenience rather than for
correctness: "how did I sleep?" needs today's two records plus enough history
to know whether they are unusual, which was four round trips and four chances
to stop early. It computes nothing — no average, no delta, no "your HRV is
up 12%". The days come back raw and the comparison happens where the method
can be cited. Across nine years of real data, three out of four changes
between consecutive measurements fall inside the metric's own normal swing, so
a percentage without that context manufactures a signal rather than reporting
one. Its one parameter is days, from 1 to 30, defaulting to 7.
oura_query parameters
| Which of the 19. |
| A single day. Shorthand for |
| The range, inclusive on both ends |
| Only these fields. Oura trims on its side, so less comes down |
| The most recent record. |
|
|
And what the response tells you when something didn't come out clean:
truncated with continue_from naming the last day reached, pagination_cycle if Oura
repeats a token, ignored_fields, discarded_out_of_range,
uneven_columns, empty when a query comes back empty, and
large_response when what's returned is heavy enough to matter.
Four more say something happened that you'd otherwise never learn:
synthetic— this is Oura's sample data, not yours. It rides on every response in sample mode, which is how the extension ships, so a model can't report made-up numbers as your sleep.rate_limited— Oura refused with a 429 and a retry got through. The data is complete; the warning is about the next query. Oura sends no rate-limit headers on successful responses, so being refused is the only signal there is that you're near the ceiling.fields_split—fieldsarrived as"day,score"instead of["day","score"]and was split. No Oura field name contains a comma, so splitting is unambiguous — but reinterpreting your input silently would be the same sin this whole package is about.cached— the answer came from this session's memory instead of from Oura. Only ever for a range that closed before today, because a day that has ended cannot gain records; today is never held, since the ring syncs whenever it likes. An empty answer is never held either — nothing tells "no data" apart from "the ring hadn't synced yet", and freezing the second would turn a temporary gap into a permanent one. It lives in memory and dies with the process: no health data is ever written to disk.
That last one comes from measuring: 30 days of daily_activity is 252,000
characters, and 87% of it is a single field, met, a per-minute MET series.
Asking for three columns with fields brings those same 30 days down to 5,000
characters — 99% less. The server doesn't trim on its own — that would be
under-delivering — but it does say what's heavy and how to ask for less.
(Parameter names are stable, documented here, and the tool descriptions the model reads carry the same information. They were Spanish through 0.2.0; the rename to English landed in 0.3.0 and is recorded in the CHANGELOG as a breaking change.)
What this server does NOT do
It doesn't analyze. No correlations, no anomaly detection, no period comparison — which is exactly where other servers place their value.
The reason: an average computed in here reaches the model as a number without its method. Across nine years of real data, three out of four changes between two consecutive measurements fall within the metric's own normal oscillation. A server that hands over "your HRV is up 12%" without saying how much that metric swings on its own isn't informing you: it's manufacturing a signal.
Here you get the data. The analysis belongs where the method can be cited — for instance with cotejo, which draws exactly that distinction for blood biomarkers.
The 19 collections
Daily summaries — daily_sleep, daily_readiness, daily_activity,
daily_stress, daily_spo2, daily_resilience, daily_cardiovascular_age,
vO2_max
The detail the scores hide — sleep (stages, HRV, temperature, latency),
sleep_time, workout, session, rest_mode_period, tag, enhanced_tag
High resolution — heartrate, ring_battery_level
No range — personal_info, ring_configuration
Date-range collections use YYYY-MM-DD. heartrate and ring_battery_level
use ISO 8601 with time.
Other Oura MCP servers
There are several as of August 2026, and it's worth being precise about the
differences. benngermin/oura-mcp
paginates properly, with a resumable cursor.
daveremy/oura-mcp shipped the
end_date fix the same week we did.
davidmosiah/oura-mcp has the most
complete MCP surface. Pagination no longer distinguishes anyone.
What does, as far as we could verify: workout's UTC skew isn't documented in
any of them, nor is rejecting latest where Oura ignores it, nor warning about
fields that were never applied. And none of them treats not analyzing as a
stated position.
Privacy Policy
This section exists because the Claude connectors directory requires one. It is short because there is little to describe: the server runs on your machine and talks to a single service, the Oura API.
What is collected. Nothing, by us. The health data you request goes from the Oura API to your MCP client and passes through no server of ours, because there isn't one.
What is stored, and where. Only your credentials, and only on your machine:
OAuth2 tokens |
|
Personal token | Wherever you put it: |
No health data is written to disk, and that is the constraint the cache was designed around rather than a claim made after the fact. Answers for a day that has already closed are held in memory only, for the life of the process, and --forget clears them. Nothing about your sleep survives the server exiting.
Who it is shared with. No one. The only outbound connection is to
api.ouraring.com, with your token, to fetch what you asked for. Oura's use of
your data is governed by their privacy
policy, not by this one.
How long it is retained. Credentials, until you delete them:
oura-mcp --forget, or by removing the file. Health data isn't retained at all
— it lives in the response and that's it.
Diagnostics expose nothing. oura_check reports the token's length, never
the token; the profile's field names, never their values. The token is wrapped
in a type that won't print even in a stack trace.
Contact. Repository issues.
A note on language
The repository is in English: the code, its comments, the tests, and the
internal documents (AGENTS.md, ROADMAP.md, CHANGELOG.md).
It was written in Spanish through 0.2.0. The tool parameters were renamed in 0.3.0 — a breaking change, recorded as one in the CHANGELOG — and the prose followed. Anything still in Spanish is a storage key that cannot be renamed without orphaning credentials someone already saved, and there is a test saying so by name.
License
MIT.
mcp-name: io.github.proscar87/oura-mcp
Available Tools
4 toolsoura_checkSelf-check of the Oura connectionARead-onlyIdempotent
Self-check: is there a credential, and does Oura respond? Exposing nothing.
Returns neither the token nor any health value. It reports the token's LENGTH, never the token: diagnostic messages are the ones most often copied into chats and issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds crucial safety context beyond the annotations: 'Exposing nothing', 'Returns neither the token nor any health value', and 'It reports the token's LENGTH, never the token'. It also explains the rationale (diagnostic messages may be copied), which is not present in the readOnlyHint/idempotentHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the first sentence stating the core purpose and the second paragraph providing essential security context. Every sentence adds value, and the structure is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool with rich annotations and no output schema, the description fully covers behavioral expectations: what it checks, what it returns (token length), what it never returns, and why. There are no gaps that could lead to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). Per baseline for 0 params, the description doesn't need to explain parameter semantics, and the description adds appropriate context about what it does with the token.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'is there a credential, and does Oura respond?' It identifies a specific diagnostic resource (the Oura connection) and distinguishes itself from sibling tools (oura_collections, oura_query) by focusing on connectivity/credential checking rather than data retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The term 'Self-check' implies usage when you need to verify the connection or diagnose issues, providing clear context. It doesn't explicitly name alternatives or exclusions, but since this is a unique diagnostic tool with no overlapping siblings, explicit when-not-to-use guidance isn't necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
oura_collectionsOura collection catalogARead-onlyIdempotent
The 19 Oura collections, what each one carries and which parameters it takes.
Use it before oura_query if you are unsure of the exact name.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context by specifying the content (19 collections, their contents, and parameters) and the intended purpose as a lookup reference. It does not contradict annotations, though it doesn't detail return format or structure, which is acceptable given the simple read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first establishes the tool's content, the second provides usage guidance. Every word adds value, and the structure is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only catalog with no output schema, the description is sufficiently complete. It states what the tool contains, how many collections, and when to use it. No additional behavioral or return-detail is necessary for the agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description references parameters taken by collections, which is content detail rather than tool parameter semantics. With no parameters to document, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool provides a catalog of the 19 Oura collections, what each carries, and which parameters it takes. It uses a specific verb ('catalog') and resource ('Oura collections'), distinguishing it from the sibling tools 'oura_query' and 'oura_check'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using this tool 'before oura_query if you are unsure of the exact name', giving an actionable use case and a direct reference to the sibling tool. This provides clear guidance on when to consult the catalog versus querying directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
oura_queryQuery an Oura collectionARead-onlyIdempotent
Fetches a COMPLETE Oura collection over the requested range.
Follows pagination to the end: Oura returns next_token and whoever doesn't
chase it receives the first page with nothing saying so. One local day of
heartrate is 1,231 samples across 2 pages; a month, ~37,000.
The range is INCLUSIVE on both ends: equal start and end return that
day. Oura does not behave that way — some collections exclude the last day
and others don't, and workout is skewed to UTC — but that is corrected
here.
Date-range collections use YYYY-MM-DD. heartrate and ring_battery_level
use ISO 8601 with time. personal_info and ring_configuration take no
range.
| Name | Required | Description | Default |
|---|---|---|---|
| day | No | Shorthand for a single day: equivalent to start=end=day. | |
| end | No | YYYY-MM-DD, or ISO 8601 with time | |
| start | No | YYYY-MM-DD, or ISO 8601 with time | |
| fields | No | Only these fields. Oura trims on its side, so less comes down: use it on long heartrate ranges. `day` and `id` always come back. | |
| format | No | `json` (default) or `csv`. CSV for large volumes: a month of heartrate is ~37,000 records and in JSON the keys repeat 37,000 times. | json |
| latest | No | Only the most recent record. heartrate and ring_battery_level only; it needs no range. | |
| collection | Yes | Exact name. See `oura_collections` if you are unsure. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds significant non-obvious behavior: it fully chases pagination while Oura's API doesn't, inclusive range correction differing from Oura's native behavior, collection-specific date formats, and the fact that personal_info/ring_configuration ignore ranges. This is exactly the kind of context that goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact paragraphs with front-loaded core behavior, followed by edge cases and performance guidance. Every sentence carries value—the sample counts justify csv/fields advice, and the pagination warning is critical. No filler, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should help the agent understand return behavior. It covers pagination, inclusiveness, date formats, collection-specific exceptions, and performance. It does not explicitly state the exact JSON envelope or error behavior, but it is otherwise thorough for a moderate-complexity query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all 7 parameters (100%), so the baseline is 3. The description adds meaningful semantics: equal start/end returns that day, heartrate uses ISO 8601 with time while others use YYYY-MM-DD, and example counts (1,231 samples/day) explain why fields and csv are useful. It does not just repeat the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Fetches a COMPLETE Oura collection over the requested range.' It clearly identifies the resource (Oura collection) and differentiates from sibling tools like oura_collections (which lists available collections) by focusing on data retrieval with pagination handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides substantial usage context: when to use csv format for large volumes, when to use the fields parameter for long heartrate ranges, and when latest applies. It also warns about date-format differences and inclusive range semantics. However, it does not explicitly contrast with sibling tools beyond 'see oura_collections if unsure,' lacking explicit when-not-to-use alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
oura_todayLast night and the days before itARead-onlyIdempotent
Last night's sleep and today's readiness, with the days before them.
ONE CALL INSTEAD OF FOUR, and that is the whole of it. «How did I sleep?»
is the most common question there is, and answering it well means today's
two records plus enough history to know whether they are unusual — which
was four round trips through oura_query and four chances to stop early.
IT COMPUTES NOTHING. No average, no delta, no «your HRV is up 12%». The records come back raw and the comparison happens where the method can be cited. That is not an omission: across nine years of real data, three out of four changes between consecutive measurements fall inside the metric's own normal swing, so a server that hands over a percentage without saying how much the metric wanders on its own is manufacturing a signal.
today is very often empty and that is not an error: the ring syncs when
it feels like it, and the current day is the one most likely to be missing.
missing names whichever came back empty, so «no data yet» is never
mistaken for «nothing happened».
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many days of context, ending yesterday. 1-30. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely non-obvious behavior: it computes no averages or deltas and returns raw records, `today` is frequently empty because of ring sync latency, and a `missing` field names which record came back empty. That last point prevents an agent from misreading an empty result as a real signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, but the body is long and rhetorical for a single-parameter read tool – capitalised emphasis, "and that is the whole of it", and a nine-year-data argument about why percentages would be misleading. Some of that is justification rather than operational guidance, and the key caveats (empty `today`, `missing`) are buried at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description ably compensates by explaining what comes back (raw records, no derived metrics) and how to read an empty result via the `missing` field. It is close to complete for a simple read tool, though the shape/fields of the returned records remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (`days`, 1-30, default 7) and schema description coverage is 100%, so the schema already carries the semantics and baseline 3 applies. The description gestures at the history window ("enough history", "the days before them") but adds no syntax or bounds beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening line names the exact resources returned (last night's sleep, today's readiness, plus preceding days) and the description explicitly contrasts itself with `oura_query` – the four round trips it replaces. An agent can distinguish this from oura_check, oura_collections, and oura_query without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the concrete trigger question ("How did I sleep?") and the alternative it supersedes (four calls through `oura_query`), giving a clear selection rule. It stops short of stating when NOT to reach for it (e.g. for non-sleep/readiness metrics, which presumably belong to oura_query).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.3.4- Added
oura_today
1 tool update
v0.3.2- Changed
oura_query1 field changed- changed
Input schema / properties / collection / descriptionPrevious value: -"Nombre exacto. Ver `oura_collections`."New value: +"Exact name. See `oura_collections` if you are unsure."
6 tool updates
v0.3.1- Added
oura_check - Removed
oura_colecciones - Added
oura_collections - Removed
oura_consultar - Added
oura_query - Removed
oura_revisar
3 tool updates
v0.1.1- First observed
oura_colecciones - First observed
oura_consultar - First observed
oura_revisar
TDQS
Scored across 4 tools
Each tool has a distinct role: oura_today is a composite sleep/readiness shortcut, oura_query is the general-purpose collection fetcher, oura_collections is discovery, and oura_check is diagnostics. oura_today partially overlaps with oura_query (which can also fetch sleep/readiness), but the descriptions clearly frame today as a convenience wrapper, so misselection risk is low.
All four tools share a uniform oura_ prefix followed by a single lowercase snake_case word (today, check, collections, query). The convention is applied without deviation, making the set easy to scan and predict.
Four tools is on the lean side but each earns its place: a diagnostic, a discovery catalog, a general query, and a composite shortcut. A generic query tool absorbs most remaining coverage, so nothing feels padded or redundant.
The surface covers the read-only Oura domain well: catalog discovery (oura_collections), generic full-pagination retrieval across all collections (oura_query), a common composite case (oura_today), and credential/connectivity validation (oura_check). No obvious read-path gaps remain for the stated purpose.
Maintenance
Related MCP Connectors
Multi-tenant hosted MCP server for Oura Ring — 21 read-only tools, OAuth per user.
MCP server for Withings health data — sleep, activity, heart, and body metrics.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Query, browse, and automate OmegaAI workspaces from any MCP client. Streamable HTTP with OAuth 2.0.
Related MCP Servers
- AlicenseAqualityCmaintenanceMCP server for the Oura Ring API v2, providing access to sleep, activity, readiness, heart rate, and workout data via OAuth.565 npm1MIT
- AlicenseAqualityCmaintenanceComprehensive MCP server for the Oura Ring API v2, exposing 17 tools to access sleep, activity, heart rate, stress, SpO2, workouts, and user data.171MIT
- AlicenseAqualityAmaintenanceMCP server for the Oura Ring API v2, enabling natural language queries about sleep, readiness, activity, heart rate, and more.267 npm1MIT
- AlicenseAqualityBmaintenanceA read-only MCP server for the WHOOP API v2 that lets you query and analyze your own recovery, sleep, strain, cycles, and workout data. Note: currently a pre-alpha scaffold with stubbed internals.161MIT