Introducing Apple Health MCP Server: Open-Source Bridge Between Health Data and AI

Momentum is taking a new step in open source: the Apple Health MCP Server.

Healthcare generates some of the richest personal datasets available, yet they are often locked away in proprietary formats or scattered across devices. At the same time, the Model Context Protocol (MCP) is emerging as a new standard for how AI systems handle context. By bringing the two together, we’ve built a server that allows large language models to query, analyze, and visualize Apple Health data directly without endless manual preprocessing.

Why does this matter? If you’re a developer, this project shows how to work with MCP tools in practice, including parsing, indexing, and querying health data at scale. If you’re a clinician, researcher, or healthtech founder, it demonstrates how everyday Apple Health exports can be turned into meaningful insights with AI while keeping privacy and compliance in focus.

In this article, we’ll cover:

• What MCP is and why it’s important
• How our Apple Health MCP Server works under the hood
• Example use cases for athletes, coaches, doctors, researchers, and patients
• Key challenges (privacy, usability, scale) and how we’re addressing them
• Our roadmap and why we’re contributing this as open source

The goal isn’t just to show code, it’s to share an approach. We believe making healthcare technology simpler and more open benefits everyone, and this project is one step in that direction.

What is MCP (Model Context Protocol)?

The Model Context Protocol (MCP), introduced by Anthropic in November 2024, is one of the latest innovations in AI communication protocols. It is designed to standardize and enhance how AI models interact with their environments, and it’s already gaining traction across the industry. Major companies such as Google, Meta, and Microsoft are investing resources into adopting and shaping this new technology.

MCP is an open protocol that defines how contextual information is passed to AI models,  including both textual and structured data. It provides a standardized way to inject information like documents, system metadata, user preferences, and other dynamic content into the model. This allows for more efficient context management, enabling models to better understand their environment, dynamically adapt to real-time inputs, and produce more coherent, context-aware responses. For developers, it also means greater control and easier fine-tuning of model behavior across different applications.

Since its launch, MCP has been evolving at an exceptionally fast pace. New releases of programming frameworks often introduce significant changes to protocol implementations, making it difficult for developers to keep up. Integrating the newest versions into production systems requires agility, deep technical knowledge, and constant monitoring of updates not only to MCP itself but also to the tools around it.

We’ve experienced this first-hand. At one point, we implemented authorization using a code-based mechanism, following documentation and public examples that were just a few months old only to find them already outdated. Midway through our integration, a new framework version was released that completely redefined authentication and authorization. It introduced breaking changes that forced us to rework significant parts of our codebase. This kind of disruption is now common in the MCP ecosystem and highlights the need for a highly adaptive development process.

If you’d like a broader introduction to communication protocols, we’ve also written an article that explains what they are and how they work.

Why we built the Apple Health MCP Server

The Apple Health MCP Server project is an open-source bridge between Apple Health XML exports and MCP-compatible AI clients. It enables large language models to query, analyze, and visualize personal health and fitness data in natural language without requiring manual preprocessing.

We’re developing this project with three motivations in mind:

1. Staying up to date with MCP

MCP is evolving quickly, and the most effective way to stay aligned with its latest changes is to work with it directly. Building on top of MCP helps us keep pace with its shifting structure and surrounding ecosystem.

2. Providing users with a tool to extract insights from their Apple Health data

Millions of people generate large volumes of personal health data, but few have simple ways to turn it into meaningful analysis. This project closes that gap, enabling AI-driven insights instead of raw data dumps.

3. Using MCP as a practical playground for wearable data analysis

Apple Health exports provide the perfect sandbox to experiment with real-world challenges: structuring time-series data, managing context windows, and tailoring AI outputs to user-specific needs.

How the Apple Health MCP Server works

Apple Health XML structure

Apple Health allows users to export their entire health history as a single XML file (export.xml). This includes data from Apple devices, third-party apps, and connected wearables.

The general structure looks like this:

• HealthData – root container of the dataset
• ExportDate – timestamp of the export
• Me – user profile information
• Record – individual health measurements (the bulk of data)
• Workout – structured workout sessions
• ActivitySummary – daily activity rings
• WorkoutRoute – GPS coordinates for workouts

Each <Record> entry includes:

• type – metric type (e.g., step count, heart rate)
• sourceName – data source (Apple Watch, iPhone, third-party app)
• value – the measurement
• unit – unit of measure (count, kcal, bpm)
• startDate / endDate – measurement window
• creationDate – when the data was saved

Scale and scope

In our tests, one dataset contained ~2.8 million records (~1 GB) spanning 8 years of continuous tracking. This scale is fairly typical for long-term Apple Watch users.

For experimentation, we used Predict My Sleep Patterns by Rob Mulla (2023), available on Kaggle: Google Drive copy.

Most common categories (percentage of all records):

• Active Energy Burned ~30%
• Heart Rate ~15%
• Basal Energy Burned ~11%
• Distance Walking/Running ~10%
• Step Count ~9%

Other frequent metrics include exercise minutes, running data, and stand hours.

Data characteristics

• 2015–2018: fewer but larger aggregated records (e.g. 300–600 steps per entry).
• 2020–2023: more frequent, smaller records (20–250 steps each).
• Heart rate is highly granular (every few seconds during workouts; every 5–10 minutes at rest).
• Step counts shifted from batch logging to near-continuous sampling over time.

Data sources

• Apple devices (iPhone, Apple Watch)
• Third-party apps (Strava, Polar Flow, etc.)
• External hardware (chest straps, cycling sensors)
• Manual entries (e.g., weight, blood pressure)

This multi-source approach brings richness and accuracy but also creates redundancy, making it challenging to unify overlapping records. In real-world scenarios, having an iPhone and an Apple Watch track the same metrics simultaneously can lead to data duplication and integration complexities.

Beyond basic fitness

The XML export includes far more than just steps and calories. Additional categories often found in long-term datasets include:

• Heart health metrics (resting HR, variability, high/low event flags)
• Advanced performance data (VO₂ Max, cadence, stride length, running power)
• Environmental exposure (ambient noise levels)
• Body metrics (weight, BMI, height)
• Wellness tracking (sleep, mindfulness sessions)
• Safety events (falls, blood oxygen levels)

Taken together, these categories make Apple Health exports a uniquely rich dataset — ideal for testing MCP’s ability to handle large, diverse context inputs.

Exporting Apple Health XML Data to Elasticsearch

Once Apple Health data is exported into an export.xml file, it can be loaded into a search-friendly database such as Elasticsearch. This enables fast querying, filtering, and aggregation across millions of records – tasks that would be slow or impractical with raw XML alone.

In our implementation, we use a custom Python class, ESIndexer, to parse the XML, convert values into consistent formats, and send them to Elasticsearch in bulk.

Parsing and converting data

The first step is to read the XML and extract the relevant attributes from each <Record> element. During this process, the parser normalizes dates into ISO 8601 format and converts numeric values into floats, making later analysis easier and more reliable.

def parse_xml(self) -> Generator[dict[str, Any], None, None]:
    tree = ET.parse(self.es.xml_path)
    root = tree.getroot()
    for child in root:
        document: dict[str, Any] = child.attrib.copy()

        if "startDate" in document:
            document["startDate"] = self.convert_str2datetime(document["startDate"])
            document["dateComponents"] = document["startDate"]
        if "endDate" in document:
            document["endDate"] = self.convert_str2datetime(document["endDate"])

       # [...]

        yield document

Bulk Indexing to Elasticsearch

Once parsed, the data is sent to Elasticsearch using its bulk API for speed and efficiency.

def index_to_es(self, documents: list[dict[str, Any]]) -> None:
    actions = [
        {"_index": self.es.index, "_source": document}
        for document in documents
    ]
    helpers.bulk(self.es.engine, actions)
    print(f"Indexed {len(actions)} documents into '{self.es.index}'")

Tools overview

app/
└─ mcp/
   └─ v1/
      ├─ mcp.py
      └─ tools/
         ├─ es_reader.py
         └─ xml_reader.py

The project uses a router-like structure inspired by FastAPI:

• xml_reader.py and es_reader.py each define their own FastMCP server instance and encapsulate their respective tools.
• mcp.py creates a global FastMCP server instance and mounts these sub-servers using the mount() method.

This modular structure keeps the codebase clean, maintainable, and straightforward to extend with additional tools.

es_reader_router = FastMCP(name="ES Reader MCP")


@es_reader_router.tool
def get_health_summary_es() -> dict[str, Any]:
	...

es_reader.py

xml_reader_router = FastMCP(name="XML Reader MCP")


@xml_reader_router.tool
def get_xml_structure() -> dict[str, Any]:
	...

xml_reader.py

from app.mcp.v1.tools import es_reader, xml_reader

mcp_router = FastMCP(name="Main MCP")

mcp_router.mount(es_reader.es_reader_router)
mcp_router.mount(xml_reader.xml_reader_router)

mcp.py

In the top-level main.py, responsible for starting the server, the global router is imported and mounted into the final MCP server instance:

from app.mcp.v1.mcp import mcp_router

mcp = FastMCP(settings.PROJECT_NAME)

mcp.mount(mcp_router)

Execution logic for each tool is delegated to dedicated service modules located in app/services/health/.

• elasticsearch.py handles Elasticsearch queries.
• xml.py processes XML data.

This separation creates a clear boundary between the MCP tool interface and the underlying business logic, which improves maintainability and makes testing much easier.

Elasticsearch-based analysis

The MCP server provides a set of tools for analyzing Apple Health data once it has been indexed into Elasticsearch. These tools fall into three categories:

Summary & statistics

• get_health_summary_es – overview of total records, type breakdowns, and date ranges
• get_statistics_by_type_es – detailed stats (min, max, avg, count) for specific health metrics
• get_trend_data_es – time-series analysis with configurable intervals (day, week, month, year)

Search & query

• search_health_records_es – flexible querying with filters for date ranges, values, sources, and record types
  
  • Supports complex filtering (e.g., by value ranges, time periods, or data sources).

XML file analysis

• get_xml_structure – analyze file structure, record types, and sources without loading the entire file
• search_xml_content – find specific content within XML files using pattern matching
• get_xml_by_type – extract all records of a given type for detailed analysis

Use cases

Once the data is parsed and indexed, the real value comes from how it can be applied. From athletes fine-tuning their training to doctors monitoring recovery, here are some of the most practical use cases we’ve explored.

Use case 1: Athletes and active individuals

For athletes and fitness enthusiasts like runners, cyclists, gym-goers, the MCP server can transform Apple Health data into actionable training insights. By connecting an LLM to their workout history, users can:

• Track recent performance trends against personal baselines
• Generate personalized training plans
• Receive recommendations for rest days, pacing strategies, or alternative workouts based on recovery data, heart rate zones, and training load

Example applications

• Marathon runners fine-tuning pacing strategies
• Cyclists monitoring power output trends
• Gym-goers balancing endurance and strength training

Example prompt:

“I want to prepare for a marathon. Can you advise me on how to prepare based on my data?”

Example response (useful insights):

• Proven marathon experience: Completed a 26.46-mile run in March 2022
• Strong long-run capacity: Multiple 15–20+ mile runs in early 2022
• Good running speed: Avg. 6.2 mph (9:40/mile) – strong marathon base pace
• Excellent cardiovascular health: VO₂ Max 48.3, resting HR 52–55 bpm
• Max running speed: 13+ mph, showing strong speed reserve
• Target easy pace: 10:30–11:30/mile, based on current capability
• Training plan guidance: Start long runs at 8–10 miles, increase by 1–2 miles weekly
• Leveraging strengths: With VO₂ Max and speed reserve, a sub-4:00 marathon (9:09/mile average) is realistic
• Phase 2 (Weeks 9–16): Build and strengthen; use 13+ mph top speed to train anaerobic power

Use case 2: Doctors and healthcare professionals

For clinicians, the MCP server can act as a complementary layer of patient data analysis. By aggregating long-term trends from wearable devices, an LLM can:

• Highlight anomalies in patient health metrics
• Correlate lifestyle patterns with changes in symptoms
• Support preventive care through continuous monitoring

It’s important to note: this is not a diagnostic tool, but a way to enrich clinical decision-making with additional context from wearable data.

Example applications:

• Monitoring recovery after surgery
• Detecting irregular sleep patterns or persistently elevated heart rate
• Observing how lifestyle changes affect chronic conditions

Use case 3: Fitness coaches and personal trainers

For coaches, the MCP server provides a fast way to translate Apple Health data into actionable coaching insights. Instead of manually parsing through records, coaches can:

• Generate automated progress reports
• Calculate training load and recovery patterns
• Deliver client-specific recommendations while freeing up more time for personalized feedback

Example applications:

• Tracking athlete readiness before competitions
• Detecting overtraining risk in high-intensity programs

Example prompt:

“I was preparing for a running competition. Can you detect overtraining risks?”

Example response (useful insights):

• Competition timeline advice: Based on RHR spikes in the data, schedule easy/recovery weeks 2–3 weeks before competition. Taper gradually and prioritize sleep and recovery over last-minute training gains.
• Daily readiness check: Monitor RHR trends; if resting heart rate rises >10% above baseline, take a rest day.

Use case 4: Wellness and lifestyle tracking

For individuals focused on overall well-being (beyond sports performance) the MCP server can highlight lifestyle trends in sleep, activity, and mindfulness practice. With LLM-powered analysis, users can set realistic goals, such as:

• Improving average daily step count
• Reducing resting heart rate
• Increasing sleep consistency

Example applications:

• Stress management by correlating heart rate variability with work patterns
• Detecting low-activity days and adjusting daily habits accordingly

Example prompt:

“Can you identify days of low activity to adjust daily habits?”

Example response (useful insights):

• Priority focus: The data shows the biggest opportunity lies in evening hours and during extended work periods.
• Actionable step: Start with simple 5-minute movement breaks and build gradually.
• Impact: Even small increases can make a significant difference given the current baseline.

Use case 5: Research and data analysis projects

For researchers, the MCP server makes it possible to work with anonymized multi-user datasets without manual parsing. This opens the door to studying:

• Long-term health trends across populations
• Correlations between lifestyle metrics and outcomes
• Environmental or seasonal effects on health indicators

Example applications:

• Investigating how daylight hours influence physical activity
• Comparing recovery patterns across different age groups

Example prompt:

“How do daylight hours affect my physical activity?”

Example response (useful insights):

• Spring peak (March–May): Highest activity levels occur during spring months when daylight is rapidly increasing, suggesting strong responsiveness to seasonal transitions.
• Summer plateau: Activity levels flatten, possibly due to heat or vacation patterns.
• Practical advice: Consider light therapy or structured indoor activities during winter to maintain consistency year-round, and leverage natural spring energy peaks for setting fitness goals.

Use case 6: Rehabilitation and physiotherapy

For patients in rehabilitation, MCP-enabled insights can help track adherence to prescribed exercises and monitor progress over time. The system can also flag irregularities or plateaus in mobility-related metrics, giving both patients and clinicians early signals to adjust treatment.

Example applications:

• Tracking mobility recovery after surgery
• Remote monitoring of physiotherapy patients

Challenges and solutions

Building a system that connects personal health data with AI is powerful, but it doesn’t come without obstacles. Along the way, we’ve identified several challenges that need to be addressed for this approach to be practical, secure, and widely usable, along with the solutions we’re exploring.

Challenge 1: Privacy and security of health data

Health data is among the most sensitive information users can share, so it’s natural to ask how it will be handled when connecting to the MCP server. Even though the server is designed primarily for analytics and insight extraction, its scope can include the entirety of a user’s Apple Health export, making security and privacy critical.

Planned solution

• The MCP server runs locally by default. Parsing, indexing, and querying all happen on the user’s own machine, ensuring no health data leaves the local environment.
• The only case where data leaves is if the MCP server connects to a cloud-hosted LLM (e.g., Claude or ChatGPT) that processes the data externally.
• For users who prefer to stay fully on-premise, the MCP server can connect to locally hosted LLMs such as:
  
  • gpt-oss-20b (runs on a medium laptop)
  • gpt-oss-120b (requires more powerful hardware but runs entirely on local infrastructure)
• Another option is integration with Azure OpenAI, which can be operated in a HIPAA-compliant way under a signed Business Associate Agreement (BAA).

Limitations

• True privacy depends on where the connected LLM is running. If a public API is used, the relevant data will be sent to that provider.
• Running large local models requires substantial hardware resources.
• HIPAA compliance is dependent on the cloud provider and on proper contractual agreements being in place.

Challenge 2: High entry barrier for non-technical users

Running the MCP server today requires a Python environment, Elasticsearch configuration, and command-line setup. Even with tools like Claude Desktop, we encountered friction points such as:

• Unclear error messages when MCP connections fail
• No simple “one-click” installation process
• Manual handling of JSON config files (a must-have for setup)

Planned solution

• We plan to leverage Desktop Extension (dxt) (issue #6), a technology introduced by Anthropic in June 2025.
• With a small JSON configuration file added to the project, a ready-to-run installer is generated automatically.
• A user can simply click the installer, and it will set up the MCP server in their AI client (no manual configuration or scripts required).
• This would make onboarding nearly frictionless, even for non-technical users.

Limitations

• dxt is very new technology (released June 2025) and still maturing.
• Works best with Node.js-based projects; Python support is limited and does not integrate smoothly with environments like uv.
• Currently exclusive to Claude Desktop; wider adoption depends on other MCP-compatible clients adding support.
• As the ecosystem evolves, early adopters may face breaking changes or undocumented behavior.
• Installation of third-party dependencies (like Elasticsearch) is not fully solved by this approach.

Challenge 3: No official Apple Health API

Apple Health does not provide a public API for direct programmatic access to user data. Currently, the only options are:

• Using third-party export apps that generate .xml files
• Manual export from the Health app on iOS

Both approaches require extra steps, break automation, and may raise trust concerns with third-party tools.

Planned solution

• Build support for streamlined XML ingestion, whether from manual exports or known, trusted apps
• Automatically parse and index the data into Elasticsearch for immediate use

Limitations

• Without native integration into iOS, real-time access to Apple Health data is not possible
• The system will remain limited to manually exported XML files

Challenge 4: Lack of optimization for high-frequency sampling data

Metrics like heart rate, motion, and GPS can generate millions of records in long-term datasets. In our own tests, we processed ~2.8M records spanning 8 years (~1 GB).

At present, all records are indexed individually. This creates three main issues:

• Slow queries over long time ranges
• Large payloads when sending data to MCP tools
• Overly granular outputs in LLM responses

Planned solution

• Implement specialized MCP tools for high-frequency data (issue #8) that:
  
  • Aggregate records by time windows (minute, hour, day)
  • Provide summary statistics instead of raw dumps (partially supported already)
  • Reduce memory footprint and improve LLM performance on time-series insights
• Evaluate alternative databases such as ClickHouse or DuckDB for handling large, append-only time-series datasets more efficiently

Challenge 5: Irregular sampling intervals and redundant measurements

Apple Health data is often recorded at irregular intervals. For example, one workout segment might capture measurements every few seconds, while another spans ten minutes. This inconsistency makes accurate time-series analysis and meaningful comparisons more difficult.

In addition, metrics are frequently logged by multiple devices simultaneously. For instance, both an iPhone and an Apple Watch tracking the same workout. This leads to duplicate entries.

Together, these issues can:

• Distort analyses
• Inflate storage requirements
• Produce overly verbose or inconsistent outputs from LLMs

Planned solution
Enhance XML data import tools to:

• Resample time-series data into uniform intervals for consistent analysis
• Detect and remove duplicates from overlapping device measurements
• Preserve raw data for scenarios where high-precision analysis is required

The result: cleaner, smaller datasets that are easier to query and yield more reliable insights.

Roadmap

You can explore the full roadmap in our GitHub Issues. Some items are marked with the good first issue label — perfect entry points for anyone who wants to step into open source and get hands-on experience with the project.

Here are a few of the most interesting and impactful items currently on our roadmap (as of August 2025):

• Support for HTTP communication beyond stdio
• Specialized MCP tools for high-frequency data (issue #8)
• Desktop extension support (issue #6)
• Support for string values in records (issue #7)
• Evaluation of in-memory database solutions for large time-series datasets
• Improved XML import tools for sampling normalization and duplicate removal

Why Momentum is contributing

From the beginning, our goal at Momentum has been to make healthcare technology simpler, more open, and more useful for the people who rely on it. The Apple Health MCP Server is a natural extension of that philosophy.

By releasing this project as open source, we’re doing three things at once:

• Simplifying healthcare tech: turning raw, messy data into clean, AI-ready insights.
• Building reusable building blocks: code that others can adapt, extend, and apply in their own projects.
• Staying ahead of MCP: working directly with the protocol as it evolves keeps us — and the community — ready for what’s next.

Ultimately, this isn’t just about Apple Health or Elasticsearch. It’s about setting a precedent for how AI can responsibly interface with sensitive, complex healthcare data — and making those lessons available to anyone.

We’d love for you to explore the repo, try it out with your own Apple Health exports, and share feedback or contributions. Open source works best when it’s collaborative, and this is our invitation to build the future of healthtech with us.