Delx Wellness

Start here

Agents should start with agent_manifest, connection_status or capabilities when a connector exposes them. Humans should start with the Hermes or OpenClaw profile packs when they want the whole stack installed as one local-first wellness agent.

✨ The 11 connectors

Each connector is a standalone npm package. Install one or all eleven — they coexist and the agent reconciles overlapping signals (WHOOP, Garmin, Apple Health, Samsung Health and Google Health all reporting sleep, etc.).

🚀 Quick Start — one command for the whole stack

The fastest path is a profile pack. One command creates a local-first wellness profile with onboarding, skills, MCP presets and setup checks for all 11 connectors:

npx -y delx-wellness-hermes setup
hermes -p delx-wellness

For OpenClaw:

npx -y delx-wellness-openclaw setup
openclaw --profile delx-wellness agent --local --message "Open Delx Wellness onboarding"

That's it. The setup wizard walks you through choosing which providers to wire up, checks the local Nourish preset (no OAuth required), and prints the next commands for model setup and per-provider auth.

📦 delx-wellness-hermes and delx-wellness-openclaw are the first runtime-native profile packs — they preconfigure everything below so you don't have to glue 11 MCP configs by hand.

🔌 Or wire connectors individually

Each connector is a standalone npm package with its own guided setup CLI — use this path when you want to drop a single provider into Claude Desktop, Cursor, ChatGPT Desktop or any other MCP client.

npx -y whoop-mcp-unofficial         setup && npx -y whoop-mcp-unofficial         auth
npx -y oura-mcp-unofficial          setup && npx -y oura-mcp-unofficial          auth
npx -y garmin-mcp-unofficial        setup && npx -y garmin-mcp-unofficial        auth --install-helper
npx -y strava-mcp-unofficial        setup && npx -y strava-mcp-unofficial        auth
npx -y fitbit-mcp-unofficial        setup && npx -y fitbit-mcp-unofficial        auth
npx -y google-health-mcp-unofficial setup && npx -y google-health-mcp-unofficial auth
npx -y withings-mcp-unofficial      setup && npx -y withings-mcp-unofficial      auth
npx -y apple-health-mcp-unofficial  setup --export-path /path/to/export.zip
npx -y samsung-health-mcp-unofficial setup --export-path /path/to/SamsungHealth
npx -y polar-mcp-unofficial         setup && npx -y polar-mcp-unofficial         auth
npx -y wellness-nourish             manifest

Then drop one of the client config examples into your AI client:

🏗️ How it fits together

flowchart LR
    subgraph A[" Your AI Agent "]
      direction LR
      Claude[Claude]
      Cursor[Cursor]
      Hermes[Hermes]
      OpenClaw[OpenClaw]
      ChatGPT[ChatGPT Desktop]
    end

    subgraph L[" Local on your machine "]
      direction TB
      MCP[profile pack<br/>or standalone MCP configs]
      W[whoop-mcp]
      O[oura-mcp]
      G[garmin-mcp]
      S[strava-mcp]
      F[fitbit-mcp]
      GH[google-health-mcp]
      Wi[withings-mcp]
      AH[apple-health-mcp]
      SH[samsung-health-mcp]
      P[polar-mcp]
      N[nourish]
    end

    subgraph P2[" Provider APIs "]
      direction TB
      WHOOP[WHOOP API]
      OURA[Oura API]
      GARMIN[Garmin Connect]
      STRAVA[Strava API]
      FITBIT[Fitbit API]
      GOOGLE[Google Health API]
      WITHINGS[Withings API]
      AHE[Apple Health export.zip]
      SHE[Samsung Health CSV export]
      POLAR[Polar Accesslink]
      LOCAL[Local food DB]
    end

    A --> MCP
    MCP --> W & O & G & S & F & GH & Wi & AH & SH & P & N
    W --> WHOOP
    O --> OURA
    G --> GARMIN
    S --> STRAVA
    F --> FITBIT
    GH --> GOOGLE
    Wi --> WITHINGS
    AH --> AHE
    SH --> SHE
    P --> POLAR
    N --> LOCAL

    style L fill:#0F172A,stroke:#0EA5A3,color:#fff
    style A fill:#0F172A,stroke:#10B981,color:#fff
    style P2 fill:#0F172A,stroke:#7C3AED,color:#fff

🧭 Which connector should I install first?

Have a WHOOP?              → start with whoop-mcp        (recovery, HRV, sleep, strain)
Have a Garmin?             → start with garminmcp        (Body Battery, training readiness, HRV)
Have an Oura?              → start with ouramcp          (readiness, sleep, activity, HRV)
Have Withings devices?     → start with withingsmcp      (body measures, sleep, activity, heart)
Have an Apple Health export?→ add apple-health-mcp       (local export activity, sleep, HRV, workouts)
Have a Galaxy Watch export? → add samsung-health-mcp     (local CSV activity, sleep, HRV, workouts)
Have a Polar device?       → start with polarmcp         (Nightly Recharge, training load, PPI/HRV)
Run/ride/swim a lot?       → add strava-mcp              (activities, streams, routes)
Just bought a Fitbit?      → add fitbitmcp               (activity, sleep, heart, HRV)
Migrating Fitbit to Google?→ add google-health-mcp       (Google Health API v4, rollups, reconciled streams)
Tracking food?             → add wellness-nourish        (food search, barcode lookup, intake, hydration)
Multiple devices?          → install several. Each is independent and read-only.

The connectors are designed to coexist. When two providers cover the same signal (e.g. WHOOP and Garmin both report sleep), each tool returns provider-tagged data and your agent reconciles them.

💡 Why local-first?

Your wearable data is the most personal context an agent can have — sleep stages, heart rhythm, recovery scores, what you ate. Sending all of that through a hosted vault you don't control is the wrong default.

Delx Wellness flips it:

• 🔒 Tokens stay on your machine. OAuth completes locally; refresh tokens live in your OS keychain or a ~/.config file you own.
• 📖 Read-only by design. Every connector is read-only. There is no "write to your Apple Health" tool, no surprise side effects.
• 🧱 Standalone packages. Each connector is a separate npm package with a clear scope. Audit one without auditing nine.
• 🤝 Vendor-neutral. You can mix providers, swap one out, or remove all of them without anything breaking on a hosted side.
• 🌐 No phone-home. No analytics, no telemetry, no usage reporting baked into the connectors themselves.

The hosted commercial layer (token vault, billing, rate limits) may stay private — but the connectors that touch your data are open source, on this registry, forever.

📊 Open-source boundary

Tiers and trust levels are defined in docs/connector-quality-standard.md. Machine-readable catalog: registry.json.

📚 Reference docs

• Connector quality standard — release and trust checklist
• Registry validation — what the context_ready CI validator enforces and how to extend it
• Provider status — current matrix and risks
• Privacy model — local-first privacy boundary and hosted-hub considerations
• Normalized schema — shared cross-provider wellness snapshot shape
• Growth playbook and MCP directory submissions — ecosystem ops

⚠️ What this is not

• Not a medical device.
• Not medical advice, diagnosis, treatment or emergency support.
• Not a promise that every future hosted product will be open source.
• Not a place for real user health exports, OAuth tokens, API secrets or private deployment files.

🧭 Direction

The practical near-term path:

1. Keep provider MCPs independently installable.
2. Use this repository as the public connector registry and documentation hub.
3. Define shared normalized schemas before building cross-provider tools.
4. Keep hosted/commercial infrastructure private until the product direction is proven.

👤 Built by

David Batista — founder of Delx, building protocol layers for autonomous AI agents.

Follow on X: @delx369 · Site: wellness.delx.ai

📜 License

MIT — see LICENSE.

Delx Wellness is an open-source project. WHOOP, Oura, Garmin, Strava, Fitbit, Google Health, Withings, Apple Health, Samsung Health and Polar are trademarks of their respective owners. None of the connectors in this registry are affiliated with, endorsed by, or supported by those companies.