How do I ask my own AI about my Health Connect or Apple Health data over MCP?

By Owen Vogelaar, who maintains Life Dashboard. Updated October 16, 2026.

Send your data with Life Dashboard Companion to the Life Dashboard stack, start the stack's built-in MCP server, and connect a model that can use MCP tools. A local model through Ollama keeps everything on your own hardware, and Claude Desktop or another cloud client can use the same server. If your data goes to Home Assistant instead, ha-mcp reads its history; if it goes to a Postgres of your own, DBHub does. It works for Health Connect data from Samsung Health, Fitbit, Garmin and other apps, for Apple Health data from the iPhone app, and in Europe, where the health connectors of Claude and ChatGPT aren't available.

The stack's MCP server

The app itself contains no AI and never talks to a model, and neither does the stack. The MCP server only answers a client you connect, and the model reads what your receiver already stores, through a connection that can't change anything.

PhoneThe stack, Home Assistant or your PostgresRead-only MCP serverYour model

How it fits together

MCP is the standard way for a model to call tools, and a read-only MCP server on the receiver gives the model tools to look up your history. The iPhone app sends to the same stack and the same integration, so every route works for Apple Health data too.

Use route 1 if you run the Life Dashboard stack: its MCP server is part of it. Use route 2 if you send to the Life Dashboard integration in Home Assistant, and route 3 if n8n or a receiver of your own already writes to a Postgres you run.

In Europe, where the official health connectors aren't available

As of October 2026, the health connectors that Claude and ChatGPT offer themselves are for users in the US only:

• Claude reads Apple Health and Health Connect in its iPhone and Android apps. It's in beta on Pro and Max plans and "currently limited to users in the US", according to Anthropic's help pages for Android and iPhone. On Android it needs Android 14 or later.
• Health in ChatGPT is for logged-in users in the US aged 18 or older, on the web and iOS. It connects Apple Health on an iPhone, and the help page doesn't mention Health Connect or Android (OpenAI's help page). For the early access in January 2026, OpenAI left out the European Economic Area, Switzerland and the United Kingdom (OpenAI's announcement).

So outside the US, the EEA, the UK and Switzerland included, neither assistant reads your Health Connect or Apple Health data by itself. The route on this page doesn't depend on where you live:

1. Your data sits in your own stack, Home Assistant or Postgres, sent there by the app.
2. A read-only MCP server runs on top of it: the stack's own, ha-mcp or DBHub.
3. Any model that can use MCP tools reads it. That can be a local model, or Claude: Claude Desktop runs MCP servers on your own computer, and a custom connector in Claude connects from Anthropic's cloud, so that server must be reachable from the internet (Anthropic's help page).

You run the server and decide which model may read it. With a cloud model, your questions and the tool results go to its provider.

What you need

• A model with tool support. For a local one, Ollama runs a model such as qwen3 (8B or 14B) or gpt-oss:20b. Pick one without a -cloud tag: those run on Ollama's servers. An 8B model wants 16 GB of memory; 20 to 30B wants a 24 GB graphics card or a Mac with 32 GB or more.
• A chat client that speaks MCP, such as Open WebUI, LM Studio or Claude Desktop, unless you use Home Assistant's own assistant. Ollama runs the model; the chat client makes the MCP connection.
• History to ask about. Backfill on the Health tab sends up to a year.

Set it up

Route 1: the stack's own MCP server

The stack has an optional MCP server as a fourth image, next to the receiver, Postgres and Grafana. It reads the stack's dash views, which already turn records into days, nights and workouts in your time zone, so a model never has to write SQL against nested JSON.

1. In the stack's .env, set MCP_TOKEN to a long random string, different from API_TOKEN. The server refuses to start without one:

   echo "MCP_TOKEN=$(openssl rand -hex 32)" >> .env

2. Start it with its profile. A plain docker compose up leaves it out, so add COMPOSE_PROFILES=mcp to .env if upgrades should include it:

   docker compose --profile mcp up -d

3. Connect a client over Streamable HTTP, at http://<address of this machine>:8090/mcp with the header Authorization: Bearer <MCP_TOKEN>. In Open WebUI, add it under Admin settings > Integrations > External tool servers as the type MCP (Streamable HTTP), with the token as bearer authentication, then switch the tools on in a chat with your Ollama model. In LM Studio, add the URL and the header to mcp.json.
4. Or use Claude Desktop on the same machine, over stdio, without the port or the token. Under Settings > Developer > Edit Config, add the stack, with the folder of your docker-compose.yml as the path, and restart Claude Desktop:

   {
     "mcpServers": {
       "life-dashboard": {
         "command": "docker",
         "args": ["compose", "--project-directory", "/path/to/life-dashboard",
                  "--profile", "mcp", "run", "--rm", "--no-deps", "-T",
                  "mcp", "python", "server.py", "--stdio"]
       }
     }
   }

   Fetch the image once first with docker compose --profile mcp pull mcp.
5. Ask a direct question with a period: “Use trend for sleep_h over 28 days, then workouts for the same period, and tell me whether I slept longer on days I worked out.”

The six tools:

Every tool reads as dash_ro, a database user that can only read the dash views, in read-only sessions that stop after 15 seconds. There's no tool that writes and none that takes SQL, so a model can't change or delete anything, and it can't read the raw records. Six tools with fixed parameters are also far easier for a small model than SQL. On Kubernetes, the stack's Helm chart runs the same server with mcp.enabled; the MCP documentation has every client and parameter.

For a script rather than a model, the stack's receiver serves the same queries as a read-only JSON API under /api/, once you set API_TOKEN: days, nights, workouts, screen time, one metric as a series, and a trend. The API documentation lists every endpoint.

Route 2: Home Assistant with ha-mcp

The integration keeps your history in long-term statistics, with IDs like life_dashboard:<entry>_steps. With its Assist API, Home Assistant's built-in MCP server only offers current states, so it can answer “how many steps today” but not how this month compares with the last. ha-mcp, a community project, has a history tool that reads long-term statistics.

1. In HACS, add homeassistant-ai/ha-mcp-integration as a custom repository and install it. It needs Home Assistant 2026.8 or later. Restart, then add HA-MCP Custom Component under Add integration and choose HA-MCP Server.
2. In the HA-MCP panel in the sidebar, switch on Read Only Mode.
3. Under Configure, turn off Remote access via webhook and set Network access to 127.0.0.1, unless a client on another machine needs it.
4. Connect a model. Inside Home Assistant, add the Ollama integration, create a conversation agent with a tool-capable model and choose HA-MCP Server (tool search) under Control Home Assistant. Or add ha-mcp's URL in Open WebUI or LM Studio, and switch on its tool search in the HA-MCP panel. Treat that URL as an administrator password.
5. Give the model the statistic ID, which Developer tools > Statistics lists, and ask for monthly averages with ha_get_history from its statistics.

Route 3: your own Postgres with DBHub

If n8n or a receiver of your own already stores the payloads in a Postgres you run, a generic database MCP server such as DBHub can give a model read-only access to it.

1. Store records keyed on uuid as text, daily_totals as one row per date, and apply deleted_records, so a model can't count a walk twice or read a record you deleted. Store it in Postgres has the details.
2. Create a role that can only read those tables:

   CREATE ROLE llm_ro LOGIN PASSWORD 'change-me';
   ALTER ROLE llm_ro SET default_transaction_read_only = on;
   ALTER ROLE llm_ro SET statement_timeout = '30s';
   GRANT CONNECT ON DATABASE health TO llm_ro;
   GRANT USAGE ON SCHEMA public TO llm_ro;
   GRANT SELECT ON records, daily_totals TO llm_ro;

   Use your own table and database names, and grant SELECT on every view you add later.
3. Run DBHub in read-only mode, connected as that role, and add its URL in Open WebUI or LM Studio. The recipe for this route has a docker-compose.yml and a dbhub.toml.
4. Add views with one row per day and per night. A model answers far better from those than from sleep sessions as JSON. The stack's views.sql is a template: adapt its table and column names to yours.

On Kubernetes, the stack's Helm chart can also use a Postgres 18 you already run, with a database of its own (its external mode), and then route 1 works there. With Docker Compose, running the stack against your own database isn't covered by its documentation.

What you get

• Answers about your own history, such as monthly step averages or your sleep in weeks you trained more, from a model you choose, on your own hardware if you like.
• Read-only access. With the stack's tools, a read-only role or Read Only Mode, the model can't change a setting, delete a record or switch a device.

Limits

• With a cloud model, Claude Desktop included, your questions, every tool result it asks for and its answers go to the provider, under its retention and training settings. Claude Desktop runs the stack's server on your computer, but the conversation goes to Anthropic.
• The stack's tools answer per day, per night and per workout, for up to 92 days per call, and a trend over up to 365. They don't hand out single readings or raw records.
• Docker publishes the stack's MCP port on every network interface of the machine, and over plain HTTP the token and every answer cross your network readable. Set MCP_PORT=127.0.0.1:8090 to keep it to the machine, and use TLS or a VPN beyond your own network. A custom connector in a web app calls from the provider's cloud and would need the server on the internet; the stack's documentation doesn't cover that.
• The stack's .env starts with default passwords for Grafana and the two read-only users. Change them before you add another way in.
• ha-mcp works with an administrator's access. Everyone who can talk to its conversation agent can ask about your health data, so give it its own agent, outside shared voice pipelines. A question asked by voice also goes through your speech engine, which with Home Assistant Cloud isn't local.
• Types you didn't switch on, or days the phone didn't sync, aren't there to read. Screen time history only comes from Android phones. The stack keeps series sent per time window apart, and only its heart rate views read them, so leave Data Resolution on Every record, the default.
• Types your watch's app doesn't share with Health Connect aren't there either, and they decide which questions a model can answer. Samsung Health keeps HRV, resting heart rate and respiratory rate to itself, and Garmin Connect writes no HRV to Health Connect at all and keeps resting heart rate to itself.
• A model isn't a doctor. It can sum your steps correctly and still draw a wrong conclusion.