u/delxmobile

I spent the last few months building an open-source side project around a problem I kept hitting personally: my health data was split across WHOOP, Garmin, Oura, Strava, Fitbit, Apple Health, Withings, Eight Sleep, and a few other tools, but AI agents could not use that context without me copy/pasting screenshots or exporting CSVs.

So I built Delx Wellness: a catalog of local-first MCP servers for wearable and wellness data.

What exists now:

• MCP servers for WHOOP, Oura, Garmin, Strava, Fitbit, Withings, Apple Health, Samsung Health, Polar, Google Health, Eight Sleep, Dexcom CGM, indoor air quality, cycle coaching, and nutrition logging
• each connector runs locally, usually via npx
• OAuth/token files stay on your machine under ~/.<vendor>-mcp/
• shared profile file at ~/.delx-wellness/profile.json so connectors can reuse goals/devices/preferences
• read-only defaults for sensitive integrations; mutations are gated where they exist
• docs/site with all connectors in one place

The use case I care about most is asking an agent things like:

> Should I train hard today, given my recent sleep, recovery, HRV, training load, and indoor air quality?

The biggest lesson so far: shipping 15 connectors got the ecosystem broad, but it also made positioning harder. Developers understand MCP immediately; normal wearable users usually do not. I am trying to decide whether the landing page should lead with “local-first wellness data for AI agents” or with concrete workflows like training readiness / sleep review / nutrition logging.

Project: https://wellness.delx.ai Registry: https://github.com/davidmosiah/delx-wellness

I would love feedback from other builders: does this read like a useful project, or is the scope too broad for people to understand quickly?

I built Nourish, an open-source MCP server for nutrition workflows that agents can use without pretending food estimates are perfect.

The core shape:

- food search through USDA/Open Food Facts

- local meal estimates with confidence, unresolved foods, warnings, and source attribution

- barcode lookup and barcode photo workflows

- photo-assisted meal estimation from agent-provided observations

- hydration, goals, daily/weekly summaries, exports, and undo/edit flows

- carbon footprint context for logged meals

- explicit user confirmation before mutating personal logs

The thing I care about most is agent behavior: estimate first, preserve uncertainty, then log only after the user confirms. It is meant to be nutrition infrastructure for agents, not just a calorie app with an API.

Still pre-1.0 while dataset/licensing details mature, but the package is live and usable.

GitHub: https://github.com/davidmosiah/wellness-nourish

Docs: https://wellness.delx.ai/nutrition

NPM: https://www.npmjs.com/package/wellness-nourish

Feedback from MCP builders would be very useful.I built Nourish, an open-source MCP server for nutrition workflows that agents can use without pretending food estimates are perfect.

The core shape:

- food search through USDA/Open Food Facts

- local meal estimates with confidence, unresolved foods, warnings, and source attribution

- barcode lookup and barcode photo workflows

- photo-assisted meal estimation from agent-provided observations

- hydration, goals, daily/weekly summaries, exports, and undo/edit flows

- carbon footprint context for logged meals

- explicit user confirmation before mutating personal logs

The thing I care about most is agent behavior: estimate first, preserve uncertainty, then log only after the user confirms. It is meant to be nutrition infrastructure for agents, not just a calorie app with an API.

The package is live and usable today. Dataset and licensing details are still being tightened before a stable 1.0 tag.

GitHub: https://github.com/davidmosiah/wellness-nourish

Docs: https://wellness.delx.ai/nutrition

NPM: https://www.npmjs.com/package/wellness-nourish

Feedback from MCP builders would be very useful.

Disclosure: I built and maintain this.

I just shipped an OpenClaw-native profile pack for Delx Wellness. It writes an OpenClaw profile, workspace docs, skills, and MCP server config for a local-first wellness connector stack.

It wires 11 MCP servers:

• WHOOP
• Garmin
• Oura
• Strava
• Fitbit
• Google Health
• Withings
• Apple Health export
• Samsung Health
• Polar
• Nourish nutrition

Why I made it:

• MCP health/wearable connectors are fragmented across clients
• agents need capability metadata before touching personal data
• OpenClaw profiles need repeatable setup instead of copy/paste config drift

What it includes:

• npx -y delx-wellness-openclaw setup
• OpenClaw config under mcp.servers
• workspace onboarding docs and skills
• doctor command that validates the profile and runs OpenClaw checks
• examples for Cursor, Claude Code and Codex in the registry

GitHub: https://github.com/davidmosiah/delx-wellness-openclaw

Registry: https://github.com/davidmosiah/delx-wellness

Docs: https://wellness.delx.ai/openclaw

Not medical advice, not a medical device. I am mainly looking for feedback on the MCP contract and the OpenClaw setup shape: is this the right direction for client-native MCP profile packs?

Disclosure: I built and maintain this.

I’ve been working on a local-first wellness MCP stack and wanted a cleaner discovery surface for agents instead of one-off tool wiring. The registry is a public catalog of wearable/nutrition MCP connectors with setup metadata, provider status, and agent-facing expectations.

Repo: https://github.com/davidmosiah/delx-wellness

The pattern I’m testing:

• agent_manifest for discovery
• connection_status before data tools
• privacy_audit before health data access
• summary/context tools instead of raw blobs
• docs that work for Claude/Codex/Cursor/Hermes-style clients

It is not medical advice or a medical device. I’m sharing here because MCP tool discovery is starting to overlap with LangChain-style agent/tool workflows, and I’d appreciate feedback on the connector metadata shape.

Disclosure: I built and maintain this.

I wanted an MCP connector that lets a local AI agent inspect WHOOP recovery, strain, sleep and HRV context without copying raw health data into chat, so I built an unofficial local-first WHOOP MCP server.

Repo: https://github.com/davidmosiah/whoop-mcp

What it exposes:

• MCP tools for recovery, sleep, strain, workouts and summary context
• agent-facing manifest, connection_status and privacy_audit tools
• local setup/auth flow, no hosted token vault
• stdio and Streamable HTTP transports
• tests/smokes for CLI, HTTP, Hermes/agent manifest and metadata

It is unofficial, read-only by default, and not a medical device or medical advice. I would appreciate feedback from people building MCP workflows: what tool shape or context format would make this easier for agents to use?

Disclosure: I'm the maintainer.

I just published Delx Wellness, a canonical site/registry for local-first MCP connectors that let agents use wearable/wellness data without handing provider tokens to the model.

Site: https://wellness.delx.ai GitHub hub: https://github.com/davidmosiah/delx-wellness

Current public connectors:

• WHOOP: recovery, HRV, sleep, strain, workouts
• Oura: readiness, sleep, activity, HRV, SpO2
• Garmin: Body Battery, training readiness, sleep, HRV, stress, activities
• Strava: activities, segments, streams
• Fitbit: activity, sleep, intraday heart, HRV
• Withings: scale/body composition, sleep, heart records
• Apple Health: local export.zip parsing
• Polar: Nightly Recharge, training load, PPI/HRV, samples

The design choice is local-first: each connector runs as its own MCP server/npm package. The website is the registry/docs layer, not a hosted OAuth proxy. Tokens stay in local config directories such as ~/.whoop-mcp, ~/.oura-mcp, and ~/.garmin-mcp, and agents get MCP responses rather than raw secrets.

I also made the site agent-readable: robots/content signals, sitemap, markdown negotiation, MCP server card, API catalog, agent skills index, WebMCP tools, plus llms.txt/llms-full.txt.

I'd love feedback from MCP builders on:

• whether this registry-first approach is the right shape vs a hosted hub
• which connector docs are still missing for agent clients
• what you expect from an "agent-ready" MCP connector standard

Not affiliated with WHOOP/Oura/Garmin/etc, and definitely not medical advice. Just trying to make wearable context usable by agents in a sane way.

Disclosure: I built this project.

I’ve been exploring a simple idea: wearable data should not only live in dashboards. With user permission, it should become private context that an AI agent can reason over.

So I built Fitbit MCP, an unofficial open-source MCP server for the Fitbit Web API.

What it does:

- Connects through Fitbit OAuth2

- Keeps tokens local under ~/.fitbit-mcp

- Exposes 25 MCP tools, 6 resources and 3 prompts

- Supports sleep, HRV, heart rate, activity, weight and nutrition data where Fitbit provides it

- Has privacy modes: summary, structured and explicit raw JSON

- Includes agent-facing setup/doctor flows for Claude, Cursor, Hermes, OpenClaw and generic MCP clients

Links:

GitHub: https://github.com/davidmosiah/fitbitmcp

npm: https://www.npmjs.com/package/fitbit-mcp-unofficial

Landing page: https://fitbitmcp.vercel.app

Important boundaries:

- Unofficial, not affiliated with Fitbit or Google

- Uses the official Fitbit Web API

- Not medical advice

- Does not expose raw device telemetry beyond what Fitbit’s API makes available

I’d love feedback from the MCP community on tool design, privacy defaults, and what health/wearable summaries would actually be useful for agents.

Hey r/Strava, I’m a Strava user and developer.

I built a free, unofficial open-source MCP server that lets AI agents/tools connect to your own Strava data through the official OAuth API.

What it supports:

- activities and activity details

- activity streams: time, distance, heart rate, cadence, watts, altitude, optional GPS when explicitly requested

- routes, clubs, gear, athlete profile, zones and aggregate stats

- daily/weekly training summaries for agents

- local OAuth tokens stored on your machine

- privacy modes: summary, structured, raw

- Claude, Cursor, Hermes, OpenClaw and other MCP clients

This is not affiliated with or endorsed by Strava. No paid product, no write/upload scope by default, and not medical or coaching advice. I’m sharing because I think agent-native access to personal training data can be useful if it is done with clear privacy boundaries.

Website: https://stravamcp.vercel.app/

GitHub: https://github.com/davidmosiah/strava-mcp

npm: https://www.npmjs.com/package/strava-mcp-unofficial

Would love feedback from anyone here who builds with Strava data, trains with AI tools, or wants better personal dashboards/agents.

I built an unofficial open-source MCP server for WHOOP data.

It lets MCP clients connect to a user’s own WHOOP account through the official OAuth API and expose health/performance data as tools and resources.

Current support:

- profile and body measurements

- cycles, recovery, sleep, workouts

- daily and weekly summaries

- local OAuth token storage

- automatic refresh-token handling

- privacy modes: summary, structured, raw

It is designed for Claude Desktop, Cursor, Windsurf, Hermes, OpenClaw, and generic MCP clients.

Not affiliated with or endorsed by WHOOP. Not medical advice.

GitHub:

https://github.com/davidmosiah/whoop-mcp

Docs:

https://davidmosiah.github.io/whoop-mcp/

npm:

https://www.npmjs.com/package/whoop-mcp-unofficial

Feedback welcome, especially from people building or reviewing MCP servers.