Loading ToolBench
Read-only access to your WHOOP recovery, sleep, strain, workouts, and profile.
WHOOP MCP demonstrates solid fundamentals: all 9 tools have clear verb-noun naming (whoop_overview, whoop_recovery, whoop_get_cycle), descriptions between 100-200 chars (well within the 10-1024 baseline), and explicit JSON Schema input definitions with type and description for every parameter. Tool annotations (readOnlyHint, destructiveHint) are present. However, output schemas are referenced but not fully visible in the provided code (cycleDetailSchema, sleepSchema imported from schemas module), preventing full validation. Parameter descriptions are good but could be more prescriptive about constraints (e.g., 'limit' lacks explicit max enforcement language). Error handling is not visible in the provided samples, making recovery guidance assessment impossible. The server follows composition patterns well, each tool has one responsibility, and tools chain naturally (history tools return IDs that detail tools accept). No security issues detected (OAuth handled server-side, no secrets in params).
Fetch one physiological cycle by id (from whoop_strain records), including its recovery and sleep for full day context.
Fetch one sleep activity by its UUID (from whoop_sleep records).
Fetch one workout by its UUID (from whoop_workouts records).
Single-call snapshot of the user's current WHOOP status: latest recovery, last sleep, current day strain, plus profile and body measurements. Call this first for general WHOOP context.
User profile and body measurements in one call: name, email, height (m), weight (kg), max HR.
Recovery history: recovery %, HRV (ms), resting HR, SpO2, skin temp. Defaults to the last 7 days; pass start/end for a specific range.
Output schemas not fully visible in provided code. cycleDetailSchema, sleepSchema, and other return types are imported from src/whoop/schemas but not shown. Cannot verify that output structures include all chaining IDs (e.g., cycle_id in recovery responses) or that they strip unnecessary API metadata.
Error handling and recovery guidance not visible in provided code samples. Cannot verify that tools return actionable error messages (e.g., 'User not found. Try whoop_overview first.') or categorize errors as retryable vs. fatal.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | A | 85 | 2025-06-18+ | v2 |
Sleep history: performance/efficiency/consistency %, hours slept, stage breakdown (minutes), respiratory rate, sleep need. Defaults to the last 7 days; pass start/end for a specific range.
Daily strain history (physiological cycles): day strain 0-21, average/max HR, calories. Defaults to the last 7 days; pass start/end for a specific range.
Workout history: sport, strain, average/max HR, calories, duration, distance, HR-zone minutes. Defaults to the last 14 days; pass start/end for a specific range.
Parameter 'limit' in history tools (recovery, sleep, strain, workouts) lacks explicit constraint language in description. Description says 'Max records to return (<= 25)' but does not state minimum (1?) or default behavior if omitted. Constraint should be: 'Integer 1 - 25; defaults to 10.'
Date parameters (start, end) use ISO-8601 format constraint but lack guidance on timezone handling. Should clarify: 'ISO-8601 UTC datetime (e.g., 2024-01-15T09:30:00Z). Times are interpreted as UTC.'
No visible pagination or result-limiting enforcement in code samples. History tools accept 'limit' but no evidence of enforcing MAX_PAGE_LIMIT (25) at runtime or returning a next_cursor for continuation. Large result sets risk context window exhaustion.