6 best personal health MCP servers in 2026

If you wear an Oura, WHOOP, Polar, or Garmin and use an AI assistant, you have probably wondered why the two never talk to each other. The Model Context Protocol (MCP) is the open standard that fixes this. An MCP server reads your wearable data and exposes it to any AI client that speaks MCP, so you can ask Claude or ChatGPT "how did I sleep last night" and actually get an answer.

This is an honest list. We rank by fit, not popularity, and Freddy (which we make) is not always the right choice. If you only have an Apple Watch and live entirely inside the Apple ecosystem, you should probably use Apple's own connector. If you want to self-host, Open Wearables is a better fit than any hosted service. The right answer depends on what you wear and where your data lives.

A note on scope. The hosted personal-health MCP space is small in 2026. We include the four products we consider production-grade today, plus the two first-party platform connectors (Apple's and Google's) that an iOS or Android user is most likely to consider as alternatives. Open Wearables, Apple Health Connector, and Google Health Connect are not themselves MCP servers, and we say so where it matters.

What an MCP server actually does

An MCP server is a small program that translates between an AI client and a data source. The client (Claude Desktop, ChatGPT, Cursor) speaks MCP. The data source (Oura's API, your local files, a Postgres database) does not. The server bridges the two by exposing tools the AI can call: list_metrics, query_metrics, get_workout_summary, and so on. When you ask the AI a question that touches your data, it calls those tools and gets back structured answers it can reason about.

Personal health is a particularly good fit for MCP because the data lives in many places (rings, watches, apps, glucose monitors) and the questions tend to span multiple sources ("did I sleep worse on the nights I trained late?"). A good health MCP server pulls from multiple wearables, normalizes the data into one query surface, and lets your AI do the reasoning.

The list

1. Freddy

Integrations: Polar, Oura, WHOOP, Withings, Suunto, Hevy, Intervals.icu, Dexcom.

How it works: Hosted MCP server. You sign in with a magic link, connect each wearable through OAuth (we run the developer apps, so you do not), and paste a personal MCP URL into Claude Desktop, ChatGPT, Cursor, or any other MCP client. Queries are answered live against the most recent sync.

Pricing: $9/year. Free tier supports one wearable and 30 days of history; paid is unlimited connections and unlimited history.

We built Freddy because no other hosted service supported more than one platform. If you mix two or more wearables and want a single AI surface across all of them, this is the case it is optimized for.

Best for: anyone with two or more wearables who wants a personal AI assistant that can reason across all of them.

2. Fulcra Dynamics

Integrations: Apple Health (HealthKit), which itself ingests from Apple Watch, Oura, WHOOP, Strava, Peloton, and any other iOS app that writes to HealthKit.

How it works: Hosted MCP server backed by an iOS companion app. The app reads HealthKit on your phone and uploads to Fulcra's cloud, which exposes an MCP endpoint to Claude, ChatGPT, and other clients.

Pricing: Around $14.99/month.

Mature product, well-supported. Only works if all your data already lives in Apple Health, so if you have an Android phone or a wearable that does not write to HealthKit, this is the wrong choice.

Best for: iOS users whose wearables already export to HealthKit.

3. Open Wearables

Integrations: Several wearables are supported in the codebase, but you register your own developer apps with each provider (Polar AccessLink, WHOOP, Oura, Strava, and so on) and paste the resulting client IDs and secrets into config files.

How it works: Self-hosted. Despite the name, the project is not an MCP server in the strict sense; it is a sync-and-store layer. To plug it into Claude or ChatGPT you also run a small MCP bridge in front of its database. Everything lives on your hardware.

Pricing: Free; you pay for whatever VPS or home server it runs on.

Total data ownership and no recurring cost. The cost is your time: registering with each provider's developer portal, keeping OAuth credentials fresh, monitoring the sync, patching when APIs change, and gluing on the MCP layer yourself.

Best for: developers who want to self-host and are comfortable running a Node service plus a stack of separate developer accounts.

4. Microsoft Copilot Health

Integrations: A curated list of partners Microsoft has signed deals with. Not user-extensible; if your wearable is not in the gallery, there is no way to add it.

How it works: Health data flows into Microsoft's Copilot graph and Copilot reads from it when you ask health questions. There is no MCP endpoint you can point another client at, so this is a Copilot product, not a portable MCP server.

Pricing: Bundled with Microsoft 365.

Downsides:

• Copilot-locked. You cannot use it with Claude, ChatGPT, Cursor, or any other MCP client. If you ever switch AI assistants, you start over.
• Requires a Microsoft 365 subscription. If you already pay for one, the marginal cost is zero; otherwise this is by far the most expensive option on the list.
• The integration list is what Microsoft picked, not what you wear. Microsoft adds new connectors slowly and on its own commercial timetable.
• Microsoft sees every health query you make. For most people that is fine, for some it is a non-starter.
• No data portability. The "data" exists inside Copilot, not as a clean export you can hand to another tool.

Best for: Microsoft 365 users whose AI work already happens in Copilot and who own a wearable Microsoft already supports.

5. Apple Health Connector

Integrations: Anything that writes to HealthKit on iOS. That includes Apple Watch, Oura (via the Oura app), WHOOP (via the WHOOP app), Withings, Strava, Peloton, and any third-party app that opted in.

How it works: Not an MCP server. It is Apple's first-party HealthKit framework that an iOS app developer uses to read HealthKit data from inside their own app. To turn that into an AI experience, someone has to build the iOS app, ship it on the App Store, and write an MCP bridge that uploads (or proxies) what the app reads. Fulcra is one such product.

Pricing: Free for developers; the apps built on top set their own pricing.

Downsides:

• iOS-only. You need an iPhone (and usually an Apple Watch) for the data to be there in the first place.
• Developer-only. End users cannot connect HealthKit directly to Claude. Someone has to build a product on top of it.
• Background-sync constraints. Apple's app lifecycle means a HealthKit-reading app cannot reliably push fresh data to the cloud the moment it lands in HealthKit; data is usually a few minutes to a few hours stale.
• Sandboxed per app. Each app gets a per-data-type permission grant, so the catalog of metrics depends on what the user toggled on.
• Data stays in Apple's silo unless an app explicitly exports it.

Best for: iOS developers building their own AI features against HealthKit.

6. Google Health Connect

Integrations: Anything that writes to Health Connect on Android. Fitbit, Samsung Health, MyFitnessPal, Peloton, and a growing list of fitness apps have shipped Health Connect support; coverage is expanding as Google pushes adoption.

How it works: Not an MCP server. Like Apple Health Connector, this is Android's first-party health data hub: a system service that lets apps read and write a shared store of health data with the user's permission. To expose any of it to Claude or ChatGPT, an Android app developer has to build an app and write an MCP bridge that uploads (or proxies) what the app reads.

Pricing: Free for developers; apps built on top set their own pricing.

Downsides:

• Android-only. You need an Android phone (and a wearable that writes to Health Connect) for any of this to work.
• Developer-only. End users cannot connect Health Connect directly to Claude. Someone has to build a product on top, and at the time of writing very few do.
• App fragmentation. Even with Health Connect as a standard, individual apps decide what to export. Some write only steps and active calories; some write the full sleep + workout + heart rate picture.
• Garmin and Polar still rely on Garmin Connect / Polar Flow respectively rather than Health Connect, so coverage is uneven across the wearable market.

Best for: Android developers building their own AI features against Health Connect.

How to choose

If you already use one wearable platform exclusively (just Apple Health, just WHOOP), check whether that platform has a first-party connector or a single-vendor server before reaching for a multi-wearable option. If you mix two or more, a multi-wearable server is going to save you a lot of context-switching. If you self-host everything else in your life, you will probably be happier self-hosting your health MCP server too.

The thing nobody emphasizes enough is that your AI is only as useful as the data it can see. Picking the right MCP server is mostly about which wearables you wear and where you want their data to live.

Pricing and feature details verified 2026-05-08. Things move fast in this space; check vendor sites for current details before committing.