Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
APPLE_HEALTH_MCP_PORTNoPort for HTTP transport (default 3000)
APPLE_HEALTH_TIMEZONENoTimezone for local-day summaries (e.g., America/Fortaleza)UTC
APPLE_HEALTH_WATCH_PATHNoOptional directory to watch for new exports and auto-reimport
APPLE_HEALTH_EXPORT_PATHNoPath to Apple Health export file or folder (export.zip, export.xml, or apple_health_export/)
APPLE_HEALTH_PRIVACY_MODENoPrivacy mode: summary, structured, or rawsummary
APPLE_HEALTH_MCP_TRANSPORTNoTransport type (e.g., http) for optional HTTP mode

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
apple_health_agent_manifestB

Machine-readable install, runtime and privacy guidance for AI agents operating Apple Health export data.

apple_health_capabilitiesB

Explain supported Apple Health export data, unavailable live HealthKit access, privacy modes and recommended agent workflow.

apple_health_connection_statusA

Check local Apple Health export path, Node version, privacy mode and Hermes client posture without reading full export data.

apple_health_quickstartA

Personalized 3-step setup walkthrough for the human user. Adapts to current state (is APPLE_HEALTH_EXPORT_PATH set? does the export file exist and parse?). Call this first when the user asks 'how do I connect Apple Health?'. This connector is local-first and never touches Apple servers or cloud APIs.

apple_health_demoA

Returns realistic example payloads of apple_health_daily_summary, apple_health_weekly_summary, and apple_health_wellness_context with Apple-Watch-style values, so agents see the contract before parsing a real export.

apple_health_privacy_auditA

Return the local privacy and export-file posture without revealing health data.

apple_health_list_recordsA

List bounded records from a local Apple Health export.xml. Use type/start/end filters to keep output small. limit caps the returned LIST only: in summary privacy mode (the default) the aggregate block (count_by_type, units, date_range, numeric) is computed over every record matching the filter, and truncated/limit_applied/matched_count say whether the list itself was cut. The statistics are nested under numeric (numeric.count/sum/average/min/max), not at the top of aggregate. COST: because the aggregate must cover every match, summary mode reads the whole export file on each new query — roughly 33 ms per MB of export.xml (~3 s for 84 MB, ~11 s for 336 MB), and type/start/end do not shorten it. Repeating an identical query is served from an in-memory cache and returns instantly. For a cheap bounded page with no full-file scan, pass privacy_mode 'structured' or 'raw', which stop at limit.

apple_health_list_workoutsA

List bounded workouts from a local Apple Health export.xml. limit caps the returned LIST only: in summary privacy mode (the default) the aggregate block (count_by_activity, date_range, total_duration_minutes, total_distance, distance_units, total_energy_kcal, workout_count) is computed over every workout matching the filter, and truncated/limit_applied/matched_count say whether the list itself was cut. COST: this call reads the whole export file on each new query — roughly 33 ms per MB of export.xml (~3 s for 84 MB, ~11 s for 336 MB) — and start/end do not shorten it. Workouts are sparse in an export, so even non-summary modes usually reach the end of the file. Repeating an identical query is served from an in-memory cache and returns instantly.

apple_health_export_freshnessA

Check how recently the local Apple Health export file/directory was written. Returns mtime, days_since_export, an is_stale flag, and a recommendation. Considered stale if the export is older than 30 days, or older than 7 days with no recent records (the inventory's latest-record date is also older than 7 days). Use before relying on apple_health_daily_summary or apple_health_wellness_context to confirm the export is fresh.

apple_health_data_inventoryA

Scan the local Apple Health export once and report available record types, workouts, date coverage, freshness and safe next calls.

apple_health_daily_summaryA

Build a daily wellness summary from local Apple Health export data. It is not live HealthKit and not medical advice.

apple_health_wellness_contextB

Normalize local Apple Health export sleep, workout and activity data into the shared wellness_context shape for recommendation engines.

apple_health_weekly_summaryB

Build a weekly wellness summary from local Apple Health export data. It is not live HealthKit and not medical advice.

apple_health_profile_getA

Read the shared Delx Wellness profile from ~/.delx-wellness/profile.json. Returns preferred name, goals, devices, training/nutrition/exercise/agent preferences and safety flags. NEVER contains OAuth tokens or API secrets — this connector is local-export and has no cloud auth, but the profile contract is the same across every Delx Wellness MCP. Read-only.

apple_health_profile_updateA

Persist a partial patch to ~/.delx-wellness/profile.json. Requires explicit_user_intent=true (otherwise returns USER_ACTION_REQUIRED). Rejects secret-like fields (oauth, token, secret, password, cookie, refresh, api_key, session) at write time. Use to record preferred name, goals, devices, training context, nutrition context, exercise preferences, agent preferences, and safety flags.

apple_health_clear_incremental_cacheA

Manually clear the incremental import cache at ~/.apple-health-mcp/incremental-cache.json. The cache tracks the latest parsed timestamp per HealthKit category so subsequent apple_health_list_records calls (with incremental_cache: true) skip already-seen records. Use this when you want to force a full re-parse without changing the export file. The cache also auto-invalidates when the export file mtime changes. Gated by explicit_user_intent: true (requires explicit user intent to wipe local cache).

apple_health_reimportA

Re-scan the configured watch folder (APPLE_HEALTH_WATCH_PATH or setup --watch-path <dir>) for a newer Apple Health export. If a newer export.xml/export.zip/apple_health_export directory is found, it is promoted to the active export, the in-memory snapshot cache and incremental cache are cleared, and subsequent summaries reflect the new data. With check_only=true, only report what would happen without promoting. This is the cross-platform recurring-refresh path — the native HealthKit bridge needs macOS and is separate. Requires explicit user intent when promoting a new export (force or non-check_only); check_only is read-only inspection.

apple_health_onboardingA

Return the 11-question onboarding flow plus the current profile state and missing fields. Read-only — does NOT persist anything. Pair with apple_health_profile_update once the user answers. Cross-connector: the same profile is shared by every Delx Wellness MCP (whoop, garmin, oura, fitbit, strava, polar, withings, apple-health, samsung-health, google-health, nourish, cycle-coach, cgm, air).

Prompts

Interactive templates invoked by user choice

NameDescription
apple_health_daily_reviewReview a day of Apple Health export data with non-medical wellness framing.
apple_health_weekly_reviewReview a week of Apple Health export data with practical habit signals.

Resources

Contextual data attached and managed by the client

NameDescription
apple_health_agent_manifestMachine-readable install and operating instructions for AI agents.
apple_health_capabilitiesStatic capabilities, data boundary, privacy modes and recommended agent workflow.
apple_health_data_inventory_resourceAvailable record types, workouts, date coverage and data freshness for the configured export.
apple_health_daily_summary_resourceDaily Apple Health export summary for the current UTC day.
apple_health_weekly_summary_resourceWeekly Apple Health export summary for the current UTC week window.

TDQS

A3.8/5.0

Scored across 18 tools

Disambiguation5/5

Each tool has a clearly distinct purpose, from listing records and workouts to summaries, profile management, and meta-inspection (privacy audit, capabilities, freshness). Even closely related tools like quickstart and onboarding are differentiated: quickstart is a 3-step setup walkthrough, while onboarding is an 11-question flow paired with profile updates. No two tools appear to do the same thing.

Naming Consistency4/5

All tools share the 'apple_health_' prefix and snake_case convention, creating a strong recognizable pattern. However, there is a mix of verb_noun names (list_records, profile_get, clear_incremental_cache) and noun-only names (capabilities, quickstart, demo, export_freshness), which breaks strict consistency but remains predictable and readable.

Tool Count4/5

18 tools is on the high end of the acceptable range for a health data connector, but each tool addresses a distinct aspect of the domain—setup, status, privacy, data listing, summaries, profiles, cache management, and reimport. The count feels justified given the breadth of functionality, though it could be streamlined by consolidating some meta/status tools.

Completeness4/5

The tool surface covers the core lifecycle of working with Apple Health export data: onboarding, listing, summaries, wellness context, profile management, freshness checks, and cache/reimport operations. Minor gaps exist (e.g., no direct tool for specific metric queries like heart rate or steps beyond list_records with filters), but agents can achieve these via the available tools. Overall, it supports the primary workflows without dead ends.

Maintenance

ActivityActive
ResponsivenessNo issues