Semantic Search MCP Servers for Apple Health: What Retrieval Adds

Does semantic search actually help with your Apple Health data? It earns its keep for one kind of question, and quietly fails the one you probably care about most.

A new class of Apple Health MCP server does not only read your export. It chunks your records, embeds them into a vector store, and answers by similarity. That is the same RAG pattern people use for documentation. Health data makes it harder, because most of the payload is numeric time series rather than prose.

What retrieval actually buys you

Semantic retrieval works when you ask about text you wrote (notes, symptoms, journal entries) or about a metric whose exact name you forgot. Instead of exposing only a query_health_data tool, these servers retrieve by meaning, so a fuzzy question can surface the right rows.

It adds almost nothing to "what was my average HRV last week". That answer is arithmetic on exact samples, not the nearest vector. Similarity is not arithmetic: "resting heart rate 61" and "resting heart rate 610" can sit close together in embedding space.

Three real projects doing it now

The pattern is already public:

• Barbaroso/apple-health-semantic-mcp reads export.zip into DuckDB and adds a "clinical semantic layer". Its stated reason is the interesting part: Apple Health is full of traps that produce confidently wrong answers, like percentages stored as fractions, sleep that changes date at midnight, and three apps recording the same metric.
• Svetafo/health-agent is a self-hosted agent that stores health history in pgvector and runs in Telegram. It is built around remembering what matters across months.
• Community RAG tutorials, like the DuckDB plus Pinecone walkthrough on DEV, wire LangChain to an Apple Health export and vectorize it. Useful as a pattern, but it is explicitly a build-it-yourself pipeline.

Notice what each one had to add: a database (DuckDB or Postgres), an embedding step, and a vector index.

What the second pipeline costs

Retrieval is not free. You add ingest, an embedding model, and a vector store, and you rebuild the index every time your export refreshes. Most of these pipelines call a cloud embedding model, which puts health data on someone else's server.

The zero-dependency counter-position

A read-only server that just reads a JSON file is a different shape. Ours ships 16 tools and 22 prompts, makes zero runtime network calls, and answers on-device with provenance cards that show the exact numbers used. No vector store, because the numbers never needed one.

Retrieval is a great tool for text. For the arithmetic, compute it.

Wellness, not medical.

Read the full post at https://dub.sh/vogHdf5