Open Health Sync

What Open Health Sync MCP server does

Open Health Sync MCP server gives AI agents read-only access to health data held on infrastructure you operate. The underlying system collects records from thirteen supported sources: Apple Health, Withings, Oura, WHOOP, Fitbit, Health Connect, Polar, Strava, Suunto, Ultrahuman, Dexcom, OMRON, and intervals.icu.

Data is mapped into a shared model with consistent units. The available health domains include samples, sleep, workouts, nutrition, and daily summaries. The system also supports merged views across sources, so records from multiple providers can be presented through one API model.

This is an ingestion and normalization service, not a dashboard, coaching application, hosted service, medical device, or clinical software. It runs on your own server and exposes the normalized data through REST, FHIR R4, Open mHealth, exports, webhooks, and MCP.

How it works

Provider connectors pull health records, while phone uploads can provide additional source data. Incoming payloads are retained verbatim on disk or S3 before being normalized. Repeated uploads are deduplicated, and stored raw data can be reprocessed if a mapper changes.

Background synchronization includes provider webhooks where available, follow-up pulls for changed data, and a backstop pull for missed updates. The /freshness endpoint reports how current each source is. User and metric priorities support a merged view when several sources contain the same type of measurement.

The Open Health Sync MCP server is read-only. Agents authenticate with a token that permits reading the owner’s data, rather than modifying records or triggering writes through MCP.

Setup and configuration

The project is distributed as a Go binary and provides a container image for version 0.1.0:

docker pull ghcr.io/soma-intelligence/open-health-sync:0.1.0

The quickstart uses Docker Compose to start Open Health Sync together with Postgres. A demo seed command can load 90 days of synthetic data from six sources for testing the API and MCP tools. The project also supports amd64 and arm64 images and documents Kubernetes deployment through a Helm chart.

The service is intended for self-hosting. The supplied material does not specify individual environment variable names or required configuration values, so deployment settings should be taken from the repository’s current documentation.

Tools and capabilities

The read-only MCP interface exposes sixteen tools in the v0.1.0 demonstration. The provided material describes their data scope rather than listing each tool name. Supported agent-facing retrieval includes:

• Health samples such as heart-rate measurements
• Sleep records and sleep-related summaries
• Workout and activity data
• Nutrition records
• Daily summaries combining data from available sources
• Merged data across providers using configured priorities

The same underlying records can be accessed through REST, FHIR R4 Observations, Open mHealth, CSV, and Parquet. FHIR output uses standardized observation formats, including LOINC and UCUM values in the demonstrated heart-rate response.

Limitations and notes

Open Health Sync is marked as an early v0.1.0 preview. Its APIs, configuration, and schema may change in any 0.x release. Garmin and Coros are planned sources, while Samsung Health is planned through Health Connect; they are not listed as current direct integrations.

The Open Health Sync MCP server provides read access only. It should not be treated as medical or clinical software. Self-hosting also leaves deployment, database operation, access control, backups, and data deletion with the operator. The project includes backup and restore scripts, a hard-delete endpoint for users and raw files, consent controls, and an append-only audit log, but the provided material does not describe a managed hosting option.