Loading ToolBench

Reading the current corpus…

whoop-mcp MCP server · C · ToolBench

whoop-mcp

Bring your WHOOP data into Claude (and any MCP client). Single-file, stdio MCP server built on the WHOOP Developer API v2.

2026-07-28+STDIO2 tools

66/100

Definition Quality72

Protocol Readiness50

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

Two tools with clear, actionable descriptions (194 - 200 chars, within baseline 34 - 392 range). Both have proper input schemas with typed parameters and defaults. However, output schemas are completely undocumented, LLMs cannot plan downstream calls or extract fields. No error handling guidance, no parameter constraints (e.g., days 1 - 365), and no tool annotations. Naming is verb-first and clear (whoop_recovery, whoop_sleep), but lacks composition guidance for multi-step workflows.

Tools (2)

whoop_recoveryread onlyauthsource verified72/100

Get daily WHOOP recovery scores: recovery %, HRV (RMSSD ms), resting heart rate, SpO2, and skin temperature. This is the primary signal for deciding training intensity on a given day. Returns newest first.

whoop_sleepread onlyauthsource verified72/100

Get WHOOP sleep records: total sleep time, sleep performance %, efficiency %, consistency %, time in each stage (REM / slow-wave / light / awake), disturbances, respiratory rate, and sleep debt. Returns newest first.

Issues (5)

CRITICALtool ↗

Output schemas completely undocumented. LLMs cannot infer what fields are returned (e.g., does recovery return 'recovery_percent' or 'recovery_score'?), forcing guesswork and downstream failures.

whoop_recoverywhoop_sleep

HIGHconstrained-input ↗

No parameter constraints documented. 'days' and 'limit' accept any integer; no min/max bounds stated. LLMs may pass days=999 or limit=10000, causing API errors or timeouts.

whoop_recoverywhoop_sleep

HIGHrecovery-guide ↗

No error handling guidance. If WHOOP API returns 401, 429, or 404, the tool raises RuntimeError with a message, but LLMs receive no recovery path (e.g., 'retry after 60s' or 'run setup again').

whoop_recoverywhoop_sleep

MEDIUMtool-annotations ↗

No tool annotations. Tools are read-only (risk: READ_ONLY declared in metadata), but readOnlyHint is not set in the MCP tool definition, so LLMs cannot optimize caching or retry logic.

Recommendations

Document output schemas for both tools. Example for whoop_recovery: 'Returns array of {recovery_percent: number, hrv_rmssd_ms: number, resting_heart_rate: number, spo2: number, skin_temperature_celsius: number, timestamp: ISO8601}'. This enables LLMs to extract and chain data.
Add parameter constraints to descriptions: 'days: 1 - 365 (default 7)', 'limit: 1 - 200 (default 14)'. Include rationale: 'Larger limits may hit WHOOP rate limits; paginate with nextToken if needed.'
Add error recovery guidance: 'If 401 Unauthorized, credentials expired, re-run setup. If 429 Too Many Requests, wait 60s and retry. If 404, app may lack read:recovery scope, re-run auth.'
Set readOnlyHint: true in tool definitions so MCP clients can optimize caching and retry behavior for read-only operations.
Clarify pagination in descriptions: 'Use days to set the lookback window; use limit to cap results per call. Combine with nextToken (if returned) to fetch older records. Default returns last 7 days, up to 14 records.'

Score history

Overall score trend

First recorded score · v2 rubric

66/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	66	2026-07-28+	v2