Connecting Wearable Data to AI Assistants Safely

This guide is for whoever connects the assistant: you, with your own ring or watch data, or a team wiring a coaching feature. If you are building an app that sends its users' health data to a model API, the developer side is covered in personalizing an app with wearable data; the checks below apply to every server that app talks to as well.

Three ways an assistant reaches wearable data#

Where the data sits decides the route. This site's guide to on-device and cloud health data splits it in two: on-device stores such as Apple HealthKit and Google Health Connect hold data on the phone under an OS-granted permission, with no vendor server to query, while cloud APIs such as Fitbit, Strava and Oura keep it on the provider's servers behind OAuth tokens. An assistant running on a laptop or in a browser has no direct path into the first kind. MCP servers come in two forms, local and remote, so the three routes take four rows:

The registry shows how MCP servers handle the on-device case. On October 17, 2026, 10 entries in the official MCP Registry named Apple Health or HealthKit. Three of their descriptions say where the data comes from, and they name an Apple Health export file, a companion iPhone app's copy of the data, and a database the user hosts; the one entry naming Health Connect describes itself as self-hosted. The directory of health MCP servers quotes every description.

What the MCP specification asks of the host#

The Model Context Protocol specification (version 2026-07-28) describes three roles: the host, which is the AI application; clients, the connectors inside it; and servers, which provide context and tools. Its security principles are written for the host:

• Hosts "must obtain explicit user consent before exposing user data to servers".
• Hosts "must not transmit resource data elsewhere without user consent".
• Hosts "must obtain explicit user consent before invoking any tool", and the specification's section on tools adds that there should always be a human in the loop with the ability to deny a tool call.

The same page is plain about the limit: "MCP itself cannot enforce these security principles at the protocol level". The consent prompt you see is your host's implementation of those principles, and the server on the other end is whatever its publisher wrote.

Before you connect a server: four checks#

1. Where it runs, and where your data goes#

A server listed with a package (npm, PyPI or a container image) runs on your machine. One listed with a remote URL is reached over the network, usually on a server someone else runs, though a few self-hosted ones list a URL template for a host you run yourself. On October 17, 2026, 87 of the 176 health servers in the registry listed a package and 91 a remote URL. Either way, what a tool returns becomes context for the model: the specification's security list for clients includes "Validate tool results before passing to LLM". So the data reaches the model provider behind your assistant whichever kind you pick, and a remote server adds its operator as one more recipient.

If you build an app that does this for its users, Apple's App Store guideline 5.1.2(i) requires clear disclosure and explicit permission before personal data is shared with third parties, "including with third-party AI". Guideline 5.1.2 on data use and sharing covers that clause, Apple's extra condition for HealthKit data, and why its application to model providers is still unsettled. Legal consent is a separate question: an iOS or Android health permission is a device access control, not a legal basis for what you do with the data, as user consent for health data explains.

2. Whether its tools only read#

A server describes each of its tools to the client and may attach annotations. The specification's schema defines readOnlyHint ("If true, the tool does not modify its environment", default false) and destructiveHint (true when a tool "may perform destructive updates to its environment", default true). It also says what they are worth: all of them are hints, not guaranteed to describe the tool faithfully, and clients "should never make tool use decisions based on ToolAnnotations received from untrusted servers".

Read "read-only" in a description the same way, as the publisher's claim. On October 17, 2026, 14 of the 176 registry descriptions said read-only, while others described creating, editing, deleting or scheduling workouts in the vendor account. In our judgement, a server that can write to your training calendar is more access than answering questions about your data needs. If your host shows each tool call before it runs, as the specification recommends, that prompt is where to refuse a write you did not ask for.

3. Where your vendor token lives#

For a local server the specification's authorization section is explicit: implementations using the stdio transport "SHOULD NOT follow this specification, and instead retrieve credentials from the environment". The registry's own format has a field for exactly that, a list of the environment variables a package reads, with a flag for the ones that are secret, such as a password or token. On October 17, 2026, 61 of the 176 health servers' entries declared at least one secret environment variable, header or URL placeholder. Whoever can read that variable, or the configuration file that sets it, can use your token. In 3 remote entries the secret is part of the URL itself, so the URL is the credential: keep it out of shared configuration files and screenshots as you would a password.

For servers reached over HTTP, the specification's authorization is based on OAuth 2.1. It requires clients and servers to "implement secure token storage", recommends short-lived access tokens, and forbids a server from passing the token it received from your client through to another service: an MCP server that calls a vendor's API has to use a separate token that vendor issued. A remote server holding a grant to your Garmin or WHOOP account holds it on its operator's infrastructure for as long as the grant lasts.

This site's guide to storing health data securely applies to that token as much as to the data: keep secrets out of source control, logs and client-side code, and rotate them.

4. How you take it back#

Removing a server from your assistant's configuration stops the host from starting or calling it. It does not cancel anything the server was given. A token it stored keeps working for whoever holds it until it expires or is revoked, and the specification's own warning is that an attacker holding a stolen token can make "requests that appear legitimate". So revoke at the source too: withdraw the app's access in your vendor account where the vendor offers that, delete the variable or file that holds the token, and for a remote server, ask its operator what it keeps after you disconnect. This site's guide to account linking makes the same point from the builder's side: deleting your end of a connection while the vendor grant stays live makes the revocation cosmetic.

Who publishes these servers#

On October 17, 2026, the directory found 176 servers in the official MCP Registry whose name, title or description names a health or fitness data source. None was published under a vendor's own domain namespace (com.garmin, com.ouraring, com.whoop and so on), which the registry grants only to a publisher who proves control of that domain; 106 were published under a personal or organisation GitHub namespace. That makes each publisher, not the vendor, the source for the answers to the four checks. Some descriptions call the server unofficial outright, and others say they use the vendor's official API or OAuth sign-in; this site has checked neither kind of claim.

This site's own MCP server#

Disclosure: AIFitnessAPI publishes its own MCP server, @aifitnessapi/mcp, so read this section as a description by its publisher. It reads no wearable or personal data. Its four tools (healthkit_type, health_data_cross_platform, fitness_api_changes and fitness_api_glossary) answer questions about the platform APIs from this site's CC BY 4.0 datasets, either over stdio from the copies bundled with the package, whose README says the server makes no network call, or at https://aifitnessapi.com/mcp, a hosted read-only endpoint that runs the same tools over HTTP. Every tool declares readOnlyHint: true, and the rule above applies to it as to any other server: that is its publisher's claim. On October 17, 2026 the package was not in the MCP Registry and npm had no package by its name, so it cannot yet be installed with npx; its section of the directory carries the current state.