How it works

Four surfaces: an HTTPS host you own, an MCP client that operates it, three source pipes in, and one SQLite ledger everything lands in.

The human flow
  1. 1

    Deploy on public HTTPS

    One process on a VPS behind your reverse proxy — Python 3.12+, SQLite WAL, no Postgres. Phones and OAuth need a real hostname with TLS; a laptop or private VPN name won’t do. The reference deploy is healthtake.c52.com; yours substitutes its own host.

  2. 2

    Connect your MCP client

    Point the client at /mcp with the bearer you issued. Its first call is setup_status; from there it walks you through each source, stores secrets in the server vault, and never echoes one back.

  3. 3

    Open the source pipes

    Apple Health arrives by webhook from Health Auto Export on your iPhone — two Premium REST automations, metrics and workouts, every one to six hours. Oura connects by browser consent through the public callback; Hevy takes a Pro API key. Watch-only is a supported profile: HealthKit alone, the other two disabled.

  4. 4

    Ask for the brief

    Each morning, health_brief answers with one compact card — sleep, readiness, activity, last strength session. Roles pick the winner per domain and every row names its instrument. With Hevy on, the agent plans routines too — dry-run until you say commit.

Public routes on the host
PathWhat it isAuth
/mcpStreamable MCP for the agentBearer token
/ingest/healthkitHealth Auto Export webhookX-Ingest-Token header
/oauth/oura/callbackOura consent redirectState check, no bearer
/healthzLiveness probeNone
The honest caveats
SourceProvidesWhat it asks of you
HealthKit via Health Auto ExportSteps, HR, HRV, energy, sleep, Apple workoutsHAE Premium for REST automations — and the iPhone does not sync while locked
OuraSleep score, readiness, sleep sessionsActive membership (Gen3+); open the Oura app after waking so the cloud has your night before the poller runs
HevyWorkouts, sets, routines read/writeHevy Pro for the API key; writes are dry-run unless commit=true