delx-living-body

delx-living-body

Meta-MCP，将 15 个健康 MCP 整合为一个统一的身体数据层，供 AI Agent 使用。

如今，要回答“我今天该不该进行高强度训练？”Agent 必须协调 WHOOP 恢复情况、Garmin Body Battery、Oura 睡眠、Nourish 营养数据和经期阶段，跨越五个独立的 MCP 服务。这对用户来说不可靠，对 Agent 来说也令人困惑。

delx-living-body 是一个 MCP 服务，可以：

1. 自动检测你在本地已安装的 15 个 Delx Wellness 连接器，无需手动配置
2. 组合调用并行调用适当的子集
3. 综合生成自然语言答案，以及结构化推理轨迹和各来源的置信度——采用基于规则的推理，不调用大模型

只需安装一次，即可获得统一的身体数据层。可与您已安装的任何健康 MCP 配合使用。

组合矩阵（哪些子项提供 *_series，哪些仅提供摘要）：docs/compose-matrix.md。 固定版本偏移：docs/pin-drift.md。

如果它有助于你的 Agent 工作流，请为仓库点个星。星标有助于其他 AI 开发者发现 Delx Wellness 的单入口方案。

---

HTTP（v2 无状态）

默认使用 stdio。可选的 Streamable HTTP——无会话 ID、JSON 响应，仅限回环地址：

npx -y delx-living-body --http
# GET  http://127.0.0.1:3030/health
# POST http://127.0.0.1:3030/mcp   (sessionless)

环境变量：LIVING_BODY_MCP_HOST、LIVING_BODY_MCP_PORT、LIVING_BODY_MCP_TRANSPORT=http。

• 立即试用，无需账户 — npx -y delx-living-body demo（“我今天该不该进行高强度训练？”）
• 在以下平台运行：Claude · Cursor · ChatGPT · Hermes · OpenClaw — 查看Agent 配置示例
• 本地优先 — delx-living-body 从不读取你的令牌；子连接器会读取各自的凭据（隐私与安全）
• 该使用哪个连接器？ — 从 Delx Wellness 入口页开始

本服务组合使用的三个旗舰连接器：google-health-mcp（google-health-mcp-unofficial）、garmin-mcp（garmin-mcp-unofficial）和 wellness-nourish（wellness-nourish）。

---

安装

npx -y delx-living-body

安装就这么简单。无需 OAuth 流程，也无需 API 密钥——delx-living-body 本身不处理身份验证。每个子连接器会处理自己的凭据。

查看完整的 Agent 演示 →“我今天该努力训练吗？”（无需账号）

npx -y delx-living-body demo

一条命令，无需克隆。演示会启动真实的 MCP 服务，模拟三个已安装的连接器（WHOOP + Oura + Garmin，由内置的存根子进程提供合成身体数据），并通过标准输入输出驱动服务，方式与 Agent 完全相同。无需真实账号、API 密钥或网络。添加 --scenario=red 可查看低准备度（“今天收着点”）路径；运行 demo --help 可列出选项。捕获的输出位于 examples/demo-what-should-i-do-today.txt：

2) living_body_ask  question="What should I do today?"
────────────────────────────────────────────────────────────────
Recommendation:
   Today at a glance: recovery 74, sleep 83, body battery 68.

Confidence: high   Sources: whoop, oura, garmin

3) living_body_ask  question="Should I train hard today?"
────────────────────────────────────────────────────────────────
Recommendation:
   Green light for a hard session. Recovery and sleep both support high intensity.

Confidence: high   Sources: whoop, oura, garmin

Reasoning trace (rule-based, no LLM):
   Intent classified as: training_readiness
   - (rec_high) Recovery 74 supports a high-intensity day.
   - (sleep_good) Sleep score 83 is supporting recovery.

输入一个问题 → 综合三个连接器的数据生成一个答案，并提供稳定的推理轨迹，不调用任何大模型。这是 Body 垂直领域的入口：安装一次，用自然语言提问，即可获得统一答案。

工具（6）

工具	用途
living_body_status	检测到哪些连接器？安全，不会启动子进程。
living_body_ask	主要工具。并行启动已检测到的子进程，返回综合答案。需要 explicit_user_intent: true。
living_body_daily_brief	根据各连接器的 daily_summary 生成 Markdown 简报。
living_body_compose_context	合并各来源，生成标准化的 delx-wellness-context/v1 格式。
living_body_health_check	列出全部 15 个已知连接器，并为缺失的连接器提供安装提示。
living_body_capabilities	自我描述 + 各连接器的可用性矩阵。

检测方式

对于每个已知连接器，delx-living-body 会检查：

1. ~/.<vendor>-mcp/tokens.json 是否存在
2. ~/.<vendor>-mcp/config.json 是否存在（例如 Eight Sleep 这类基于密码的连接器）
3. 供应商环境变量所指向路径中的导出文件（Apple Health、Samsung Health）
4. ~/.delx-wellness/profile.json 是否列出了该设备

任何一项检查通过 → detected。否则 → missing（并提供安装提示）。无状态连接器（Cycle Coach）始终视为可用。

检测结果缓存 60 秒（DELX_LIVING_BODY_DETECT_TTL）。

已知连接器（15）

ID	包	类别
whoop	whoop-mcp-unofficial	恢复
oura	oura-mcp-unofficial	睡眠
garmin	garmin-mcp-unofficial	恢复
strava	strava-mcp-unofficial	训练
fitbit	fitbit-mcp-unofficial	恢复
google_health	google-health-mcp-unofficial	多项
withings	withings-mcp-unofficial	多项
apple_health	apple-health-mcp-unofficial	多项
samsung_health	samsung-health-mcp-unofficial	多项
polar	polar-mcp-unofficial	训练
eight_sleep	eight-sleep-mcp-unofficial	睡眠
nourish	wellness-nourish	营养
air	wellness-air	环境
cycle_coach	wellness-cycle-coach	周期
cgm	wellness-cgm-mcp	血糖

组合流程

运行 living_body_ask 或 living_body_compose_context 时：

1. 检测已安装的连接器。
2. 对每个连接器，通过 StdioClientTransport 使用 npx -y <package> 将其作为子 MCP 启动。
3. 并行调用子进程的 *_wellness_context（或 *_daily_summary）工具。
4. 将结果标准化为 delx-wellness-context/v1 格式，并合并评分。
5. 运行合成器（基于规则，离线运行），生成建议和推理轨迹。

关键是：delx-living-body 从不调用大模型。 合成过程具有确定性，因此下游 Agent 可以基于稳定的推理轨迹进行推理。

合成器规则

共有 14 条启发式规则，每条规则都有一个稳定的 rule_id，并会出现在推理轨迹中：

• rec_low / rec_mid / rec_high — 恢复评分区间
• bb_low / bb_high — Garmin Body Battery 区间
• sleep_poor / sleep_good — 睡眠评分区间
• strain_high — WHOOP strain ≥ 18
• cycle_luteal / cycle_follicular — 周期阶段信号
• load_high / load_low — 综合训练负荷
• no_data — 未安装任何连接器，仅提供参考建议
• conflict — 各来源意见不一致 → 低置信度

隐私与安全

• delx-living-body 绝不会读取子连接器的令牌或配置文件——子连接器会独立读取自己的凭据。
• 启动子进程前，会移除上游的机密环境变量（*_CLIENT_SECRET、*_ACCESS_TOKEN、*_REFRESH_TOKEN、*_API_KEY、*_PASSWORD）。
• 默认以 privacy_mode=structured 启动子进程。只有调用方在 living_body_ask 中设置 explicit_user_intent: true 时，才会遵循 raw。
• 不会逐字记录子进程的响应，只记录计数和摘要字段。
• 每次子进程调用的超时时间：30s。卡住的子进程会被标记为 timeout 并跳过。
• 缓存位于 ~/.delx-living-body/cache.sqlite（chmod 600），TTL 为 5 min。设置 DELX_LIVING_BODY_NO_CACHE=true 可禁用缓存。
• delx-living-body 本身不会主动向外发送数据。

完整的威胁模型请参阅 SECURITY.md。

环境变量

变量	默认值	用途
DELX_LIVING_BODY_DETECT_TTL	60	检测缓存 TTL，单位为秒
DELX_LIVING_BODY_NO_CACHE	未设置	禁用 SQLite 响应缓存
DELX_LIVING_BODY_CACHE_PATH	~/.delx-living-body/cache.sqlite	覆盖缓存路径
DELX_LIVING_BODY_NPM_RUNNER	npx	覆盖用于启动子进程的 npm runner
DELX_LIVING_BODY_CHILD_OVERRIDE_<ID>	未设置	覆盖子进程二进制文件路径（仅用于测试）
LIVING_BODY_MCP_HOST / LIVING_BODY_MCP_PORT	127.0.0.1 / 3030	HTTP 传输绑定地址

CLI

living-body-mcp-server                # MCP stdio server (default)
living-body-mcp-server --http         # Local HTTP transport
living-body-mcp-server doctor         # Detect installed connectors
living-body-mcp-server doctor --json  # JSON output
living-body-mcp-server setup          # Print profile path + install hints
living-body-mcp-server demo           # Zero-secret end-to-end demo (--scenario=red, --help)
living-body-mcp-server version

与 Claude Desktop 搭配使用

{
  "mcpServers": {
    "living-body": {
      "command": "npx",
      "args": ["-y", "delx-living-body"]
    }
  }
}

与 Cursor 搭配使用

{
  "mcpServers": {
    "living-body": { "command": "npx", "args": ["-y", "delx-living-body"] }
  }
}

非医疗建议

输出是供训练／恢复／睡眠／营养 Agent 使用的运行上下文，不用于医疗诊断或临床用途。

许可证

MIT——请参阅 LICENSE。由 David Mosiah 构建。

密集序列

当子连接器提供 *_series 工具（agent-safe-series/v1）时，优先使用它们，而不是原始流转储。

技能还是 MCP

同一个包，两种使用方式。MCP 通过 stdio/HTTP 注册工具。技能 可在客户端不支持 MCP 时，通过 CLI 调用相同的工具：

npx -y delx-living-body call living_body_connection_status --json '{}'

将 skill/SKILL.md 复制到 Agent 技能目录。