Oura MCP server has 9 well-defined read-only tools with mostly complete JSON Schema inputs and reasonable descriptions. All tools have proper naming (verb_noun format: get_*), clear descriptions (150-250 chars typical), and typed parameters with descriptions. However, there are several gaps preventing a higher score: (1) Output schemas are NOT documented, tools return JSON stringified results but the structure is not declared in the tool definition, preventing agents from planning downstream use. (2) No tool uses type enum constraints despite having valid value sets (e.g., days param in get_health_insights could have a range, biological_sex could be an enum). (3) Parameter descriptions lack specificity on valid ranges/formats, 'Start date in YYYY-MM-DD format' is present, but no mention of valid ranges (e.g., 'last 90 days only'). (4) No error handling guidance visible, tools don't document recovery hints (e.g., 'If date range is invalid, try narrower range'). (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all being READ_ONLY. (6) Descriptions are functional but generic, they lack the specificity needed to disambiguate similar tools (e.g., get_sleep_summary vs get_sleep_detailed are both 'Get sleep...', requiring LLM to read parameter details to distinguish). Tool get_personal_info and get_health_insights have minimal schemas (get_personal_info returns empty object properties, get_health_insights has only one optional number param), which is correct but minimal.

• Add outputSchema to every tool definition. Example: get_workouts should declare {type: 'object', properties: {workouts: {type: 'array', items: {type: 'object', properties: {id: {type: 'string'}, start_time: {type: 'string'}, duration: {type: 'number'}, ...}}}, total: {type: 'number'}}}. This enables agents to extract IDs for chaining.
• Add tool annotations: set 'annotations.readOnly = true' in the tool definition for all 9 tools. This is a 2026-07-28 spec pattern that marks tools as safe for unsupervised execution.
• Distinguish get_sleep_summary and get_sleep_detailed in descriptions: 'Returns daily sleep aggregate (total sleep, quality score)' vs 'Returns individual sleep sessions (REM, light, deep phases per session). Use this when you need phase breakdown or detect multiple naps.'
• Add min/max constraints to parameter descriptions. E.g., 'Number of days to analyze (1 - 365, default 7)' for get_health_insights 'days' param. Document Oura API lookback window (likely 90 days for heart_rate, unlimited for older data).
• Add recovery hints to tool descriptions or parameter descriptions. E.g., 'If date range returns no data, the Oura API may only have data for the past 90 days. Try narrowing to recent dates.' This guides agents when calls fail.
• Wrap parameter validation errors with actionable messages. Instead of generic 'Invalid input', return 'start_date must be in YYYY-MM-DD format and not more than 365 days in the past.' The code has validateParams() calls, ensure those throw descriptive AxiosError or similar that the client can parse.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry