What can you do with this server?

The Wellness CGM MCP server provides a local-first interface for AI agents to access and analyze continuous glucose monitor (CGM) data from Dexcom and FreeStyle Libre sensors, with synthetic mock data for prototyping. Key capabilities: * Glucose Data Access: Retrieve most recent glucose value and trend, or historical readings over 1–72 hours. * Daily Summaries: Compute mean, median, min/max, standard deviation, Glucose Management Indicator (GMI), Coefficient of Variation (CV), and Time-In-Range (TIR) for diabetic (70–180 mg/dL) and metabolic health (70–140 mg/dL) profiles. * Hypoglycemia Detection: Identify and summarize low-glucose events based on customizable thresholds (e.g., ADA Level 1 and 2) with duration, recovery, and recommendations. * Meal Response Assessment: Analyze glucose response to a meal (baseline, peak, delta, and rating band from excellent to poor). * Custom Time-In-Range: Calculate TIR, time below, and time above range for specific time windows (e.g., overnight, post-meal). * Provider Management: Connect to Dexcom via OAuth or FreeStyle Libre via LibreLink Up; check connection status; log in and list sensors. * Onboarding & Profile: Guide users through onboarding questions and maintain a personalized wellness profile (diabetes type, goals, preferences) to tailor responses. * Privacy & Transparency: Audit local storage and outbound data flows, review supported metrics/formulas, and access the full agent manifest. * Development Support: Use mock mode for testing without real credentials, view example payloads, and follow a quickstart guide to go live.

Which integrations are available for this server?

Provides continuous glucose monitoring (CGM) data from FreeStyle Libre sensors via LibreLink Up, including glucose readings, trend analysis, daily summaries, time-in-range, meal responses, and hypo events.

Wellness CGM MCP

by davidmosiah

Overview Schema Related Servers Score Discussions

TypeScript

Remote

⚡ 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:

npx -y wellness-cgm-mcp --http
# GET  http://127.0.0.1:3000/health
# POST http://127.0.0.1:3000/mcp   (sessionless)

Env: WELLNESS_CGM_HOST, WELLNESS_CGM_PORT, WELLNESS_CGM_TRANSPORT=http.

Related MCP server: Polar MCP

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)

npx -y wellness-cgm-mcp doctor       # see env / mode
npx -y wellness-cgm-mcp status

# In Claude Desktop / Cursor / etc., add:
# {
#   "mcpServers": {
#     "wellness-cgm": {
#       "command": "npx",
#       "args": ["-y", "wellness-cgm-mcp"]
#     }
#   }
# }

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)

# 1. Sign up at https://developer.dexcom.com (sandbox is free)
# 2. Create an app, register your redirect URI
export DEXCOM_ENV=sandbox
export DEXCOM_CLIENT_ID=...
export DEXCOM_CLIENT_SECRET=...
export DEXCOM_REDIRECT_URI=https://your.callback/redirect

# 3. Get the OAuth URL, open it, grant access, copy the code from the redirect
npx -y wellness-cgm-mcp authorize

# 4. Swap code for tokens
npx -y wellness-cgm-mcp exchange <auth_code_from_redirect>

# 5. Set DEXCOM_ACCESS_TOKEN to the access_token, restart the MCP — flips from mock to live.

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:

export CGM_PROVIDER=libre               # or just set the creds below and let it auto-detect
export LIBRELINKUP_EMAIL=you@example.com
export LIBRELINKUP_PASSWORD=...
# Optional: region shard if you're not on EU/global, and a pinned sensor:
export LIBRELINKUP_REGION=us            # eu (default) | us | de | fr | au | jp ...
# export LIBRELINKUP_PATIENT_ID=<id>    # only if you follow more than one sensor

# Verify credentials + list the sensor(s) you follow (never prints the token):
npx -y wellness-cgm-mcp libre-login

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:

// cgm_daily_summary({ hours: 72 }) on live Libre
{
  "window_hours": 72,          // what you asked for
  "hours_covered": 12,         // what the numbers below are ACTUALLY computed over
  "observed_window": { "start": "…", "end": "…", "hours": 12 },
  "window_truncated_by_provider": true,
  "notes": ["LibreLink Up returns ~12h of graph data per read and ignores wider spans; requested 72h, covered 12h. …"]
}

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 empirical

It 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 notes means "no known provider ceiling was hit", not "the window was fully covered". hours_covered is the only number that states the real span — compare it against hours_requested before reporting any window.

Tools (19)

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 — call cgm_agent_manifest for the full, always-current list.

Two Time-In-Range profiles in every summary

Diabetic (70-180 mg/dL) — ADA standard for adults with diabetes.
Metabolic health (70-140 mg/dL) — Levels-style for non-DM users.

Agents surface BOTH so the user picks the one that fits their context.

Meal response bands

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.

The killer combo

wellness-nourish: meal at 13:15 (rice + chicken)
       ↓
wellness-cgm-mcp.cgm_meal_response(meal_time)
       ↓
{ peak: 167, peak_delta: 72, band: "moderate", peak_time_minutes: 45 }
       ↓
whoop-mcp.recovery: 67%
       ↓
Agent: "That meal hit a moderate spike (peak +72 mg/dL at 45 min)
        AND recovery is borderline. Try protein-first next time, or
        swap white rice for lentils — should drop the peak ~30 mg/dL."

Levels charges $199/mo for this. Here it is, free, local-first, MCP.

Privacy

✅ Credentials local only — DEXCOM_ACCESS_TOKEN / LIBRELINKUP_* stay in env vars; the LibreLink Up auth token is never returned in tool output.
✅ Mock mode by default — every tool returns synthetic data with mock: true until a provider is configured.
✅ No third-party telemetry — outbound calls go only to your CGM provider (Dexcom or, for Libre, Abbott's LibreLink Up API).

Run wellness-cgm-mcp doctor to inspect.

Roadmap

✅ v0.4 — FreeStyle Libre via LibreLink Up (the OTC sensor). Shipped.
next — Refresh-token rotation. Per-meal historical browser (which foods spike YOU?). Threshold alerts (agent notified when glucose holds > X mg/dL for Y minutes). Cross-meal automation with wellness-nourish.

What this is NOT

Not medical advice or diagnosis.
Not for insulin/medication dosing decisions — defer to clinician.
Not affiliated with Dexcom or Abbott.

📧 Contact & Support

📨 support@delx.ai — general questions, integration help, partnerships
🐛 Bug reports / feature requests — GitHub Issues
🐦 Updates — @delx369 on X
🌐 Site — wellness.delx.ai

License

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.

Available Tools

2 tools

cgm_agent_manifestCGM agent manifestA

Returns the wellness-cgm-mcp agent manifest: tool list, supported clients, env vars, recommended first calls, capabilities, privacy posture, and community links.

ParametersJSON Schema

Name	Required	Description	Default
`client`	No

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It explains what the tool returns (list of tools, clients, env vars, etc.), which is sufficient for a read-only manifest retrieval. Could mention auth needs, but not critical.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the main action and lists contents. It is concise, though a bullet list might improve readability for the enumerated items.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose and output but omits the optional 'client' parameter. Given the tool's simplicity and lack of output schema, this gap reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one optional parameter 'client' with a clear enum, but the description does not mention or explain this parameter. With 0% schema description coverage, the description fails to add meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the agent manifest and enumerates its contents (tool list, supported clients, etc.). It distinguishes from sibling tools which are specific CGM operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for getting the manifest, but provides no explicit guidance on when to use it versus alternatives. No exclusions or when-not-to-use are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

cgm_data_inventoryCGM data inventoryB

Returns the metric catalog plus thresholds (TIR ranges, GMI formula reference).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden for behavioral disclosure. It only states what is returned, but does not mention side effects, authentication needs, rate limits, error conditions, or data freshness. The implied read-only behavior is not explicitly confirmed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the key information. No redundant words. Every word adds value, making it highly efficient for an AI agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the zero-parameter, no-output-schema profile, the description covers the essential purpose. However, it would benefit from a hint about the output format (e.g., structured vs. plain text) or intended use-case (e.g., retrieving thresholds for calculations). Still, it is adequate for a simple inventory retrieval.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and 100% schema coverage, so the description does not need to add parameter-specific meaning. The baseline of 3 applies, but the simplicity of a parameterless call justifies a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a metric catalog and thresholds (TIR ranges, GMI formula reference). The verb 'returns' and resource 'metric catalog plus thresholds' provide a specific purpose. However, it does not explicitly distinguish from siblings like cgm_capabilities or cgm_agent_manifest.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., cgm_capabilities). The description lacks context about whether it's for initial setup, ongoing reference, or exploration. No when-not-to-use information is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation5/5

The two tools have clearly distinct purposes: one returns the server manifest (tool list, clients, env vars), and the other returns the metric catalog with thresholds. There is no overlap, so an agent can easily distinguish them.

Naming Consistency5/5

Both tool names follow the consistent pattern of 'cgm_' prefix followed by a descriptive noun in snake_case ('agent_manifest', 'data_inventory'). This is uniform and predictable.

Tool Count2/5

With only 2 tools, the server feels very thin for a domain like 'Wellness CGM', which typically requires data ingestion, querying, analysis, and alerts. The tools are purely informational, suggesting a very limited scope.

Completeness1/5

The server lacks any tools for actual CGM data access, analysis, or management. For a server named 'Wellness CGM', the omission of core functionality like fetching glucose readings or managing trends is a severe gap.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Related MCP Connectors

anythingmcp A
io.github.keysersoft
Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Agent Orchestration Data Platforms App Automation
42191
Agentverse Memory
io.github.fetchai
Graph-native persistent memory for AI agents — 33 MCP tools, zero-LLM writes.
Knowledge & Memory Autonomous Agents
2
nexusOAuth
com.civic
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Agent Orchestration Developer Tools App Automation
2
Hail
io.github.hail-hq
Phone, SMS & email for AI agents — one remote MCP endpoint, OAuth login, zero install.
Communication Email Agent Orchestration
226

Related MCP Servers

Fitbit MCP
Health & Wellness Fitness Tracking
davidmosiah
A
license
A
quality
A
maintenance
Local-first MCP server that connects AI agents to your Fitbit activity, sleep, heart-rate, HRV, SpO2 and weight data.
Updated 19 days ago (2026-08-15 15:44 UTC)
33
163
1
MIT
Polar MCP
Health & Wellness Fitness Tracking
davidmosiah
A
license
B
quality
A
maintenance
Local-first MCP server that connects AI agents to your Polar training, sleep, Nightly Recharge and continuous-sample data.
Updated 19 days ago (2026-08-15 15:32 UTC)
37
215
5
MIT
Dexcom MCP Server
Health & Wellness Biology & Medicine
cykj40
A
license
Not graded
quality
C
maintenance
A Model Context Protocol (MCP) server that connects Claude to your personal Dexcom CGM (Continuous Glucose Monitor) for assistive diabetes management intelligence.
Updated 2 months ago (2026-07-18 11:26 UTC)
MIT
mcp-server-dexcom-health
Health & Wellness Biology & Medicine
IshaanRSharma
A
license
A
quality
D
maintenance
MCP server for Dexcom CGM glucose data, enabling AI agents to access and analyze continuous glucose monitor readings for health intelligence applications.
Updated 6 months ago (2026-02-23 09:04 UTC)
10
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/wellness-cgm-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

HTTP (v2 stateless)

Overview

Try It In 60 Seconds (mock mode, zero setup)

Live setup (Dexcom Developer)

Live setup (FreeStyle Libre — the OTC sensor)

Libre history limit: ~12h per read

window_truncated_by_provider is structural, not empirical

Tools (19)

Two Time-In-Range profiles in every summary

Meal response bands

The killer combo

Privacy

Roadmap

What this is NOT

📧 Contact & Support

License

Available Tools

TDQS

TDQS

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Fitbit MCP

Polar MCP

Dexcom MCP Server

mcp-server-dexcom-health

Latest Blog Posts

MCP directory API

`window_truncated_by_provider` is structural, not empirical