WHOOP MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_SERVER_PORT | No | The port for the MCP server | |
| WHOOP_CLIENT_ID | Yes | Your WHOOP API client ID | |
| WHOOP_REDIRECT_URI | Yes | The redirect URI for OAuth authentication | |
| WHOOP_CLIENT_SECRET | Yes | Your WHOOP API client secret |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| whoop-get-user-profileA | Get basic user profile information (name, email) for the authenticated user |
| whoop-get-user-body-measurementsA | Get body measurements (height, weight, max heart rate) for the authenticated user |
| whoop-revoke-user-accessB | Revoke the access token granted by the user |
| whoop-get-cycle-by-idC | Get the cycle for the specified ID |
| whoop-get-cycle-collectionA | Get all physiological cycles for a user, paginated |
| whoop-get-sleep-for-cycleB | Get sleep data for a specific cycle |
| whoop-get-recovery-collectionB | Get all recovery data for a user, paginated |
| whoop-get-recovery-for-cycleB | Get recovery data for a specific cycle |
| whoop-get-sleep-by-idC | Get the sleep record for the specified ID |
| whoop-get-sleep-collectionB | Get all sleep records for a user, paginated |
| whoop-get-workout-by-idB | Get the workout record for the specified ID |
| whoop-get-workout-collectionA | Get all workout records for a user, paginated |
| whoop-get-authorization-urlB | Get the authorization URL for OAuth flow |
| whoop-exchange-code-for-tokenB | Exchange authorization code for access token |
| whoop-refresh-tokenB | Refresh access token using refresh token |
| whoop-set-access-tokenC | Set the access token for API calls |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Most tools have distinct purposes targeting specific resources like cycles, sleep, workouts, recovery, and authentication. However, there is some potential overlap between collection tools (e.g., whoop-get-cycle-collection and whoop-get-recovery-collection) and their cycle-specific counterparts (e.g., whoop-get-recovery-for-cycle), which could cause minor confusion in selection.
All tools follow a consistent verb_noun pattern with the prefix 'whoop-' and clear action-object naming (e.g., whoop-get-cycle-by-id, whoop-refresh-token). The naming is uniform across all 16 tools, making them predictable and easy to understand.
With 16 tools, the count is slightly high but reasonable for a fitness/health API server covering authentication, user data, cycles, sleep, workouts, and recovery. It provides comprehensive coverage without being overly bloated, though it borders on the upper limit of typical scoping.
The tool set covers core CRUD-like operations for key resources (cycles, sleep, workouts, recovery) and includes essential authentication flows (OAuth, token management). Minor gaps exist, such as lack of update or delete operations for user data or workout records, but agents can likely work around these for most use cases.