WHOOP — MissingMCP
com.missingmcp由 missingmcp.com 發布官方發布者v1.0.0更新於 Nov 2, 2026
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
發布方自己的服務：Garmin — MissingMCP
概覽
遠端 WHOOP 連接器，讓助理透過 WHOOP 官方 OAuth 登入讀取恢復、睡眠、負荷、訓練與身體測量資料。
- 可以做什麼
- 讀取 WHOOP 的恢復、睡眠、負荷與每日週期資料
- 檢視訓練紀錄與身體測量資料
- 透過 WHOOP 自己的 OAuth 頁面登入，閘道不會接觸 WHOOP 密碼
- 自動更新輪替的 WHOOP 權杖
- 適用情境
- 想讓助理討論你的 WHOOP 恢復、睡眠、負荷或訓練資料，又不想在本機執行任何程式時使用；任何 Claude 用戶端透過瀏覽器登入即可連線。
- 執行需求
- 透過 HTTP 存取的遠端 MCP 端點，使用 OAuth 2.1 登入；需要 WHOOP 帳號與瀏覽器授權。自架需註冊 WHOOP 開發者應用程式，設定 WHOOP_CLIENT_ID 與 WHOOP_CLIENT_SECRET、完全相符的重新導向 URI、所列讀取範圍及 offline，並設定 GATEWAY_SECRET。
安裝
在 SourceWeft 中
- 開啟 儀表板中的 WHOOP — MissingMCP，將其新增到工作區。
- 連接 所需的 憑證。它們會被私密儲存，絕不會在公開頁面上展示。
- 為需要使用其工具的對話啟用該服務。
Web executable，透過 Streamable HTTP。 遠端服務在工作區中設定後即可從網頁執行環境執行。
交給代理程式安裝
把這段提示詞貼上到 Claude Code、Codex、Cursor 等代理程式，或 SourceWeft 對話中。代理程式會讀取該伺服器的安裝指南，先向你展示發布者、端點和登入方式，經你同意後再把它新增到你的客戶端。金鑰不會寫進任何命令。
閱讀 https://sourceweft.com/mcp/com.missingmcp%2Fwhoop/install.md，並按其中說明把這個 MCP 伺服器接入我的客戶端。修改任何設定之前，先告訴我它的發布者、端點和登入方式，等我確認。不要把 API 金鑰寫進命令或我會提交的檔案；問我金鑰應從哪裡取得。其他 MCP 客戶端
把它新增到你客戶端的 mcpServers 設定中。 客戶端會在首次連接時完成 OAuth 登入。
{
"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.
來源：README.md，提交 7b38b95
工具
0版本歷史
1- v1.0.0最新Sep 16, 2026
評分
已滿足適用檢查項的 85%
該評分衡量此收錄條目的完整程度，依據註冊中心條目、端點與公開來源計算得出。它不是對伺服器本身的評價，也不表示伺服器安全或目前可用：可連通性是帶日期的檢查結果，評分也不包含安裝量或使用者評價。
- 近 30 天內可連通必需25 分
- 已宣告認證方式必需10 分
- 已列出工具15 分
請讓伺服器在無憑證時回應 tools/list，或發布可在沙箱中無憑證啟動的軟體包。
- 描述必需15 分
- 圖示10 分
- 文件15 分
- 授權條款10 分