Whoop MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORT | No | HTTP server port | 3000 |
| DB_PATH | No | SQLite database path | ./whoop.db |
| MCP_MODE | No | http for remote, stdio for local | http |
| WHOOP_CLIENT_ID | Yes | Whoop OAuth client ID | |
| WHOOP_REDIRECT_URI | No | OAuth callback URL | http://localhost:3000/callback |
| WHOOP_CLIENT_SECRET | Yes | Whoop OAuth 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
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_todayA | Returns the user's latest WHOOP status as Markdown: the most recent recovery (score %, Green/Yellow/Red zone, HRV in ms, resting heart rate, SpO2, skin temperature), last night's sleep (time asleep, performance, efficiency, light/deep/REM stages, respiratory rate) and today's strain so far (0–21) with calories and heart rate. Use it first for questions like "how am I today?" or "should I train hard?". For more than one day, use get_recovery_trends, get_sleep_analysis, get_strain_history or get_workouts. When a newer version of this server is out, the answer ends with a one-line notice to pass on to the user. Read-only: it never changes the user's WHOOP data. It fetches the data live from WHOOP on every call and keeps no copy, so the answer is current; if WHOOP can't be reached, it says so. If WHOOP isn't connected yet, it returns a message asking to call get_auth_url. |
| get_recovery_trendsA | Returns daily recovery for the last |
| get_sleep_analysisA | Returns nightly sleep for the last |
| get_strain_historyA | Returns daily strain for the last |
| get_workoutsA | Returns individual workouts from the last |
| get_auth_urlA | Returns a one-time link that connects the user's WHOOP account to this server through WHOOP's own login. Use it when a data tool such as get_today says WHOOP isn't connected or its authorization expired. Give the link to the user to open in a browser: it works once and expires in 10 minutes. Once they have logged in, get_today and the other data tools work. It doesn't read any WHOOP data. A server running in stdio mode can't receive WHOOP's login, so there it returns setup instructions instead. |
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 6 tools
Each tool targets a distinct WHOOP metric domain (recovery trends, today's snapshot, auth, sleep, strain, individual workouts), and the descriptions explicitly cross-reference each other with guidance on when to prefer one over another. There is essentially no risk of misselection.
All tools follow a uniform get_ verb + noun pattern in snake_case (get_recovery_trends, get_today, get_auth_url, get_sleep_analysis, get_strain_history, get_workouts). The convention is predictable and readable throughout.
Six tools is well-scoped for a read-only health data server, with one tool per major WHOOP metric plus an auth helper. Nothing feels redundant or missing at the count level.
The surface covers recovery, sleep, strain, workouts, a daily snapshot, and authorization, which matches the domain well. Minor gaps exist (e.g., no user profile/body metrics or journal data), but these are edge concerns an agent could work around.