io.github.davidmosiah/withingsmcp

Inventory supported Withings data domains, auth scope requirements, privacy boundary and recommended first calls. Does not call Withings APIs or expose user data.

Machine-readable install, runtime and client guidance for AI agents. Does not call Withings or expose secrets.

Explain supported Withings data, privacy boundaries, recommended agent workflow and project links.

Personalized 3-step setup walkthrough for the human user. Adapts to current state (env vars set? token present? what's next?). Call this first when the user asks 'how do I connect Withings?'

Returns realistic example payloads of withings_daily_summary, withings_wellness_context, and withings_list_body_measures so agents see the contract before calling real Withings APIs.

Generate a Withings OAuth authorization URL. Use this first when no local token exists.

Exchange a Withings OAuth authorization code for local tokens using Withings signed request flow. Tokens are stored locally and never returned. Requires explicit user action: the user must complete browser OAuth and supply the authorization code (agents must not invent codes).

Check local Withings config, token file, Node version, privacy mode, cache readiness and optional MCP client readiness without calling Withings or exposing secrets.

Show optional local SQLite cache status. Enable with WITHINGS_CACHE=sqlite or WITHINGS_CACHE=true.

Return local privacy, cache, token-path and env-presence posture without revealing secret values.

Delete the local Withings token file. Withings token revocation support varies by app/API plan, so this tool only clears local access. Gated by explicit_user_intent: true (requires explicit user intent).

Build a practical daily summary from Withings activity, sleep and body/heart data when available. Read-only and non-medical.

Build a weekly Withings scorecard with sleep, activity, body measures, bottlenecks and actions. Read-only and non-medical.

Normalize Withings sleep and activity load into the shared wellness_context shape for recommendation engines.

Read the shared Delx Wellness profile from ~/.delx-wellness/profile.json. Returns preferred name, goals, devices, training/nutrition/exercise/agent preferences and safety flags. NEVER contains OAuth tokens or API secrets. Read-only.

Persist a partial patch to ~/.delx-wellness/profile.json. Requires explicit_user_intent=true (otherwise returns USER_ACTION_REQUIRED). Rejects secret-like fields (oauth, token, secret, password, cookie, refresh, api_key, session) at write time. Use to record preferred name, goals, devices, training context, nutrition context, exercise preferences, agent preferences, and safety flags.

Return the 11-question onboarding flow plus the current profile state and missing fields. Read-only — does NOT persist anything. Pair with withings_profile_update once the user answers. Cross-connector: the same profile is shared by every Delx Wellness MCP (whoop, garmin, oura, fitbit, strava, polar, withings, apple-health, samsung-health, google-health, nourish, cycle-coach, cgm, air).