Samsung Health Analytics MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ingest_exportA | Load a Samsung Health export (.zip or extracted folder) into the local database, replacing the old one. Takes about 10 seconds. Re-run whenever the user downloads a fresh export. |
| set_periodsA | Save the periods to compare, e.g. [{"name": "Before", "start": "2025-01-01", "end": "2025-06-30"},
{"name": "After", "start": "2025-07-01"}]. |
| overviewC | Date range, data coverage per metric, available metrics and the periods being compared. |
| monthly_trendsB | Monthly averages per metric with month-over-month % change (mom_pct). Dates are YYYY-MM-DD. home_only=True drops travel days. Metrics default to the core set; see overview() for all keys. |
| compare_periodsA | Compare two periods. Either names from set_periods (defaults: the first two), or ad hoc ranges a_range/b_range like "2025-03-01..2025-03-31" (period_a/period_b then become their labels). Returns mean/median/n per period, delta %, Cohen's d and a plain verdict per metric. Travel days excluded by default. |
| tripsB | Trips detected from the phone's timezone (no location data needed), each compared with the 30 home days before it, plus the overall travel effect on steps, sleep and heart rate. |
| hourly_profileC | Average steps for each hour of the day (0-23), per period. Shows when you move. |
| weekday_profileC | Average of a metric per weekday (Mon..Sun), per period. Useful for weekend effects (Sat/Sun vs Fri/Sat). |
| sleep_timingC | Bedtime, wake time, sleep hours, split nights and bedtime consistency (std dev in minutes) per period. |
| rolling_baselineB | Each day's value against your own trailing baseline, with a z-score. |z| > 2 is unusual for you. |
| detect_locationsB | Timeline of contiguous UTC-offset runs: homes and trips. Use it to suggest periods (e.g. a move). |
| workoutsC | Recorded exercise sessions grouped by month, period and type. |
| schemaA | Tables and columns available to run_sql. |
| run_sqlB | Run a read-only DuckDB query. Main table: |
| dashboard_payloadA | Everything the dashboard renders, including precomputed |
| render_dashboardA | Render the single-file dashboard with the story you wrote from the payload.
actions: 3 items of {title, detail, metric, target}, each grounded in a payload number.
headline: one sentence, the most important finding. subtitle: one line of context.
callouts: labels on the 24h clock, e.g. [{"hour": 6, "text": "Morning run"}], only for causes the user confirmed.
travel_note: one or two sentences about the user's travel, from |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
Each tool targets a distinct analysis surface (trends, periods, trips, sleep, workouts, SQL). There is mild overlap between overview and dashboard_payload (both summarize the dataset), and between trips and detect_locations (both derive travel), but descriptions make the split between summary/payload and analysis/raw-timeline reasonably clear.
All names are snake_case and readable, but the convention is mixed: several are verb_noun (ingest_export, set_periods, render_dashboard, compare_periods, run_sql) while others are bare nouns (overview, trips, workouts, schema, sleep_timing). The inconsistency is minor but visible across 16 tools.
16 tools is just over the comfortable band but justified by a genuinely broad analytics domain (ingestion, overview, trends, profiles, comparisons, travel, SQL escape hatch, dashboard). No single tool looks trivially redundant, though the overview/dashboard_payload pair could likely merge.
Coverage is strong: ingestion, schema inspection, raw SQL, period definition, trends, comparisons, profiles, sleep, baselines, trips, workouts, and dashboard output. Minor gaps exist around exporting analysis results or persistent saved analyses, but agents can work around them via run_sql.