WHOOP Health Signals

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 processing status, with no older recovery substituted while a new sleep is pending
• Score-derived metrics appear only for SCORED records; live current-cycle strain is labeled provisional_strain
• Human-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.

Requirements

• Node.js 18 or newer
• A WHOOP account
• A free application in the WHOOP Developer Dashboard
• An MCP-compatible AI client

Quick start

1. Create a WHOOP developer application and register http://127.0.0.1:8765/callback.
2. Enable the five read scopes and offline listed below.
3. Run npx -y [email protected] auth in a terminal and approve WHOOP access.
4. Run npx -y [email protected] status to confirm the local grant exists.
5. Add the stdio command npx -y [email protected] to your AI client's MCP configuration.
6. 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.

The documentation pins an exact reviewed version by default. Use @latest only if you explicitly want your client to follow future releases without reviewing them first.

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/callback

Enable these scopes:

offline
read:recovery
read:cycles
read:sleep
read:workout
read:body_measurement

offline is required because WHOOP access tokens expire and WHOOP rotates refresh tokens.

2. Authorize locally

Run:

npx -y [email protected] auth

The 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.json

On Linux and macOS, every path ancestor is checked before use, the direct directory is current-user-owned with mode 0700, and the file is a single-link current-user-owned regular file with mode 0600. Override the path with WHOOP_CREDENTIALS_FILE only when every ancestor is trusted and is not a symlink.

Persistent OAuth credentials intentionally fail closed on native Windows. Node.js file modes do not enforce private Windows ACLs, and its standard file APIs cannot guarantee reparse-safe credential writes. Native Windows users can provide a short-lived WHOOP_ACCESS_TOKEN through the MCP process environment, but automatic authorization and refresh-token persistence require WSL, Linux, or macOS until a native credential backend is available.

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-server

Then 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 [email protected] status

Remove the local grant:

npx -y [email protected] logout

Revoking 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", "[email protected]"]
    }
  }
}

Claude Code

claude mcp add --transport stdio whoop -- npx -y [email protected]

Cursor, 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", "[email protected]"]
    }
  }
}

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", "[email protected]"]
    }
  }
}

Codex

Either run:

codex mcp add whoop -- npx -y [email protected]

Or add this to ~/.codex/config.toml:

[mcp_servers.whoop]
command = "npx"
args = ["-y", "[email protected]"]

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 [email protected]

Confirm 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_history

Useful 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

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:00

It 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

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 [email protected] 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 [email protected] --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 [email protected]:Yadheedhya06/mcp-server-whoop.git
cd mcp-server-whoop
npm ci --ignore-scripts
npm run check

Run the local source server:

npm run dev

Build and inspect the exact npm artifact:

npm pack --dry-run

Privacy 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.
• On supported POSIX storage, the credential file and every ancestor are checked against symlinks, unsafe ownership or permissions, oversized input, and unexpected fields. Refresh rotation uses a heartbeat lease that does not trust PIDs, an exclusive temporary file, atomic replacement, post-write verification, and disk sync. Native Windows persistence fails closed.
• 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 full test suite on Node 18, 20, 22, and 24, adds macOS and Windows platform-security jobs, audits both source and the exact compiled npm runtime, 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