How to Give Your LLM Access to Wearable Data

Open Wearables Team · July 21, 2026 · 7 min read

Key Takeaways

Raw wearable data pasted into LLM context is not the same as structured health data. The format matters as much as the content.
MCP (Model Context Protocol) is an open standard for connecting AI assistants to external data sources through defined tools. Open Wearables ships an MCP server as part of the repository.
The Open Wearables MCP server exposes five tools that give any compatible LLM structured, queryable access to health data from any connected provider.
The MCP server is designed for AI assistant interfaces (Claude Desktop, Cursor IDE). For production apps, call the Open Wearables REST API directly from your backend.
The difference between an LLM that reads health numbers and one that reasons about them is the layer underneath: normalized data, consistent units, and a query interface the model can use reliably.

Most LLM integrations with health data follow the same pattern: dump a CSV or a JSON blob into the context, ask the model a question, and hope the output makes sense. It rarely does. The model reads numbers back at you. It has no framework for what those numbers mean, no sense of whether a resting heart rate of 58 bpm is good or concerning for this specific user, and no way to connect patterns across metrics over time.

This article covers how the Model Context Protocol works with wearable data, what Open Wearables ships today, and how to structure the integration so your LLM reasons about health data instead of just reading it.

Why Dumping Raw Data Into Context Does Not Work

A typical workout record from a wearable provider contains a mix of timestamps, distances, heart rate values, and activity identifiers. Each provider uses different field names, different units, and different timestamp formats. Garmin, Polar, and Apple Health all represent a running workout differently at the API level.

Even if you normalize this yourself before including it in context, you still have a larger problem: context is not a database. An LLM receiving 90 days of workout records, heart rate time series, and sleep data will hit the context limit before it can reason meaningfully. And even within the limit, the model does not know which data points matter for the question being asked.

The solution is not to give the model more data. It is to give the model tools to query the right data for the right question.

What MCP Is and Why It Matters for Health Data

Model Context Protocol is an open standard developed by Anthropic for connecting AI assistants to external data sources and tools. Instead of embedding data directly in the prompt, you expose a set of tools that the model can call during reasoning. The model decides which tool to call, with which parameters, and uses the result to construct its response.

For health data, this is the right architecture. A model with a get_workout_events tool can retrieve the last 7 days of activity data when asked about training load, without needing all of it pre-loaded in context. A model with a get_users tool can identify which users it has data for before answering a question about a specific person.

MCP is supported natively by Claude Desktop and Cursor IDE. Other LLM interfaces are adding support as the standard becomes more widely adopted.

What the Open Wearables MCP Server Provides

Open Wearables ships an MCP server in the mcp/ directory of the repository. It runs as a REST API client on top of your Open Wearables instance and exposes five tools to any connected AI assistant:

get_users: returns the list of users accessible via your API key, with optional name or email filtering
get_workout_events: retrieves workout and exercise sessions for a specific user within a date range
get_sleep_summary: retrieves sleep data for a specific user within a date range, including per-night records and aggregated summary
get_activity_summary: retrieves daily activity data (steps, calories, heart rate, intensity minutes) for a specific user
get_timeseries: retrieves granular time-series samples (weight, SpO2, HRV, intraday heart rate) for a specific user and time window

All data returned by these tools follows the Open Wearables unified data model. Units are normalized across providers. Timestamps are UTC. The model receives consistent structure regardless of which provider the data came from.

Setting Up the MCP Server

The MCP server lives in the mcp/ directory of the Open Wearables repository. Prerequisites: uv package manager version 0.9.17 or later, a running Open Wearables instance, and a valid API key.

Step 1: Install dependencies

            cd mcp
uv sync --group code-quality

Step 2: Configure environment variables

            cp config/.env.example config/.env

Edit config/.env with your instance details:

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

Step 3: Test the server locally

            uv run start

Step 4: Register with Claude Desktop

Add the following to ~/Library/Application Support/Claude/claude_desktop_config.json on macOS:

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

Replace /path/to/open-wearables/mcp with the actual path to the mcp/ directory. Restart Claude Desktop after saving.

Step 5: Verify the connection by opening Claude Desktop and asking: "Who can I query health data for?" The model calls get_users and returns the users connected to your Open Wearables instance.

What the Interaction Looks Like in Practice

Without the MCP server, a prompt like "How has this user's training load changed over the past two weeks?" produces a generic response or asks you to provide the data manually.

With the MCP server connected, the model calls get_users to identify the user, then get_workout_events with a date range covering the last 14 days, receives normalized workout records including duration, distance, average heart rate, and activity type, identifies trends across the returned records, and produces a response grounded in the actual data.

From the Open Wearables MCP documentation, a sleep query looks like this in practice:

            User: "How much sleep did John get last week?"
Claude: [calls get_users() to get John's user_id]
Claude: [calls get_sleep_summary(user_id="uuid-1", start_date="2026-01-28", end_date="2026-02-04")]
Claude: "John slept an average of 7 hours and 45 minutes over the last week.
His longest sleep was 8h 15m on Monday, and shortest was 6h 30m on Thursday."

The model is not hallucinating or reasoning from incomplete information. It is calling a tool, receiving structured data, and synthesizing a response from that data.

MCP Server vs. REST API: When to Use Which

The MCP server is the right choice for AI assistant interfaces (Claude Desktop, Cursor IDE), internal tooling where a developer or analyst queries health data through a chat interface, and prototyping and exploring the data model before writing integration code.

For production applications, call the Open Wearables REST API directly from your backend. The REST API gives you full control over how data is retrieved, how it is passed to the LLM, and how the response is processed. The MCP server is a layer on top of the REST API, designed for interactive AI assistant use cases, not for embedding in an application backend.

            curl -H "X-API-Key: YOUR_API_KEY" \
  "http://localhost:8000/api/v1/workouts?user_id=USER_ID&from=2026-07-01&to=2026-07-21"

The response follows the same normalized data model the MCP server returns. You retrieve the data, format it for your LLM, and manage the model interaction yourself.

What You Still Need to Handle Yourself

The MCP server and the Open Wearables REST API give you structured, normalized health data. They do not give you a health reasoning system out of the box.

For a production AI health feature, you still need to decide which data to retrieve for which question (a question about recovery requires different data than a question about training volume), how to frame the context (health data without reference ranges is hard to interpret), and what the model should and should not recommend (health data applications operate near clinical territory and need guardrails).

Open Wearables provides the data layer. The intelligence layer is what you build on top.

FAQ

Does the MCP server work with models other than Claude?

MCP support varies by model and interface. Claude Desktop and Cursor IDE have native MCP support. Other interfaces are adding support as the standard gains adoption. For model-agnostic integrations, use the Open Wearables REST API directly and manage the model interaction in your application code.

Can I use the MCP server in a production application?

The MCP server is designed for AI assistant interfaces, not for embedding in a production backend. For production use, call the Open Wearables REST API from your backend and pass the data to the LLM in whatever format fits your application architecture.

What data is available through the MCP tools?

The five MCP tools expose workouts, sleep data, daily activity aggregates (steps, calories, heart rate, intensity minutes), and high-frequency time series data (SpO2, HRV, intraday heart rate). Data availability depends on which providers your users have connected. The full data model is documented at docs.openwearables.io.

Does Open Wearables store the data, or does it query providers in real time?

Open Wearables stores normalized data in your PostgreSQL instance. Providers push data via webhooks or Open Wearables polls them on a schedule. When the MCP server calls a tool, it queries your local database, not the provider API directly. Response times are fast and you are not dependent on provider API availability for every query.

Can I extend the MCP server with custom tools?

The MCP server ships as open source under the MIT license. You can add custom tools that expose additional data or perform domain-specific operations. The architecture is decoupled from the backend and communicates via REST API, which makes it straightforward to extend. Full architecture details are in mcp/README.md in the repository.

Back to all posts