Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Beschreibung vom Entwickler (englisches Original)
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
Diese drei werden nie zu einer Punktzahl zusammengefasst: Meinungen, Messungen und Beliebtheit sind verschiedene Dinge.
Für diesen Server haben wir noch keine Zusammenfassung in einfacher Sprache geschrieben. Unten stehen die Fakten, die wir aus der Registry gelesen haben.
Wähle die KI-App, die du nutzt, und kopiere die Einstellungen.
Du brauchst
Welche App nutzt du?
Wähle oben deine App. Wir merken sie uns, damit der Button beim nächsten Mal „In … installieren“ anzeigt.
Funktioniert in Claude im Web, auf dem Desktop und auf dem Handy:
https://missingmcp.com/garmin/mcpFühre das in deinem Terminal aus
claude mcp add --transport http garmin https://missingmcp.com/garmin/mcpIn .cursor/mcp.json in deinem Projekt oder in ~/.cursor/mcp.json einfügen
{
"mcpServers": {
"garmin": {
"url": "https://missingmcp.com/garmin/mcp"
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
In .vscode/mcp.json in deinem Projekt einfügen
{
"servers": {
"garmin": {
"type": "http",
"url": "https://missingmcp.com/garmin/mcp"
}
}
}Dein Browser fragt, ob er die App öffnen darf, dann zeigt die App die Einstellungen und bittet dich um Bestätigung. Schlüsselwerte bleiben leer, damit du sie selbst einträgst.
ChatGPT verbindet sich nur mit Servern im Internet:
https://missingmcp.com/garmin/mcpMenünamen können sich je nach Tarif und mit der Zeit leicht unterscheiden.
Deine Auswahl bleibt in einem Cookie auf diesem Gerät; kein Konto nötig.
Diese Einstellungen werden aus dem Registry-Eintrag des Entwicklers erzeugt. Wenn in der README etwas anderes steht, folge der README.
Die Tool-Liste dieses Servers haben wir noch nicht gelesen; wir prüfen die Endpunkte reihum.
Wir prüfen Informationen, die jeder sehen kann; den Code haben wir nicht gelesen. Checks, die nicht zutreffen, werden nicht mitgezählt. · Geprüft am 6. Nov. 2026
Der Registry-Name wurde über die Domain missingmcp.com bestätigt (die Registry prüft, wem die Domain gehört)
Dieses Repo haben wir noch nicht von GitHub gelesen
Dieses Repo haben wir noch nicht von GitHub gelesen
Noch nicht geprüft; wir prüfen die Endpunkte reihum
Noch nicht geprüft; wir prüfen die Endpunkte reihum
Noch nicht geprüft; wir lesen die Tool-Liste, wenn wir den Endpunkt prüfen
Verglichen mit allen aktiven Servern dieser Kategorie in der Registry. Sterne zählen nur, wenn dem Herausgeber das Repo gehört.
Er hat 1 von 1 zutreffenden Basischecks bestanden. Den Code haben wir nicht gelesen. Bevor du einen Schlüssel oder Token hinzufügst, sieh nach, welche Zugriffe der Server verlangt, und nutze einen Schlüssel, der nur die Berechtigungen hat, die du brauchst.
Die Registry nennt keinen erforderlichen Schlüssel, manche Server bitten dich aber bei der ersten Nutzung, dich anzumelden.
Er läuft in der Cloud des Entwicklers. Du verbindest dich übers Internet, ohne etwas zu installieren, aber was du sendest, läuft über die Server des Entwicklers.
Das GitHub-Repo wurde zuletzt – geändert, und die neueste Version (1.0.0) kam vor 4 Monaten in die Registry.
Apps, die MCP unterstützen, etwa Claude Desktop, Claude Code, Cursor und VS Code. Er verbindet sich per URL, also funktionieren auch Apps, die Remote-MCP-Server akzeptieren, zum Beispiel ChatGPT im Entwicklermodus.
In derselben Kategorie: Spec Driven Development, Remote Desktop Commander, AI Deprecations
Server derselben Kategorie von anderen Entwicklern, sortiert nach Sternen.
So liest du eine Karte:★ GitHub-SterneiDrei Säulen: Bewertungen · Checks · NutzungiAktualisiert = neueste Version in der Registry veröffentlichti
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
AI model shutdown dates, replacements, change feed and webhook alerts for 8 providers.
Unverändert aus dem Repo des Entwicklers übernommen. PopNx MCP hat den Inhalt weder geprüft noch empfiehlt es ihn. HTML, Bilder und Skripte wurden entfernt. Links führen von dieser Website weg.
*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
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.
GATEWAY_SECRET. Bearer tokens are stored only as SHA-256 hashes.garmin_mcp worker bound to 127.0.0.1, started on demand and reaped when idle.garmin_mcp worker pinned to a reviewed commit./ and as a friendly fallback for unknown paths.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.
uv pip install -e ".[dev]"
uv run --extra dev pytest -q # run the test suite
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.
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/mcpSign 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/mcpSign 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/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).
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.
claude mcp add --transport http garmin https:// /garmin/mcp (whoop: claude mcp add --transport http whoop https:// /whoop/mcp; car: .../car/mcp).Set via environment (or .env). See .env.example.
| Variable | Required | Default | Description |
|---|---|---|---|
GATEWAY_SECRET | yes | — | ≥32-char key for token encryption. Refuses to start with the placeholder. Generate with openssl rand -base64 48. |
PUBLIC_URL | yes | http://localhost:8080 | Public URL used in OAuth metadata + redirects. |
PORT | no | 8080 | Listen port. |
DATA_DIR | no | /data | Where the SQLite DB and per-user token dirs live. |
DB_PATH | no | $DATA_DIR/gateway.db | Override the DB path. |
GARMIN_MCP_CMD | no | garmin-mcp | Command to spawn the worker. Use a uvx … invocation when garmin-mcp isn't on PATH. |
GARMIN_MCP_REF | no | pinned SHA in Dockerfile | Docker build arg: commit of garmin_mcp to install. Bumping it is a deliberate, reviewed action — afterwards run python scripts/gen_garmin_tools.py to refresh the tool listing on the /garmin page. |
WORKER_PORT_START / WORKER_PORT_END | no | 9000 / 9099 | Port range for per-user workers. |
WORKER_IDLE_TTL | no | 900 | Seconds before an idle worker is reaped. |
WORKER_STARTUP_TIMEOUT | no | 20 | Seconds to wait for a worker to become healthy. |
MAX_WORKERS | no | 10 | Max concurrent per-user workers. |
GARMIN_MCP_STATELESS_HTTP | no | true | Run garmin workers' Streamable HTTP without MCP sessions (passed to every worker explicitly). A replaced worker (eviction, idle reap, crash, deploy) then still serves the client's old Mcp-Session-Id instead of answering 404 "Session not found"; the gateway answers GET/DELETE on /garmin/mcp with 405 itself. false is the rollback switch (session-ful workers, GET/DELETE forwarded). Accepts true/false, 1/0, yes/no, on/off (case-insensitive; empty = default); any other value stops the gateway at startup. |
SSO_PROBE_INTERVAL | no | 0 (off) | Seconds between browser-impersonated GET probes of Garmin's SSO embed widget, once per sign-in egress (event sso-probe, fields via, egress_ip — the egress's real outgoing IP via cdn-cgi/trace; plus egress-health per egress: real sign-in outcomes since the previous run, since the GET can't see a blocked credential POST; egress-ip-changed when an egress's IP changes, floor 60 s) — an attempt-independent block timeline for diagnosing egress-IP rate-limiting (reliability ticket 12). |
| 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, `
Nur der Anfang wird gezeigt; den Rest findest du im Repo