Run Apple Health Data with Your Local LLM (Ollama + MCP)

You want a fully local stack: your model on Ollama, your Apple Health numbers on the same machine, nothing off-device. The tutorials stop at "install Ollama" and nothing works. Here is the missing piece and the exact config.

By MetricBridge · Updated 12 October 2026 · ~8 min read

AI-assisted, human reviewed. How we use AI

Quick answer

Ollama does not speak MCP. It is an inference server: it runs the model and exposes an OpenAI-compatible chat API, and that is all. MCP lives on the client side, so you need an MCP-aware client to hold the connection and translate tool calls to and from the local model. Run Ollama for the model, add a client that can drive Ollama (Goose, LM Studio, mcphost, or Open WebUI behind mcpo), and point that client at a local Apple Health MCP server. The model never leaves your machine, and neither does the data.

Why the "Ollama plus MCP" tutorials break

Ollama listens on http://localhost:11434 and serves a chat API. It never speaks MCP. MCP is a separate protocol over stdio or HTTP between a client (the agent) and a server (the tool provider). The client calls get_trends, sends the JSON-RPC request, and feeds the result back as a tool result. Swap the model and the server never changes.

What you are wiring up

1. A local model server. Ollama serving a tool-calling model. ollama pull qwen3 is a fine start.
2. An MCP-aware client that can drive Ollama. Goose, LM Studio, mcphost, or Open WebUI with mcpo. Most guides omit this part.
3. The health-export MCP server. A zero-dependency Node server exposing 16 read-only tools and 22 prompts over your local export.
4. An export to read. The MetricBridge iOS app writes it from Apple Health, read-only, to a folder you choose.

The server config, which is the same everywhere

Every client below wants the same two values: the command that starts the server, and the folder holding your export. The server is on npm, so there is nothing to clone:

{
  "mcpServers": {
    "health-export": {
      "command": "npx",
      "args": ["-y", "health-export-mcp"],
      "env": {
        "HEALTH_DATA_DIR": "/Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents"
      }
    }
  }
}

Keep the quotes: the default iCloud folder name contains a space. That folder is ~/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents; expand ~ to your real home path, because most clients do not. No export yet? Test the wiring with synthetic data:

npx -y health-export-mcp --demo

The demo serves a deterministic 400-day synthetic dataset, watermarked as synthetic, so you can prove the client, transport and tool calls work before touching real numbers.

Client 1 Goose, the most direct CLI

Goose talks to Ollama natively and holds MCP extensions itself, so it is the shortest path. Point it at Ollama in ~/.config/goose/config.yaml, then declare the health server as a stdio extension:

extensions:
  health-export:
    type: stdio
    cmd: npx
    args: ["-y", "health-export-mcp"]
    envs:
      HEALTH_DATA_DIR: /Users/you/Library/Mobile Documents/iCloud~ai~healthexport~app/Documents
    enabled: true

Start it with goose session and ask in plain language. Goose picks the tools; Ollama reasons.

Client 2 LM Studio as the client

LM Studio has been both an MCP client and server since early 2026. For a GUI over a terminal, open the Program tab, choose Install, then Edit mcp.json. That file lives at ~/.lmstudio/mcp.json and uses the mcpServers shape above. Add the health-export block, save, and LM Studio lists the tools.

Client 3 mcphost for a scripted config

mcphost is the terse option: one command, a config file you control. Give it a model string and the same config:

mcphost -m ollama:qwen3 --config ~/health-mcp.json

It reads the mcpServers block, starts the server as a child process, and routes tool calls to Ollama.

Client 4 Open WebUI, via mcpo

Open WebUI is an HTTP front end, and most MCP servers speak stdio, so you need a bridge. mcpo converts a stdio MCP server into an OpenAPI HTTP endpoint Open WebUI can add as a tool server.

pip install mcpo
mcpo --port 8080 -- npx -y health-export-mcp

Set HEALTH_DATA_DIR in the environment before launching, then add http://localhost:8080 as a tool server in Open WebUI. The model stays on Ollama; mcpo is only the transport shim.

A worked example, with the tools it actually calls

Once the wiring is up, you talk to the local model normally. Ask something real:

You: Using my MetricBridge data, how did my HRV trend this week
     compared with last week?

[qwen3] -> get_freshness
        -> compare_periods { metric: "hrv", thisWeek: true, lastWeek: true }

        Your HRV averaged 61 ms this week, up 4.4% from 58 ms last
        week. Resting heart rate fell from 56 to 55 bpm. Both are
        deviations from your own recent baseline, not a verdict.

The tool list is the same 16 read-only tools on every client: get_mcp_status to confirm the server sees your data, get_freshness to check how current the export is, list_metrics for the 190 available metrics, get_health_metrics for raw values, get_trends and compare_periods for the week-over-week math, query_health_data for flexible questions, and resolve_metric to map any spelling of a metric to its canonical name and unit. Ask the agent to call get_mcp_status first: it tells you whether the server is up and whether the data source was found, which separates "still syncing" from "never arrived".

Local model versus a cloud agent: the same tradeoff

The point is not that a local model out-reasons a frontier one. It will not. The point is what stays put:

Two verified facts sit under that table: the health-export MCP server makes zero runtime network calls, and the bridge exposes 16 tools and 22 prompts, which is the whole surface a local model chooses from.

If it does not work

The model describes tools but never calls them: a function-calling problem, not config. Swap to a tool-calling build of Qwen3, Gemma 3, or Llama 3.3 70B.

The server connects but reports no data: HEALTH_DATA_DIR is wrong, or the export has not synced. Check export is on in the app, the .health-cache.json file has landed on this machine, and the path matches with ~ expanded.

The client does not list the server: wrong shape. Goose wants YAML with cmd, args, envs; JSON clients want mcpServers with command, args, env. The wrong shape is silently ignored, so restart the client after editing.

What this is not

None of this diagnoses, detects, treats or monitors any condition. Where a metric moves away from your recent range, the language is a deviation from your personal baseline, never abnormal. This is wellness information about your own numbers, not medical advice. A local model changes where your data lives, not what the numbers can tell you.

Related reading

• → Connect Apple Health to Claude (and any MCP agent): step by step
• → Apple Health data privacy with AI agents: what stays local, what leaves
• → Export Apple Health data to JSON for AI (the pillar guide)
• → Apple Health JSON vs CSV vs XML: which format AI agents actually want
• → health-export-mcp: the zero-dependency MCP server on GitHub