--- title: "MCP Server for Wearable Health Data" description: "Point Claude Desktop or Cursor at your own deployment and ask about your users' health data in plain language. Open source, self-hosted." canonical_url: "https://openwearables.io/platform/mcp-server" --- # Ask your own data a question. MCP server Point Claude Desktop, Cursor or any MCP client at your deployment and ask about your users in plain language. The question and the answer stay inside your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) Built on Open Wearables - Heart Monitor logo - Hundred logo - JustGains logo - Lifelong logo - MoveTogether logo - Suna logo - Yoboo logo What you get ## What changes when you can just ask. Sleep, activity, workouts, cycles and the samples underneath were always reachable. What changes is who can reach them, how fast, and where the question goes. ### No query to write. You ask the way you would ask a colleague. The assistant works out which lookups it needs and runs them. - “How did they sleep last week?” ### Nothing to build. The server ships with the project. Connecting it is a config entry, not a sprint. - One config entry ### The question stays in your account. It runs against your deployment, so answering it does not send your users' data through anyone else's infrastructure. - Your deployment - No middleman ### One server, every provider. No separate Garmin MCP or Strava MCP to run and keep working. The assistant asks about a user, not about a device. - One schema - Any provider ### It reaches exactly what your key reaches. Scope comes from the API key you issued, and the tools are read-only. An assistant can answer, not change. - Read-only - Scoped to your key ### People who do not write SQL can ask. A clinician checking a cohort or a product lead checking a hunch, without putting an engineer in the middle. - No query language needed How it works ## Three steps, then you are asking questions. Setup per client, including Claude Desktop and Cursor, is in the docs. 01 ### Point it at your deployment. The server needs two things: where your backend lives and a key that belongs to you. There is no Open Wearables account in the middle, because the deployment it queries is the one you run. Terminal ``` $ OPEN_WEARABLES_API_URL=https://api.yourcompany.com $ OPEN_WEARABLES_API_KEY=ow_... ``` 02 ### Add it to the client you already use. Claude Desktop and Cursor both read a config file listing the servers they can reach. Adding this one is an entry in that file, and the client picks it up on restart. Terminal ``` $ "open-wearables": { "command": "uv", "args": ["run", "--directory", "/path/to/mcp", "start"] } ``` 03 ### Ask in the language you would use with a colleague. The assistant works out which lookups it needs, runs them against your deployment and answers. What it cannot do is reach anything your key does not already reach. [MCP server guides](https://openwearables.io/docs/mcp-server) Terminal ``` $ "Compare this user's sleep in March against February, and flag anything unusual." ``` Who asks ## Everyone on the team gets their own answers. The clinician, the coach, the researcher and the product lead each ask in their own words. Nobody files a ticket, and nobody writes a query. 01 ### A clinician, before a check-in. “Which of my patients had fewer than four nights over seven hours this month?” One question instead of opening every patient's chart. 02 ### A coach, after a training block. “Who trained longest last week, and how did their HRV move the nights after?” Workouts and recovery in one answer, from whichever watch each athlete wears. 03 ### A researcher, across a study. “How does resting heart rate change across the cycle for participants who log one?” Cycle phases and heart rate side by side, without an export. 04 ### A product lead, testing a hunch. “What share of our users hit 8,000 steps on most days last month?” A number for the roadmap review, without waiting on a dashboard. The honest comparison ## Hosted API, in-house, or self-hosted. Where each one wins. If a hosted API fits your situation, use one. | | Hosted SaaS API | Build in-house | Open Wearables, self-hosted | | --- | --- | --- | --- | | [01] Where the question is answered | Their infrastructure | Yours | Your deployment | | [02] What the assistant can reach | What they expose | What you built | Your own data, scoped to your key | | [03] Who can reach the data | The vendor and its sub-processors | Your team | Your team, and us under a DPA you sign when we work on it | | [04] Building the server | Not yours to build | Weeks of work, then maintenance | Ships with the project | | [05] Reading what the tools do | Closed | Yours | MIT source you can open | Who is it for ## Different industries, one constraint: the data cannot sit in somebody else's cloud. ### Digital health products Coaching, scoring and analytics on the devices your users already wear, with a security review somewhere ahead. [Learn more](https://openwearables.io/for/digital-health) ### Health data platforms Wearable data next to the clinical record you hold, running in your own cloud under your own credentials. [Learn more](https://openwearables.io/for/health-data-platforms) ### Remote patient monitoring Readings from the patient's own device, in the record their clinician reads, in the country the data must stay. [Learn more](https://openwearables.io/for/remote-patient-monitoring) ### Clinical and research builders Endpoints that survive review, for teams heading for DiGA, CE or FDA and for research under ethics approval. [Learn more](https://openwearables.io/for/clinical-research) ### Care providers Remote monitoring for care programmes, clinics, senior care and virtual wards, with a patient app and a care view for your team. [Learn more](https://openwearables.io/for/care-providers) ### Hospitals and telemedicine Wearable data written into your EHR, with a source for every reading that clinicians and auditors can trust. [Learn more](https://openwearables.io/for/hospitals-telemedicine) What you own ## What you actually own at the end. The deployment, the data and the algorithms stay in your account, whoever runs it. What that means in practice. ### Sovereignty Health data does not sit in a third party's cloud. Where that is your regulator's rule, your board's policy or your own, the deployment satisfies it by architecture rather than by contract. ### Residency The data stays in the region you chose, and you can prove where it is by pointing at an account rather than at a trust page. ### Control You run it under your own credentials and decide who gets access. What you build on top of Open Wearables is yours. ### Your own reasons No regulator forcing it. You want the data in your own account anyway, and that is a sufficient reason. ## Every provider, through the same conversation. Whatever a user wears, the data arrives in one schema, and the assistant queries that schema rather than each provider's API. So there is no separate Garmin MCP server, Strava MCP server or Whoop MCP server to run and keep working. There is one server, and it answers about a user rather than about a device. [Browse all integrations](https://openwearables.io/integrations) - [Garmin integration](https://openwearables.io/integrations/garmin) - [Strava integration](https://openwearables.io/integrations/strava) - [Whoop integration](https://openwearables.io/integrations/whoop) - [Oura integration](https://openwearables.io/integrations/oura) - [Polar integration](https://openwearables.io/integrations/polar) - [Suunto integration](https://openwearables.io/integrations/suunto) - [Ultrahuman integration](https://openwearables.io/integrations/ultrahuman) - [Apple Health integration](https://openwearables.io/integrations/apple-health) - [Samsung Health integration](https://openwearables.io/integrations/samsung-health) - [Google Health Connect integration](https://openwearables.io/integrations/google-health-connect) ## Deploy Open Wearables in your own cloud. The repository is public and the deployment is yours from the first commit. Start from the source, or bring us in to stand it up in your account. [Get started](https://openwearables.io/docs/quickstart) [Book a demo](https://openwearables.io/book?tier=pro) [See pricing](https://openwearables.io/pricing) FAQ ## Do you have more questions? ### What is MCP, in one sentence? An open standard for letting an AI assistant use external tools, so a client like Claude Desktop or Cursor can look something up instead of guessing at it. ### Does our health data go to Anthropic or to you? The server runs against your deployment and returns answers to the client you are running. What the assistant sends onward is between you and whichever model you have chosen, which is a decision you make rather than one we make for you. Nothing routes through us. ### Do we need an Open Wearables account? No. The server authenticates with a key from your own deployment, so there is no account of ours anywhere in the path. ### Which clients work? Anything that speaks MCP. Claude Desktop and Cursor are the two most teams start with, and [the docs](https://openwearables.io/docs/mcp-server) have setup for both. ### We only care about one provider. Is there a Garmin MCP server, or a Strava one? There is one server, and it covers every provider connected to your deployment. That is the point of the normalised schema: an assistant asking about last week's training does not need to know whether it came from a Garmin watch, a Strava upload or a phone. If you connect only one provider, the same server answers about that one. ### What can the assistant actually reach? Exactly what your key reaches, and nothing beyond it. The tools are read-only lookups against your own API, so an assistant can answer questions about your data but cannot change it. ### Is this the agentic AI on your roadmap? No, and the distinction matters. This ships today and is part of the project you deploy. Agentic reasoning, where the system decides what to look at without being asked, is a separate layer for building an [AI health coach](https://openwearables.io/platform/ai-insights) on your data, as a licensed module. ### Can we see what the tools do? Yes, it is MIT licensed like the rest of the project. If your security review wants to know what an assistant can reach, the answer is code they can read. ### Can we add our own tools? Yes. The server is part of the repository you cloned, so extending it with lookups specific to your product is a change you make rather than a feature request you file.