claude mcp add wellness-cgm-mcp -- npx -y wellness-cgm-mcp
A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
1 ★ · davidmosiah/wellness-cgm-mcp · read from the repository page · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 1 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository davidmosiah/wellness-cgm-mcp;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
Local-first continuous glucose monitor MCP for AI agents. Dexcom Developer API. Levels-killer pattern, agent-first, $0. 🩸 Why this exists: Levels charges $199/mo to do exactly this — read your CGM, correlate with meals, flag spikes. wellness-cgm-mcp is the same game as a free local-first MCP. Stelo OTC + Dexcom developer API + your agent + wellness-nourish = the full metabolic loop. > ⚡ **One-command install** — pick your runtime: > - Delx Wellness for Hermes: npx -y delx-wellness-hermes setup > - Delx Wellness for OpenClaw: npx -y delx-wellness-openclaw setup --- HTTP (v2 stateless) Default is **stdio**. Optional Streamable HTTP — no session id, JSON responses, loopback only: Env: WELLNESS_CGM_HOST, WELLNESS_CGM_PORT, WELLNESS_CGM_TRANSPORT=http. Overview Local MCP server that exposes CGM data (and synthetic mock data when nothing is configured) to any MCP-aware agent. Two real backends are supported: **Dexcom** (Developer API, sandbox + production) and **FreeStyle Libre** (the OTC sensor — Libre 2 / Libre 3) via **LibreLink Up**. Pick the backend with CGM_PROVIDER; it auto-detects Libre when only Libre credentials are set. Both feed the same ADA time-in-range / GMI / hypo / meal-response engine. Try It In 60 Seconds (mock mode, zero setup) The agent now has 10 CGM tools. Without a Dexcom token, every tool returns synthetic readings tagged mock: true — perfect for prototyping. Live setup (Dexcom Developer) Live setup (FreeStyle Libre — the OTC sensor) No developer program, no app to build — just the **same email/password you use in the LibreLinkUp follower app** (the OTC Libre 2 / Libre 3 sensor works). In the LibreLink app, share your readings; in the LibreLinkUp app, accept the invite. Then: Once logged in, every glucose tool (cgm_glucose_now, cgm_daily_summary, cgm_time_in_range, cgm_meal_response, cgm_hypo_events, …) reads from Libre and returns the same ADA TIR / GMI / hypo / meal-response metrics — each response carries a provider field so you always know the source. Without any credentials, everything returns synthetic mock: true data. Libre history limit: ~12h per read LibreLink Up's graph endpoint takes **no start/end parameter** — it always answers with its own fixed trailing window of roughly **12 hours**. Asking for 24h or 72h does not widen it, so on Libre those extra hours simply do not exist. Every windowed payload therefore reports what it actually covered: Read hours_covered, never the requested hours / window_hours. A GMI (estimated A1C), CV or time-in-range built on 12h is not a 3-day result. **For multi-day metrics use Dexcom**, whose v3 API takes an explicit start/end and honours the request. Mock mode synthesises the full requested span, so it is never truncated. The same applies to cgm_hypo_events, which takes an explicit from/to: "no hypoglycemia events" is only a claim about hours_covered. A 3-day question answered from a live Libre read is a 12-hour answer, and the payload says so in hours_covered, observed_window.hours, window_truncated_by_provider and notes. (events_per_day is safe either way — its denominator is the observed span, not the requested one — but the frame around it is not.)