mcp-server-whoop
A read-only MCP server that gives AI clients access to your personal WHOOP health and fitness data, processed locally without sending credentials to third parties. It offers five focused tools:
whoop_latest_overview: Get a compact coaching snapshot including current recovery (only when scored/ready), latest sleep status, current daily strain, latest workout, recent activity types, and body measurements.whoop_recovery_history: Fetch up to 180 days of recovery data including recovery score, HRV, resting heart rate, SpO2, skin temperature trends, and processing state.whoop_sleep_history: Retrieve up to 180 days of sleep records (primary sleep + optional naps) including bedtime/wake time, duration, sleep stages, performance, efficiency, consistency, respiratory rate, and local timestamps.whoop_cycle_strain_history: Access up to 180 days of daily cycle data including strain score, calories burned, average/max heart rate, processing state, and current-cycle status.whoop_workout_history: View up to 180 days of workout details including sport type, duration, strain, average/max heart rate, calories, distance, heart-rate zone minutes, and processing state.
Key characteristics:
All tools are read-only, non-destructive, and idempotent — no write, delete, or token-management capabilities are exposed.
Data is returned with per-record local timestamps for accuracy across time zones.
Explicitly surfaces
processing/pending states rather than substituting stale data.WHOOP OAuth tokens stay on the user's machine, never sent to a third party.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mcp-server-whoopwhat's my current recovery status?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
mcp-server-whoop
A local-first, read-only Model Context Protocol server for WHOOP. It gives MCP-compatible AI clients compact recovery, sleep, strain, HRV, heart-rate, workout, and body-measurement signals without sending your WHOOP credentials through a hosted third party.
Why this server
Standard MCP over stdio, usable by any client that supports local MCP servers
Local WHOOP OAuth flow with each user's own WHOOP developer application
Access and rotating refresh tokens remain on the user's machine
Five focused read-only tools instead of a noisy API dump
Per-record local timestamps, so travel does not shift sleep or workout dates
Explicit
processingstatus, with no older recovery substituted while a new sleep is pendingHuman-scale hours, minutes, calories, and heart-rate-zone minutes
No raw identifiers, OAuth secrets, or raw continuous heart-rate claims in tool output
No hosted relay, telemetry, database, generic HTTP tool, raw SQL, or install lifecycle scripts
Reproducible tarball security audit, CycloneDX SBOM, CodeQL, Gitleaks, dependency review, and OpenSSF Scorecard
This is an independent community project. It is not affiliated with or endorsed by WHOOP. WHOOP data is useful coaching context, not medical advice.
Related MCP server: whoop-mcp
Requirements
Node.js 18 or newer
A WHOOP account
A free application in the WHOOP Developer Dashboard
An MCP-compatible AI client
Quick start
Create a WHOOP developer application and register
http://127.0.0.1:8765/callback.Enable the five read scopes and
offlinelisted below.Run
npx -y mcp-server-whoop@latest authin a terminal and approve WHOOP access.Run
npx -y mcp-server-whoop@latest statusto confirm the local grant exists.Add the stdio command
npx -y mcp-server-whoop@latestto your AI client's MCP configuration.Restart or reload the client, then ask:
Use WHOOP to summarize my recovery and sleep from the last 7 days.
The authorization command and the AI client must run as the same operating-system user, or both must set WHOOP_CREDENTIALS_FILE to the same private file. The package never asks you to paste WHOOP tokens into an AI conversation.
For reproducible or security-sensitive deployments, replace @latest with an exact reviewed version such as @0.2.0. @latest is convenient but automatically follows future releases.
1. Create your WHOOP application
Create an application in the WHOOP Developer Dashboard and register this exact redirect URL:
http://127.0.0.1:8765/callbackEnable these scopes:
offline
read:recovery
read:cycles
read:sleep
read:workout
read:body_measurementoffline is required because WHOOP access tokens expire and WHOOP rotates refresh tokens.
2. Authorize locally
Run:
npx -y mcp-server-whoop@latest authThe command prompts for your WHOOP client ID and masks the client secret, opens WHOOP consent in your browser, validates the OAuth state, and saves the resulting grant locally.
Credentials are stored at:
~/.config/mcp-server-whoop/credentials.jsonThe directory is forced to mode 0700 and the file to 0600. Override the path with WHOOP_CREDENTIALS_FILE if needed.
For headless environments, provide WHOOP_CLIENT_ID, WHOOP_CLIENT_SECRET, and optionally WHOOP_REDIRECT_URI as environment variables before running auth.
The OAuth callback still needs to reach the machine running auth. When authorizing over SSH, create a loopback tunnel from your workstation first:
ssh -L 8765:127.0.0.1:8765 user@your-serverThen run auth in that SSH session and open its printed WHOOP URL in your workstation browser. Do not pass the client secret as a command-line argument because shell history and process listings may expose it.
Check setup without displaying secrets:
npx -y mcp-server-whoop@latest statusRemove the local grant:
npx -y mcp-server-whoop@latest logoutRevoking access in WHOOP account settings is also recommended when you no longer use an integration.
3. Add it to an AI client
Claude Desktop
Add this under mcpServers in Claude Desktop's configuration, then fully restart Claude Desktop:
{
"mcpServers": {
"whoop": {
"command": "npx",
"args": ["-y", "mcp-server-whoop@latest"]
}
}
}Claude Code
claude mcp add --transport stdio whoop -- npx -y mcp-server-whoop@latestCursor, Windsurf, Gemini Code Assist, and other mcpServers clients
Add the server to the client's MCP JSON. Gemini Code Assist uses ~/.gemini/settings.json; other clients choose their own settings path.
{
"mcpServers": {
"whoop": {
"command": "npx",
"args": ["-y", "mcp-server-whoop@latest"]
}
}
}VS Code
Create .vscode/mcp.json for a project, or use VS Code's MCP: Add Server command:
{
"servers": {
"whoop": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-server-whoop@latest"]
}
}
}Codex
Either run:
codex mcp add whoop -- npx -y mcp-server-whoop@latestOr add this to ~/.codex/config.toml:
[mcp_servers.whoop]
command = "npx"
args = ["-y", "mcp-server-whoop@latest"]ChatGPT
Local Codex and ChatGPT desktop clients that support stdio can use the Codex configuration above. ChatGPT web does not launch a command on your computer; it requires a separately secured remote bridge or tunnel and a workspace plugin. This repository intentionally does not ship or operate a public health-data relay.
Client menus and configuration paths change over time. If a client supports standard local stdio MCP, the portable values are always:
command: npx
arguments: -y mcp-server-whoop@latestConfirm the connection
After restarting the client, confirm that it discovers exactly these five tools:
whoop_latest_overview
whoop_recovery_history
whoop_sleep_history
whoop_cycle_strain_history
whoop_workout_historyUseful prompts:
Use WHOOP to review today's recovery, latest sleep, current strain, and latest workout.Compare my recovery, HRV, and resting heart rate over the last 14 days.Show my last 7 days of sleep, including naps, and flag anything still processing.Summarize my workout strain and heart-rate zones for the last 30 days.Use WHOOP as context for today's training, but do not treat it as medical advice.
The model decides when to call tools, so explicitly say Use WHOOP when you want live data rather than a general answer.
Tools
Tool | Purpose |
| Current coaching snapshot with pending-data safeguards |
| Recovery, HRV, resting HR, SpO2, and skin-temperature trends |
| Primary sleep and optional naps, stages, need, quality, and timing |
| Daily strain, calories, and average/max heart rate |
| Sport, duration, strain, HR, calories, distance, and zone minutes |
All tools are marked read-only, non-destructive, and idempotent.
Why deliberately only five tools?
For a health-data MCP, a larger tool count also means a larger capability surface. This server keeps authentication outside the agent and gives the model only the five health-reading capabilities it needs.
It intentionally has:
no WHOOP write, revoke, token-management, or authorization-code tools
no profile/email/name scope
no raw-record, raw-ID, arbitrary endpoint, SQL, file, or shell tool
no hosted OAuth relay, telemetry service, health-data cache, or database
no stale-recovery fallback when the newest sleep is still processing
The goal is not maximum WHOOP API coverage. It is the smallest practical authority boundary for recovery-aware AI.
Data semantics
WHOOP returns absolute timestamps plus a timezone_offset on sleep, cycle, and workout records. This server applies each record's own offset and returns only already-converted local timestamps such as:
2026-07-07 18:02:22 +04:00It does not apply the machine's current timezone to historical records.
WHOOP exposes activity type and workout sport, but its public API does not indicate whether a workout was auto-detected or manually started. This server does not guess.
When the newest primary sleep is still PENDING_SCORE, the latest overview returns:
{
"status": {
"state": "waiting_for_whoop",
"current_recovery_available": false
},
"recovery": null
}An older recovery is never presented as current.
Environment variables
Variable | Purpose |
| WHOOP OAuth client ID |
| WHOOP OAuth client secret |
| OAuth callback, defaults to |
| Override local credential-file path |
| Optional short-lived access-token override |
| Optional refresh-token override |
| Optional ISO token-expiry override |
Client configuration from WHOOP_CLIENT_ID, WHOOP_CLIENT_SECRET, and WHOOP_REDIRECT_URI overrides file values. Token environment variables can bootstrap a headless setup, but once a refresh token rotates, the newer token persisted in the credential file takes precedence. Do not put secrets directly in command-line arguments or commit them to source control.
Troubleshooting
Missing WHOOP ...
Run npx -y mcp-server-whoop@latest status as the same OS user that launches the AI client. If the credentials are elsewhere, set WHOOP_CREDENTIALS_FILE in the client's MCP environment.
WHOOP reports a redirect mismatch
The redirect in the Developer Dashboard and the value used by this package must match exactly. The default is http://127.0.0.1:8765/callback, including scheme, host, port, and path.
The browser does not open
Copy the authorization URL printed in the terminal and open it manually. The callback listener expires after five minutes; rerun auth if needed.
Port 8765 is already in use
Register another loopback URL such as http://127.0.0.1:9876/callback, set WHOOP_REDIRECT_URI to that exact value, and rerun auth.
Recovery is null
Check the returned status.state. If it is waiting_for_whoop or waiting_for_recovery, WHOOP has not finished scoring the newest sleep. The server intentionally refuses to label an older recovery as current; retry after WHOOP finishes processing.
The client shows no tools
Run npx -y mcp-server-whoop@latest --help in a terminal to verify Node.js and npm can launch the package, then restart the AI client and inspect its MCP logs. Do not run the bare server interactively to inspect output: stdio is reserved for MCP protocol messages.
Development
git clone git@github.com:Yadheedhya06/mcp-server-whoop.git
cd mcp-server-whoop
npm ci --ignore-scripts
npm run checkRun the local source server:
npm run devBuild and inspect the exact npm artifact:
npm pack --dry-runPrivacy and security
This project publishes evidence rather than claiming that any package is perfectly safe. See the full security policy and reproducible security evidence.
Every user owns their WHOOP developer app and OAuth grant.
Credentials stay local and are never returned through MCP tools.
The package provides no WHOOP write, generic network, shell, filesystem, or raw API passthrough tool.
The credential file and its direct parent are checked against symlinks, unsafe permissions, oversized input, and unexpected fields. Refresh rotation uses a crash-aware lock, exclusive temporary file, atomic replacement, and disk sync.
WHOOP and OAuth responses are size-bounded and structurally validated; provider response bodies are never copied into MCP errors.
Direct dependencies use exact versions. There are only two direct runtime dependencies and no package install lifecycle scripts.
CI runs the test suite on Node 18, 20, 22, and 24, scans the exact npm tarball, verifies npm registry signatures, and generates a CycloneDX SBOM.
Independent workflows run CodeQL, Gitleaks, dependency review, and OpenSSF Scorecard.
The publish workflow packs once and publishes that exact tarball through npm Trusted Publishing with Sigstore provenance. GitHub separately attests that tarball against its CycloneDX SBOM; no long-lived npm token is used.
These controls reduce risk, but they are not a paid penetration test or a guarantee. The limitations are documented explicitly in SECURITY-EVIDENCE.md.
License
MIT
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Yadheedhya06/mcp-server-whoop'
If you have feedback or need assistance with the MCP directory API, please join our Discord server