Whoop MCP has 11 well-named, read-only tools with consistent verb_noun naming (get_*). All tools have descriptions (avg ~120 chars, within baseline 34-392 range). Input schemas are present with type definitions and parameter descriptions. However, output schemas are NOT documented, LLMs cannot predict response structure for downstream chaining. Parameter descriptions are adequate but lack explicit constraints (e.g., 'limit: max 25' is stated in description but not as a JSON Schema maxItems). Error handling is minimal, no recovery guidance or categorization. No tool annotations (readOnlyHint present in metadata but not declared per-tool). Composition is sound: tools are single-purpose and chainable (e.g., get_recent_cycles → get_recovery_for_cycle). Security is strong: credentials injected server-side, no secrets in params.

• Document output schemas for all tools. Example: get_recent_recovery should declare that it returns {records: [{recovery_score: number, resting_heart_rate: number, ...}], pagination: {total: number, limit: number}}. This enables LLMs to extract and chain data correctly.
• Add JSON Schema constraints: maxItems/maximum for 'limit' and 'days' parameters. Replace description-only constraints with formal schema validation so LLMs see the bounds in the tool definition, not just prose.
• Enhance error handling in get_today() and other tools: catch WhoopAuthError and return {error: 'Authentication failed', recovery: 'Call re-authenticate or check WHOOP_REFRESH_TOKEN'} instead of a bare string. Categorize errors as retryable or fatal.
• Add readOnlyHint: true to all tool definitions via FastMCP's tool decorator or metadata. This signals to LLMs and clients that these tools are safe to call without confirmation.
• Document pagination behavior: specify whether list endpoints return total_count, next_cursor, or require offset-based continuation. Add an example response snippet in the tool description.