The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Wellness Cgm MCP listing page.
🩸 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
Default is stdio. Optional Streamable HTTP — no session id, JSON responses, loopback only:
Env: WELLNESS_CGM_HOST, WELLNESS_CGM_PORT, WELLNESS_CGM_TRANSPORT=http.
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.
The agent now has 10 CGM tools. Without a Dexcom token, every tool returns synthetic readings tagged mock: true — perfect for prototyping.
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.
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.)
window_truncated_by_provider is structural, not empiricalIt answers "can this provider cover a span this wide?" — never "did this particular read come back short?". A sensor applied two hours ago answers cgm_daily_summary({ hours: 12 }) with hours_covered: 2, window_truncated_by_provider: false and an empty notes, because nothing is broken and warning there would be a false alarm. That is deliberate:
An empty
notesmeans "no known provider ceiling was hit", not "the window was fully covered".hours_coveredis the only number that states the real span — compare it againsthours_requestedbefore reporting any window.
| Tool | Purpose |
|---|---|
cgm_agent_manifest | Runtime contract |
cgm_capabilities | Providers, metrics, privacy modes |
cgm_connection_status | env, credentials, mode (live vs mock) |
cgm_privacy_audit | Local storage + outbound destinations |
cgm_data_inventory | Metric catalog + TIR ranges + GMI formula |
cgm_glucose_now | Most recent EGV + trend |
cgm_glucose_window | All EGVs over last N hours (+ hours_covered — see the Libre ~12h limit) |
cgm_daily_summary | Mean / GMI / CV / 2 TIR profiles — over hours_covered, not the requested window |
cgm_meal_response | Baseline → peak → return + band |
cgm_authorize_url | Dexcom OAuth URL builder |
cgm_hypo_events | Hypo event detection (ADA Level 1 < 70, Level 2 < 54) — "no events" applies to hours_covered only |
cgm_libre_status | FreeStyle Libre (LibreLink Up) config + region + mode — v0.4 |
cgm_libre_login | Log in to LibreLink Up + list followed sensors — v0.4 |
The table omits the shared profile/onboarding/quickstart/demo helpers (
cgm_profile_get,cgm_profile_update,cgm_onboarding,cgm_quickstart,cgm_demo) for brevity — callcgm_agent_manifestfor the full, always-current list.
Agents surface BOTH so the user picks the one that fits their context.
| Peak Δ from baseline | Band |
|---|---|
| < 30 mg/dL | excellent |
| 30-49 | good |
| 50-79 | moderate |
| ≥ 80 | poor |
Combine with wellness-nourish to compute "what did I eat → what happened" automatically.
Levels charges $199/mo for this. Here it is, free, local-first, MCP.
DEXCOM_ACCESS_TOKEN / LIBRELINKUP_* stay in env vars; the LibreLink Up auth token is never returned in tool output.mock: true until a provider is configured.Run wellness-cgm-mcp doctor to inspect.
MIT — see LICENSE.
wellness-cgm-mcp is independent open-source software. Dexcom and FreeStyle Libre are trademarks of their respective owners. Neither company is affiliated with or endorses this project.
Same package, two doors. MCP registers tools on stdio/HTTP. The skill can drive the same tools through the CLI when the client has no MCP:
Copy skill/SKILL.md into your agent skills dir.