Related Servers

Multiple tools have unclear boundaries: oura_capabilities, oura_data_inventory, oura_agent_manifest, and oura_quickstart all describe server capability/setup information, while oura_connection_status and oura_privacy_audit both report local config/privacy posture. The near-twin names oura_list_daily_sleep vs oura_list_sleep and oura_get_personal_info vs oura_profile_get are easily confused despite different underlying data.

The consistent oura_ snake_case prefix and the repeated list_ verb for data retrieval tools provide some pattern, but the verb usage is mixed: two get_ tools, one update_/exchange_/revoke_, and a dozen noun-only names (oura_capabilities, oura_demo, oura_onboarding, oura_quickstart). Resource naming is also inconsistent — daily_activity, daily_sleep, daily_readiness, daily_spo2 use the daily_ prefix while sleep, heartrate, workouts, sessions, tags do not, even though they share the same collection semantics.

At 27 tools, the count is too high for the apparent scope. Eight of them (quickstart, connection_status, data_inventory, agent_manifest, capabilities, demo, privacy_audit, cache_status) are meta/setup tools with substantial functional overlap and could be consolidated into two or three. The ten data-domain tools are justified by Oura's API breadth, but the inflated meta cluster pushes the total past reasonable bounds.

The auth lifecycle (get_auth_url, exchange_code, revoke_access), shared profile read/write, and read access to most major Oura domains are well covered, and the daily/weekly summary tools add helpful derived value. However, standard Oura endpoints for daily resilience, daily stress, daily HRV, and tag creation (POST) are missing, so agents answering questions in those domains will hit dead ends with no workaround.