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、精确匹配的回调地址、所列读取权限及 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 分