io.github.proscar87/oura-mcp

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.

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.

Is the difference between two periods larger than this metric's own noise? THE ONE CALCULATION THIS SERVER MAKES, and it comes with its method. «Your HRV is up 12%» is a number without one: daily metrics swing on their own, and a good night tends to follow a good night, so a textbook comparison calls noise a change about a third of the time. This one measures how much the metric moves on its own from the person's preceding 120 days, and answers `within_noise`, `outside_noise`, or `cannot_tell` when it has too little to know. «within noise» is not «no change»: with those days, a real change smaller than `noise_band` is missed more often than seen. Today is left out — it is still accumulating. It says whether the level differs, never why.

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.

Do the day-to-day changes of two metrics move together, beyond chance? The second calculation this server makes, held to the same rule as `oura_compare`: the method travels with the number. Two metrics that both rise on weekends, or both drift over months, correlate without touching each other, so each weekday's usual level is removed and only day-to-day changes are compared, with the effective number of pairs corrected for autocorrelation. It answers `outside_noise`, `within_noise`, or `cannot_tell` — usually for anything under about three months. It measures co-movement, not cause and not direction. `first_pair` shows which day of x met which day of y, so a wrong `lag` is visible.

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