WHOOP — MissingMCP

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.

Claude → POST /garmin/mcp (Bearer) → Gateway → 127.0.0.1:<port>/mcp (per-user garmin_mcp) → connect.garmin.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_mcp worker bound to 127.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_mcp worker 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):

cp .env.example .env          # set GATEWAY_SECRET, PUBLIC_URL, pin GARMIN_MCP_REF

docker build -t missingmcp . docker run -d --name missingmcp --restart unless-stopped --env-file .env \ -p 127.0.0.1:8080:8080 -v missingmcp-data:/data missingmcp

Put any TLS-terminating proxy in front (Caddy, nginx, Traefik). One non-obvious requirement: / /mcp streams SSE, so disable response buffering and raise the read timeout (nginx: proxy_buffering off; proxy_read_timeout 3600s;). Then add https:// /garmin/mcp as a remote MCP server in Claude.

Local development

uv pip install -e ".[dev]"

uv run --extra dev pytest -q # run the test suite

Run the gateway locally (no Garmin account needed to exercise the OAuth surface).

garmin-mcp isn't on PATH locally, so point GARMIN_MCP_CMD at uvx.

GATEWAY_SECRET="$(openssl rand -base64 48)" \ PUBLIC_URL=http://localhost:8088 PORT=8088 DATA_DIR=./.localdata \ GARMIN_MCP_CMD="uvx --python 3.12 --from git+https://github.com/Taxuspt/garmin_mcp garmin-mcp" \ uv run missingmcp

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

1. In any Claude client: Settings → Connectors → Add custom connector, or in the CLI: claude mcp add --transport http garmin https:// /garmin/mcp (whoop: claude mcp add --transport http whoop https:// /whoop/mcp; car: .../car/mcp).
2. 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.
3. Done — the service's tools are now available in Claude.

Configuration

Set via environment (or .env). See .env.example.

| GARMIN_SSO_PROXY | no | — (direct) | Comma-separated proxy URLs (http://user:pass@host:port) on dedicated IPs for the gateway's own Garmin traffic — sign-in, MFA, token verify — instead of the shared host egress that Garmin's SSO rate-limits (ticket 12). Each account sticks to one proxy (by account hash). Sign-in throttling (failing-logins map): one in-flight sign-in per login email (a concurrent one is turned away); a 2 min post-connect hold after a real connection; a "blocked" sign-in cools down only that account for 5 min, without an in-call retry; an egress's breaker trips once ≥2 distinct accounts are blocked on it with no sign-in getting through between, or on ≥10 blocks in an hour, resting it 30 min → 2 h → 6 h → 24 h on repeated trips (back to 30 min after a sign-in gets through). An egress tripped with no sign-in through since is *suspect*: one block on it trips the next step. A sign-in whose block trips its egress is retried once on the next route within the same call (if the first attempt took < 35 s); a block on that retry cools only the account. The rest level, rest end, egress IP and last ok/blocked times persist in the egress_state table, so deploys don't reset a burned IP; when the probe sees a route leave from a new IP, its state starts over (sudo mmcp egress shows it on hydra). A proxy that can't carry the request at all (port refused, CONNECT refused — curl's CONNECT tunnel failed / (5)/(7)/(97); Garmin never saw it) is outcome egress, not blocked: the account isn't cooled, the egress rests 5 min, and the same sign-in fails over to the next route within the call; only when every route is down does the user see an "unavailable on our side" message. The direct path stays as the last resort (reached only when every proxy is cooling down). Mobile SSO strategies are skipped on proxied sign-ins (they 429 from datacenter fingerprints even on a clean IP). Workers and all other traffic stay direct. Events: garmin-login-attempt (account, egress, egress_ip, outcome, message), login-breaker-open / login-breaker-reject (scope: account|egress|egress_down|in_flight|post_success, egress, account, message), sso-probe per egress (via, message), egress-state-restored at startup (egress, egress_ip, rest_level, remaining_s), egress-state-save-failed (egress, `