The WHOOP MCP server defines 16 tools with clear names following verb_noun convention (get_*, compare_*, analyze). Descriptions are present for all tools and range from 60-90 characters, meeting the baseline average of 194 chars but on the concise side. All tools declare input schemas with proper JSON Schema typing. However, several critical gaps reduce the score: (1) Parameter descriptions are minimal or missing detail about valid ranges, formats, and constraints; (2) No documented output schemas, LLMs cannot plan downstream calls without knowing what fields are returned; (3) Error handling is not visible in the tool definitions; (4) No tool annotations (readOnlyHint, destructiveHint) despite all tools being READ_ONLY; (5) Some parameter names lack consistency (e.g., 'id' without type suffix in get_cycle_by_id). The server follows basic composition patterns (separate tools for distinct queries, pagination support via limit+nextToken), and all tools accept natural-language time parameters ('today', 'last 7 days'), which aligns with chat-data-model principles. Tool descriptions are functional but lack the LLM-optimization guidance found in A+ baselines.

• Add documented output schemas to all tools. At minimum, include a 'returns' field in the tool definition describing the top-level structure (e.g., 'Returns {profile: {id, name, email, ...}, timestamp: string}'). This enables LLM planning.
• Enhance parameter descriptions with explicit constraints. For limit parameters, state 'limit: 1 - 25 (defaults to 10)' in the description. For metric parameter in get_trend, list valid enums: 'recovery, sleep_duration, strain, hrv, rhr'.
• Add readOnlyHint: true to all 16 tool definitions. Clients will recognize these as safe to cache, parallelize, and retry.
• Rename id parameters in by_id tools for clarity: sleep_id (string), workout_id (string), cycle_id (number). Descriptions should state 'The sleep record ID (string)' to eliminate type confusion.
• Expand by_id tool descriptions from ~50 to 80-120 characters. Include when to use: 'Retrieve a specific sleep record by its ID. Use this when you already know the ID; call get_sleep_collection() first to search by date range.'
• Implement error handling with actionable guidance. Document expected error codes (e.g., 'auth_failed', 'rate_limited', 'record_not_found') and recovery steps in tool descriptions or a separate errors schema.
• Consider adding a batch tool (e.g., get_multiple_records) accepting an array of IDs. This reduces token waste when agents need multiple records.
• Document default behavior for optional parameters (start, end, limit) in descriptions. LLMs frequently omit optional params, assuming sensible defaults; explicit defaults reduce confusion.

Inferred effective spec: 2026-07-28+.

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