How to build an AI health coaching app with wearable data

Open Wearables Team · May 27, 2026 · 6 min read

Key Takeaways

Building an AI health coaching app without structured wearable data access forces LLMs to rely on user-reported info, which leads to vague responses or hallucinations.
Open Wearables normalizes data from providers like Garmin, Polar, Whoop, Apple Health, and others into a single API schema, so your app queries one interface regardless of what device the user has.
The MCP server gives AI assistants (Claude Desktop, Cursor) direct, tool-based access to real user health data with four ready-to-use tools: List Users, Activity Summary, Sleep Summary, and Workout Events.
Setup takes minutes: install via uv sync, drop a config file, and restart Claude Desktop.
For production apps, call the REST API endpoints directly and build your own prompt layer on top.
Sleep Score and Resilience Score are in active development and not production-ready. Use them in prototypes, not in user-facing features.
The fastest path to a working health coaching prototype: connect Open Wearables, point an LLM at the MCP tools, and iterate on your prompt logic.

The Problem: LLMs Without Structured Health Data

You want to build something like this: a user opens your app, describes how they have been feeling, and an AI coach responds with personalized guidance based on their actual sleep, recovery, and activity data, turning health scores from wearables into actionable coaching.

The gap between that vision and a working app usually comes down to data access. LLMs are capable of reasoning about health metrics when given the right inputs. The problem is getting those inputs in a reliable, structured format.

Without that, you have two options, both bad. First, you ask the user to describe their own data. Accuracy depends entirely on user recall. Second, you integrate directly with each wearable provider. That means separate OAuth flows, separate data schemas, separate rate limits, and months of backend work before you can write a single line of coaching logic.

Garmin's API returns sleep data differently than Whoop's. Apple Health uses different field names than Samsung Health. A workout in Strava is not the same object shape as a workout in Polar. If you want to support more than one provider, you end up building a normalization layer yourself. That is the problem Open Wearables solves.

What Open Wearables Does Under the Hood

Open Wearables is an open source backend that handles provider integrations, OAuth, data ingestion, and normalization. It supports Garmin, Polar, Suunto, Whoop, Strava, Apple Health, Samsung Health, Google Health Connect, Fitbit, and Ultrahuman, giving you unified access to health scores from wearables across all of them.

The output is a single, consistent API. Every provider's sleep data maps to the same schema. Every workout event has the same field structure. Your application code talks to one API and never touches provider-specific logic.

For AI-powered features, this matters a lot. When you send health data to an LLM, schema consistency directly affects the quality of the output. If the model receives inconsistently shaped data, it has to make assumptions. Consistent data means the model can focus on reasoning, not interpretation.

The MCP Server: Direct AI Access to Health Data

The Model Context Protocol is a standard for connecting AI assistants to external data sources. Open Wearables ships an MCP server that exposes health data directly to AI tools like Claude Desktop and Cursor IDE.

The MCP server is decoupled from the backend and runs as a REST API client on top of your Open Wearables instance. It exposes four tools:

List Users: returns the users available for querying
Activity Summary: daily activity totals (steps, calories, active time)
Sleep Summary: sleep duration, stages, and consistency metrics
Workout Events: individual workout sessions with type, duration, and load

All tools default to a two-week lookback window.

Setup: Step by Step

Prerequisites: Open Wearables backend running (docker compose up -d), at least one user with connected wearable data.

1. Install the MCP server:

            cd /path/to/open-wearables/mcp
uv sync

2. Configure environment variables. Create config/.env in the MCP directory:

            OPEN_WEARABLES_API_KEY=your_api_key
OPEN_WEARABLES_API_URL=http://localhost:8000

3. Add to Claude Desktop config. On macOS, edit ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, edit %APPDATA%\Claude\claude_desktop_config.json.

            {
  "mcpServers": {
    "open-wearables": {
      "command": "uv",
      "args": ["run", "--frozen", "--directory", "/path/to/open-wearables/mcp", "start"]
    }
  }
}

4. Restart Claude Desktop. Test the connection by asking: "Who can I query health data for?"

Common Issues

API key errors: double-check the key in config/.env matches your Open Wearables instance
Connection refused: your backend is not running; run docker compose up -d from the Open Wearables root
No users found: verify OPEN_WEARABLES_API_URL points to the correct host and port

What Is Ready Today vs What Is Not

Production-ready endpoints:

GET /api/v1/users/{user_id}/timeseries
GET /api/v1/users/{user_id}/events/workouts
GET /api/v1/users/{user_id}/events/sleep
Summary endpoints for activity, sleep, recovery, and body metrics

In active development, not production-ready:

Sleep Score (0-100): weighted across Duration 40%, Sleep Stages 20%, Consistency 20%, Interruptions 20%
Resilience Score: based on HRV coefficient of variation from a 7-night window, requires minimum 5 nights of data

Planned, not available:

Health Insights Automations
AI Health Assistant Widget

Building a Production AI Health Coaching Flow

The MCP server is the fastest way to get started, but for a production app you want more control. The right approach is to call the REST API directly from your backend and manage the LLM interaction yourself.

When a user initiates a coaching session, your backend fetches the relevant summaries from the Open Wearables REST API. What you fetch depends on the coaching context: sleep coaching needs sleep and recovery data; training coaching needs workout events and activity summaries.

Pass the data as structured context to the model. Be explicit about the schema so the model does not have to guess field meanings. Send the prompt to your model of choice. The coaching response is grounded in real data, so the output is specific rather than generic.

Not every user will have data for every day. Build logic to detect gaps and adjust the prompt accordingly. "You have data for 9 of the last 14 days" is more accurate than silently averaging over incomplete windows.

Quickstart

            git clone https://github.com/the-momentum/open-wearables
cd open-wearables
docker compose up -d

# Set up the MCP server
cd mcp
uv sync
# Create config/.env with your API key and URL

# Configure Claude Desktop (see JSON above)
# Restart Claude Desktop
# Ask: "Who can I query health data for?"

See Related Articles

FAQ

Can I use the MCP server in a production app?

The MCP server is designed for AI assistant interfaces like Claude Desktop and Cursor IDE. For production apps, call the Open Wearables REST API directly from your backend. The MCP server is useful for prototyping, internal tooling, and exploring the data model before you write integration code.

Which wearable providers does Open Wearables support?

The current release supports Garmin, Polar, Suunto, Whoop, Strava, Apple Health, Samsung Health, Google Health Connect, Fitbit, and Ultrahuman. All providers normalize to the same API schema.

Are the Health Scores reliable enough to show to users?

Not yet. Sleep Score and Resilience Score are in active development. Use them in internal prototypes or developer demos. For anything user-facing, build on the raw summary endpoints instead.

What happens if a user has a data gap?

Open Wearables returns data for the days where it has records. If a user missed three days, those days will not appear in the response. Your application needs to handle gaps explicitly, either by noting the gap in the prompt context or by adjusting the analysis window.

Is the data stored locally or sent to a third party?

Open Wearables is self-hosted. You run it on your own infrastructure, and health data stays within your environment. There is no external service that processes or stores user data.

Back to all posts