WHOOP — MissingMCP
com.missingmcpPublished by missingmcp.comOfficial publisherv1.0.0Updated Nov 2, 2026
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
The publisher's own server: Garmin — MissingMCP
Overview
Remote WHOOP connector that lets an assistant read recovery, sleep, strain, workout and body-measurement data through WHOOP's official OAuth sign-in.
- What you can do
- Read WHOOP recovery, sleep, strain and daily cycle data
- Review workouts and body measurements
- Sign in through WHOOP's own OAuth page so the gateway never sees the WHOOP password
- Refresh rotating WHOOP tokens automatically on the user's behalf
- When to use it
- Use it when you want an assistant to discuss your WHOOP recovery, sleep, strain or training data without running anything locally, connecting from any Claude client with a browser sign-in.
- Requirements
- A remote MCP endpoint reached over HTTP with OAuth 2.1 sign-in; a WHOOP account and a browser to approve access. Self-hosting requires a registered WHOOP developer app with WHOOP_CLIENT_ID and WHOOP_CLIENT_SECRET, an exact redirect URI, the listed read scopes plus offline, and a GATEWAY_SECRET.
Installation
In SourceWeft
- Open WHOOP — MissingMCP in the dashboard and add it to a workspace.
- Connect the required credentials. They are stored privately and never shown on public pages.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/com.missingmcp%2Fwhoop/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config. The client completes OAuth sign-in on first connect.
{
"mcpServers": {
"whoop-missingmcp": {
"type": "http",
"url": "https://missingmcp.com/whoop/mcp"
}
}
}README
MissingMCP
The MCP servers exist. Connecting them shouldn't be complicated.
A multi-user, OAuth 2.1–protected gateway that hosts the connectors Claude is
missing, so a small trusted circle can connect their own accounts from any
Claude client (iOS, Android, Web, Desktop). The flagship connector is
Garmin Connect: the gateway wraps the
unmodified garmin_mcp worker and
adds OAuth, per-user token isolation, and a reverse proxy. WHOOP
is served the same way but in-process, on WHOOP's own official OAuth v2 API.
The core is adapter-based and supports three forward strategies — worker
(garmin), local (whoop, in-process, no subprocess), and remote (MCP +
header injection, for services with a hosted MCP that lacks its own OAuth) —
see Connectors. The reference deployment runs at
missingmcp.com.
Why
garmin_mcp is a great MCP server, but it's single-user and stdio-only: each
person has to run it locally with their own Garmin tokens. This gateway makes it a
remote MCP server any Claude client can connect to over HTTP, with a proper
OAuth sign-in flow — so non-technical users just click "connect" and log in with
their Garmin credentials, and never touch a terminal or a token file.
Features
- OAuth 2.1 — Authorization Code + PKCE (S256) with Dynamic Client Registration. Connect from any Claude client; no manual token wrangling.
- Garmin password is never stored — used once to sign in (MFA supported); only the resulting session tokens are persisted.
- Encrypted at rest — tokens sealed with AES-256-GCM; the DB is useless without
GATEWAY_SECRET. Bearer tokens are stored only as SHA-256 hashes. - Per-user isolation — each account gets its own
garmin_mcpworker bound to127.0.0.1, started on demand and reaped when idle. - Hardened — one-time 10-min auth codes, CSRF on forms, per-IP/-token rate
limits, the
garmin_mcpworker pinned to a reviewed commit. - Off-box backups — periodic encrypted SQLite snapshots to an S3-compatible bucket (see Backups).
- Instructional landing page served on
/and as a friendly fallback for unknown paths.
Deploy
How missingmcp.com runs: one Hetzner VM (hydra), the gateway as a single
docker compose service with /data on the host, Caddy terminating TLS behind
Cloudflare. Every push to main builds an arm64 image to GHCR and deploys it
(.github/workflows/deploy.yml). Runbook, monitoring and alerts:
deploy/README.md. It ran on Railway until the 2026-10-25
cutover.
Self-hosted (plain Docker):
Put any TLS-terminating proxy in front (Caddy, nginx, Traefik). One non-obvious
requirement: /<adapter>/mcp streams SSE, so disable response buffering and
raise the read timeout (nginx: proxy_buffering off; proxy_read_timeout 3600s;).
Then add https://<your-domain>/garmin/mcp as a remote MCP server in Claude.
Local development
A .env file in the working directory is loaded automatically (real environment
variables take precedence), so you can drop the same values there instead.
Connectors
Each connector is mounted under its own path prefix with its own OAuth flow and
its own Bearer tokens (there is no bare /mcp). The landing page on / lists
the available connectors.
Garmin — /garmin/mcp
Sign in with your Garmin Connect email + password (MFA supported). The password
is used once for the Garmin login and discarded; only the resulting Garmin
session tokens are stored (AES-256-GCM encrypted). Each account gets its own
garmin_mcp worker process, bound to 127.0.0.1, started on demand and reaped
when idle.
WHOOP — /whoop/mcp
Sign in on WHOOP's own OAuth page — the gateway never sees your WHOOP password, only the resulting (encrypted, read-only) tokens. Covers recovery, sleep, strain & daily cycles, workouts, and body measurements. Served in-process on WHOOP's official v2 API (no worker subprocess, no shared upstream). Requires the operator to register a WHOOP developer app — see WHOOP connector setup in Configuration.
Car — /car/mcp (beta)
One connector for every supported car brand; the brand is picked per account on
the sign-in form. Today: Škoda, on the official
MyŠkoda Public API. Each user
brings their own API key (MyŠkoda app → Profile → Smart home → Create key)
plus the car's VIN and an email. Key and VIN are stored encrypted; no
operator setup or secret is needed, so the connector is always on. Served
in-process (local strategy). Tools are brand-neutral: status, location (only on
request), and climate / ventilation / charging start-stop and charge limit,
filtered per car by what it supports. Škoda allows 20 requests/hour per car;
status is cached for 60 s and every result reports the remaining budget. Works
in Claude, ChatGPT and Grok (connect steps on the /car landing page).
Rohlík — no longer missing
The gateway briefly served a Rohlík connector (remote strategy: credential
headers injected into the hosted Rohlík MCP). It was retired in 2026-07 when
Rohlík shipped its own OAuth-protected MCP — add
https://mcp.rohlik.cz/mcp directly as a custom connector in Claude and sign
in in the browser (Rohlík's guide).
The remote-forward strategy remains a first-class, tested part of the core
(tests/test_remote_forward.py) for the next service that needs it.
Connecting from Claude
- In any Claude client: Settings → Connectors → Add custom connector, or in
the CLI:
claude mcp add --transport http garmin https://<your-domain>/garmin/mcp(whoop:claude mcp add --transport http whoop https://<your-domain>/whoop/mcp; car:.../car/mcp). - Claude opens the gateway's sign-in page — enter the service's email + password (Garmin also prompts for an MFA code when needed); for WHOOP, sign in on WHOOP's own OAuth page; for car, pick the brand and paste your own API key + VIN.
- Done — the service's tools are now available in Claude.
Configuration
Set via environment (or .env). See .env.example.
WHOOP connector setup
- Create an app at https://developer-dashboard.whoop.com (instant self-service).
- Redirect URI:
https://<your-domain>/whoop/oauth/callback— exact match required. - Scopes:
read:recovery read:cycles read:workout read:sleep read:profile read:body_measurement offline(offlineis required — without it WHOOP issues no refresh token and sessions die after an hour). - Put the app's Client ID/Secret into
WHOOP_CLIENT_ID/WHOOP_CLIENT_SECRET.
Note: an unapproved WHOOP app is limited to 10 WHOOP members. To lift the limit, submit the app for approval: https://developer.whoop.com/docs/developing/app-approval/ (requirements: API Terms of Use compliance, tested with ≥1 member, accurate app name / contact email / privacy-policy URL in the dashboard, brand-guidelines compliance, and their Typeform submission).
Operating obligations under the WHOOP API Terms of Use (the gateway's design already covers the technical ones — no WHOOP data stored, encrypted tokens, auto-purge of revoked accounts):
- Report any security incident involving WHOOP member data to [email protected] without undue delay, and to affected users.
- No press release or public announcement that references WHOOP without WHOOP's prior written approval.
- Keep the app's Client ID/Secret out of the repo (env vars only) and never reuse them for another application.
- When a member revokes the app at WHOOP, the gateway detects it on the next
refresh (
invalid_grant), deletes the stored tokens, and revokes the member's gateway access tokens (log eventwhoop-account-revoked).
Backups
When the BACKUP_S3_* variables are set, the gateway uploads a consistent
SQLite snapshot (via the SQLite backup API, WAL-safe) to the bucket right
after startup and then every BACKUP_INTERVAL_HOURS. Keys rotate by weekday
(db/gateway-mon.db … db/gateway-sun.db), giving seven days of retention
with no cleanup logic. Watch the backup-ok / backup-failed log events.
Only the DB is backed up — per-user token dirs under DATA_DIR/users/ are
re-materialized from the DB on demand.
The backup is useless without
GATEWAY_SECRET(account blobs stay AES-256-GCM encrypted inside it) — and that is the point. Keep a copy ofGATEWAY_SECRETsomewhere that is not the bucket and not the server (e.g. your password manager). Losing the secret = losing every account.
Restore: download the newest object, put it at $DATA_DIR/gateway.db
(delete any stale gateway.db-wal/-shm next to it), set the same
GATEWAY_SECRET, start the gateway. Bearer tokens and logins survive;
workers respawn lazily.
Monitoring
Three helper scripts work directly on the gateway's DB (safe to run while the gateway is live):
The gateway also posts this daily user-stats report to Slack on its own each
morning (DAILY_REPORT_HOUR, default 08:00 DAILY_REPORT_TZ) when
SLACK_WEBHOOK_URL is set; scripts/daily_report.py runs the same report on
demand for testing.
Mail campaigns — one-off announcements to users and newsletter
subscribers, sent through Cloudflare Email Sending (MAIL_* env above). The
operator creates and starts a campaign; the gateway drains it on its own, a
batch per minute, at most MAIL_DAILY_CAP a day, most active users first —
a large list simply spreads over several days.
Every recipient is a row in a send ledger, so nobody gets a campaign twice: a
send is recorded as sending before the API call, and a crash or an
ambiguous API failure (timeout, 5xx) parks it as unknown for the operator
instead of retrying blindly (and counts toward the daily cap). A rejection of
one address (400/422) retries that address up to 3 times without holding up
the rest; an account-wide error (bad token, quota, rate limit) charges nobody
and pauses the mailer for 15 min. An address that unsubscribed is dropped
right before every send, requeues included. Each mail carries an unsubscribe link plus RFC 8058 one-click
List-Unsubscribe headers (/unsubscribe — GET only confirms, POST
unsubscribes); an opt-out is global and drops the address from every campaign.
A campaign auto-pauses if hard bounces exceed 5% (judged after 50 sends).
Progress is reported only as log events — campaign-batch,
campaign-daily-cap, campaign-auto-paused, campaign-done,
campaign-send-unknown, campaign-run-failed — never by mail.
PostHog telemetry — with POSTHOG_API_KEY set (see the env table), the
gateway also ships analytics to PostHog (EU cloud; design:
docs/superpowers/specs/2026-07-20-posthog-telemetry-design.md):
per-request $mcp_* events (PostHog's built-in MCP analytics), a lean
connect-funnel/conversion event set, an OTLP tee of the structured log stream
(PostHog Logs, only with POSTHOG_LOGS=true — the host journal stays the durable archive), and posthog-js on the
site (UTM campaign attribution; autocapture disabled on OAuth pages). Egress
rule: identity + metadata only — never MCP bodies, credentials, or form
contents; the account email travels only as distinct_id. Everything is
fire-and-forget: a PostHog outage never blocks a request. The Slack reports
above keep running unchanged — PostHog complements them. When off-boarding a
user (revoke.py --purge), also delete the person in PostHog (People → delete)
to complete the GDPR path.
Beer supporters — scripts/add_beer.py records a "buy me a beer" donation
(buymeacoffee.com/venik) into a local beers audit table and emits a
beer_purchased PostHog event, best-effort attributed to the supporter's
gateway account (matched when the email is a known login). The event is meant to
feed the operator's connect→paying funnel and "beers this month" metric on the
Growth dashboard — those PostHog insights are set up manually and don't exist
until built. Ingestion is manual for now (BMC automation deferred; design:
docs/superpowers/specs/2026-07-24-beer-supporters.md). Same egress rule as
above — the email travels only as distinct_id, never the supporter name or
note.
With Docker the scripts are baked into the image at /app/scripts; run them
inside the container. status.py finds the DB under /data automatically:
On missingmcp.com (hydra) run them in the compose service; logs live in
the host journal (see deploy/README.md → Operating):
All logging is structured JSON on stdout (one event per line) with a proper
level attribute — including uvicorn/stdlib records (event stdlib-log) and
each worker's own output (event worker-log, with an account attribute;
lines matching ERROR/Traceback are elevated to error severity). That makes
everything greppable — e.g. "event": "worker-log" plus the account's email
to trace one user's worker, or "level": "error" for problems. Request latency is recorded per call in the
mcp-response event (ttfb_ms, total_ms, bytes, tool, account);
login/verify and worker-spawn events carry ms durations. The gateway also
logs a stats event (accounts / tokens / people-with-token / clients /
active-workers) on startup and whenever those counts change, and status.py
lists the running workers.
Automatic data hygiene
The gateway keeps its own DB tidy — no manual grooming needed. Alongside expiring old auth codes and access tokens, the background loop (roughly once a minute):
- sweeps abandoned OAuth clients — Claude registers a fresh client (DCR) on
every connection attempt, and one that never completes the flow leaves a
token-less client behind. Any client with zero access tokens older than one
hour (comfortably above the 10-min code lifetime, so an in-progress sign-in is
never touched) is removed. This is why
status.py's OAuth-client count tracks the number of connected devices rather than growing with every failed attempt. Revoking a device also leaves its client token-less, so it's swept the same way. - purges retired-adapter data — if a connector is ever dropped, all its rows (accounts, tokens, clients, codes, usage) are deleted across the board. The retired set is an explicit list in the code, never inferred from configuration, so a missing env var can't accidentally wipe a live connector.
Both are logged only when they actually delete something — cleanup-orphan-clients
(count) and cleanup-dead-adapter (adapter + per-table counts) — so a quiet
log means there was nothing to clean. The one-hour threshold is a fixed constant,
not an env var, by design.
How it works
- Claude registers a client (DCR) and starts OAuth 2.1 (Authorization Code + PKCE).
- On the authorize page the user signs in with Garmin (email + password, + MFA if
prompted). The gateway logs in via
garminconnect, stores only the resulting tokens (encrypted), and discards the password. - Claude exchanges the code for a Bearer token.
- On each
/garmin/mcpcall the gateway ensures the user'sgarmin_mcpworker is running (its own tokens, bound to127.0.0.1) and reverse-proxies to it.
Adapters using the remote strategy replace steps 2 and 4 with a probe-verify against the upstream MCP and a direct header-injected forward — no worker.
Adapters using an upstream-OAuth login (whoop) replace step 2 with a redirect to the provider's own OAuth page; the provider calls back with tokens, which the gateway verifies and persists the same way (verify-then-persist is unchanged). Adapters using the local strategy (whoop) replace step 4: the request is handled in-process — no worker, no shared upstream — and the gateway refreshes the account's rotating WHOOP tokens itself as needed.
Security
- Garmin password is never persisted; WHOOP passwords are never even seen (sign-in happens on WHOOP's own OAuth page, read-only scopes).
- Tokens encrypted at rest (AES-256-GCM); the DB is useless without
GATEWAY_SECRET. - A member revoking the app at WHOOP is detected on the next refresh and their stored tokens are purged automatically.
- Bearer tokens stored only as SHA-256 hashes.
- OAuth 2.1 PKCE (S256), one-time 10-min codes, CSRF on forms, per-IP/-token rate limits.
- Workers bind
127.0.0.1only;garmin_mcpis pinned to a reviewed commit.
Deploy only on infrastructure you control and trust. Back up
DATA_DIR; keepGATEWAY_SECRETseparately.
Before you deploy
- Set a real random
GATEWAY_SECRET(openssl rand -base64 48) — the app refuses to start with the placeholder from.env.example. - Pin
GARMIN_MCP_REFto a reviewed commit SHA —mainis a floating ref that can change without notice (supply-chain). - Revoking access — access tokens expire after
ACCESS_TOKEN_TTL_DAYS(default 90; the user just re-authenticates in Claude). To revoke sooner — a leaked token or a removed user — runpython scripts/revoke.py --account [<adapter>:]<email>(kill-switch for all of that account's tokens). A single device can be revoked with--device <hash-prefix>(prefixes are shown bystatus.py). - Run a manual end-to-end smoke test with a real Garmin account (including the MFA path) before connecting real users — the upstream is mocked in the automated tests.
Support
If this gateway is useful to you, you can buy me a beer 🍺.
License
MIT © 2026 Vaclav Slajs
Acknowledgements
Wraps the excellent garmin_mcp by Taxuspt,
unmodified. Garmin and Garmin Connect are trademarks of Garmin Ltd.; this project is
not affiliated with or endorsed by Garmin.
Source: README.md at commit 7b38b95
Tools
0Version history
1- v1.0.0LatestSep 16, 2026
Score
85% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts