Talk to Your Wearable Data: How Open Wearables MCP Server Connects Health Metrics to AI Assistants

Your wearable collects sleep stages, heart rate variability, workout intensity, and recovery metrics around the clock. Getting a specific answer from that data usually means writing API queries, filtering by date ranges, and formatting the results yourself.

The Open Wearables MCP Server removes that friction. It gives AI assistants direct access to your unified wearable data, so you can ask a question in plain English and get an answer grounded in actual measurements.

"How much sleep did John get last week?" becomes a real query that returns real numbers. Not a guess. Not generic health advice. Actual data from actual devices.

What the MCP Server Does

MCP (Model Context Protocol) is a standard for connecting AI assistants to external data sources. Think of it as a bridge: on one side, your AI assistant (Claude Desktop, Cursor); on the other, your Open Wearables instance with normalized data from Garmin, Apple Health, Whoop, Polar, Suunto, or Samsung Health Connect.

The MCP Server sits between them. When you ask your AI assistant a health-related question, the assistant calls the appropriate MCP tool, the server queries your Open Wearables REST API, and the response comes back formatted for the assistant to interpret and explain.

The architecture is deliberately simple. The MCP Server is a separate component that communicates with the Open Wearables backend via REST API using your API key. It doesn't need access to the database. It doesn't run inside the main application. You can deploy it on your laptop while your Open Wearables instance runs on a remote server.

Available Tools

The MCP Server currently exposes four tools to AI assistants:

• List Users - Discover which users are accessible via your API key. Supports optional filtering by name or email. This is usually the first tool the assistant calls when you ask about a specific person's data.
• Activity Summary - Daily activity data: steps, calories burned, heart rate averages, and intensity minutes. Aggregated by day from time-series data across all connected providers.
• Sleep Summary - Sleep data within a date range: total duration, sleep stages, quality metrics. Pulls from whichever device the user wore to bed, normalized to the same format.
• Workout Events - Exercise and workout sessions within a date range: type, duration, heart rate, calories, distance. Covers everything from a morning run logged on Garmin to a strength session tracked on Whoop.

All four tools return data in the Open Wearables unified format. A Garmin sleep session and an Apple Health sleep session look identical by the time they reach your AI assistant.

What a Conversation Looks Like

A real interaction pattern from the documentation:

You: "How much sleep did John get last week?"

The assistant:

1. Calls get_users() to find John's user ID
2. Calls get_sleep_summary(user_id="uuid-1", start_date="2026-01-28", end_date="2026-02-04")
3. Responds: "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."

No manual API calls. No date formatting. No remembering which endpoint serves sleep data. You ask, the assistant handles the tool calls, and you get an interpreted answer.

This works for follow-up questions too. "How does that compare to the previous week?" triggers the same sleep summary tool with shifted dates. "Did he work out on Thursday?" switches to the workout events tool. The assistant maintains context across the conversation, combining results from multiple tool calls when needed.

How to Set It Up

You need a running Open Wearables instance and an API key. The MCP Server connects to it remotely, so they don't need to run on the same machine.

Step 1: Configure the MCP Server

Inside the mcp/ directory of the Open Wearables repository, create the config:

cd mcp
cp config/.env.example config/.env

Edit config/.env with two values:

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

Generate your API key from the Open Wearables Dashboard under Settings > Credentials > Create API Key.

Step 2: Connect to Claude Desktop

Edit your Claude Desktop config file:

macOS:

~/Library/Application Support/Claude/claude_desktop_config.json

Windows:

%APPDATA%\\Claude\\claude_desktop_config.json

Add the server:

{
  "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 on your system. If uv isn't in your PATH, use the full path (find it with which uv).

Step 3: Verify

Restart Claude Desktop. Look for the MCP tools icon in the chat interface. Try asking:

"Who can I query health data for?"

If configured correctly, Claude will call the get_users tool and return the list of users in your Open Wearables instance.

Cursor Setup

The configuration is similar. Add the same command and args to your Cursor MCP settings. The Cursor setup guide covers the exact steps.

Testing and Debugging

MCPJam provides a local inspector UI for testing MCP servers. Install it with npx @mcpjam/inspector@latest, point it at the Open Wearables MCP Server, and you can explore available tools, test individual calls, and inspect responses before connecting a full AI assistant.

Use Cases for Developers

During development and debugging

Instead of writing curl commands to check if a user's data synced correctly, ask your AI assistant. "Show me the last 3 workouts for test user X" is faster than constructing the API call, especially when you're iterating quickly.

Building conversational health features

The MCP Server demonstrates the pattern you'd implement in your own product. The same tools that power a Claude Desktop conversation can be adapted into a chat interface inside your application. A personal trainer's dashboard could include a chat where the trainer asks about an athlete's sleep and recovery trends without leaving the app.

Data exploration and reporting

Product managers and data analysts can query wearable data without writing code. "What's the average step count across all users this month?" becomes a conversation, not a SQL query or a Jupyter notebook.

Client demos

If you're building a health product and want to show a potential client how wearable data integration works, a live Claude Desktop conversation with real data is more compelling than slides.

Technical Architecture

The MCP Server is built with:

• FastMCP for the MCP protocol implementation
• httpx for async HTTP communication with the Open Wearables backend
• Pydantic for settings and data validation

It runs as a stdio-based server, meaning the AI assistant launches it as a subprocess and communicates through standard input/output. No separate web server, no ports to configure, no networking between the assistant and the MCP Server.

The data flow:

AI Assistant <--stdio--> MCP Server <--REST API--> Open Wearables Backend <--> PostgreSQL

This architecture means:

• The MCP Server has no direct database access. It uses the same REST API your application would use.
• Authentication is handled by API keys, the same ones you use for any Open Wearables API call.
• Adding new MCP tools means adding new Python functions that call existing API endpoints. No backend changes required.

Current Status and Limitations

The MCP Server is in beta. It ships with Open Wearables v0.3.0-alpha (released January 23, 2026) and is actively developed.

What works well:

• Sleep, activity, and workout queries are stable and return normalized data from all supported providers
• Claude Desktop and Cursor integrations are documented and tested
• Setup is quick and the server is lightweight

Current limitations:

• Four tools available. Body metrics, HRV trends, and stress data are not yet exposed as MCP tools (though the underlying API endpoints exist).
• No streaming or real-time updates. The server queries data on demand.
• Beta stability. APIs may change before v1.0.
• Works with MCP-compatible tools (Claude Desktop, Cursor, MCPJam). Other AI assistants will work as MCP adoption grows across the ecosystem.

The roadmap includes natural language conditions triggering webhooks, customizable AI model support, and an embeddable AI health assistant widget.

Get Started

The MCP Server ships with the Open Wearables repository. If you already have a running instance, you're minutes away from querying health data through Claude Desktop.

• MCP Server documentation -- setup, configuration, available tools
• Claude Desktop setup -- step-by-step config
• Cursor setup -- IDE integration
• GitHub repository -- source code, issues, and contributions
• Open Wearables quickstart -- deploy the full platform if you haven't already

If you're building a health product and want to evaluate how MCP-powered AI features could fit your architecture, we're happy to talk through it.