Five tools with complete input schemas and detailed descriptions. All tools follow verb_noun naming (whoop_*_*). Descriptions are substantive (100-200 chars), explaining WHAT the tool does and WHEN to use it. Input parameters have type definitions and descriptions with min/max constraints. Output schemas are documented with structured fields. Tool annotations (readOnlyHint, idempotentHint, destructiveHint, openWorldHint) are present on all tools. Key strength: descriptions explicitly address WHOOP's processing states (SCORED, PENDING_SCORE, UNSCORABLE) and local-time handling, guiding LLM behavior. Weakness: output schemas use generic recordSchema (z.record(z.string(), z.unknown())) rather than typed objects, reducing clarity on what fields agents should expect. Error handling is minimal, no recovery guidance if API calls fail.

• Replace z.record(z.string(), z.unknown()) with explicit typed schemas. E.g., recovery output should be z.object({ score: z.number(), hrv: z.number(), resting_heart_rate: z.number(), spo2: z.number(), skin_temperature: z.number(), processing_state: z.enum(['SCORED', 'PENDING_SCORE', 'UNSCORABLE']) }). This lets LLMs know exactly what fields to extract.
• Add error handling with recovery guidance. Wrap API calls in try-catch; return structured errors like { error: 'auth_expired', message: 'WHOOP token expired. Please re-authenticate.', recovery: 'Call whoop_authenticate() to refresh credentials.' }.
• Document max records returned per tool. E.g., 'Returns up to 50 most recent records within the requested day range. If more exist, results are truncated; use smaller day ranges to paginate.'
• Add brief definitions of WHOOP processing states in server instructions or tool descriptions. E.g., 'SCORED: WHOOP has finalized metrics. PENDING_SCORE: still processing. UNSCORABLE: insufficient data to score.'
• Consider adding a batch_fetch_recovery(days: number[]) tool to reduce sequential calls when agents need multi-day data. This improves latency and token efficiency.