Iridium MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| IRIDIUM_SYNC_ID | Yes | Your Iridium Sync ID, found in the Iridium app under Settings > AI Data Sync. | |
| IRIDIUM_SYNC_KEY | Yes | Your Iridium Sync Key, found in the Iridium app under Settings > AI Data Sync. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_workout_historyA | Get recent workout history with optional filtering by date range or category. Returns workout summaries including date, exercises performed, duration, and completion status. Dates accept 'today', 'yesterday', 'YYYY-MM-DD', or a full ISO 8601 timestamp; bare dates are interpreted as whole days in the user's LOCAL timezone, so an early-morning session and a late-evening one on the same day both come back from a single-day query. To ask about one specific day, pass the SAME date as both |
| get_workout_detailA | Get full details of a specific workout including all exercises, sets, weights, reps, RPE, and block structure. |
| get_nutrition_logA | Get DAILY NUTRITION SUMMARIES over a date range — one row per day with the user's actual consumed totals (live, computed from the food log on every call), their goals and targets for that day, hydration intake/goal when available, and any day notes (e.g. 'I didn't log everything today', 'was sick'). Use this for daily check-ins, trends, goal checking, and weekly/monthly review. For individual food-level detail (name + all nutrients per entry), use |
| get_nutrition_goalsA | Get the user's current nutrition intent — what they are trying to do with food right now. Returns: |
| get_food_entriesA | Get full individual food entries with name, macros, and all nutrients — plus hydration entries and a |
| log_food_entryA | Log a single food entry (cheeseburger, snack, meal, etc.) into the user's Iridium food diary. Required: name + calories + protein + carbs + fat (grams). IMPORTANT: calories and macros MUST be the totals for the amount actually consumed, NOT per-serving values. If the user ate 2 servings of a 200-cal item, send calories: 400. Optional: any micros you are confident about (fiber, sugar, sodium, vitamins, etc.) — omit values you don't know rather than guessing. WATER: do NOT log drinking water here. This tool has no water field — use |
| update_food_entryA | Update a food entry you previously logged via log_food_entry — e.g. if the user says "wait, that was 2 cheeseburgers, not 1" or "actually that had no cheese." Required: id (from the prior log_food_entry response). Only pass fields you actually want to change — omitted fields stay as they were. IMPORTANT: if you are changing calories or macros, they must still be the TOTAL for the amount actually consumed, not per-serving. This tool only works on entries that were logged via chat in the first place. If the entry was logged in the Iridium app itself, you will get a 404 — apologise and let the user edit it in the app. |
| list_my_foodsA | List the user's saved reusable foods ("My Foods" in Iridium) — things like their homemade shakes, favourite bars, go-to salads. Call this FIRST whenever the user refers to a food by name as if it were already known — for example: "log my blueberry shake," "another Nuun," "my usual lunch." If a match exists, reuse its macros and pass the MyFood's name verbatim to log_food_entry so the logged entry reads naturally. Scale macros by the actual servings consumed if it differs from the default (defaultServingSize / defaultServingUnit). If nothing matches, fall back to your own macro knowledge. You usually only need to call this once per conversation. |
| log_hydrationA | Log water (or any hydrating drink volume) into the user's Iridium hydration tracker. USE THIS — not |
| get_hydrationA | Get the user's water intake — individual hydration entries plus per-day totals against their saved hydration goal. Use this for 'how much water have I had today?', 'am I hitting my hydration goal?', or any question about fluid intake. Each day in |
| update_hydration_entryA | Correct a hydration entry you previously logged via |
| get_exercise_progressA | Get performance history and 1RM trends for a specific exercise. Shows recent sets, weight progression, and estimated one-rep max over time. |
| get_personal_recordsA | Get personal records (PRs) across all exercises or for a specific exercise. Shows best 1RM, heaviest weight, most reps, and when each PR was set. |
| get_body_measurementsA | Get body measurement history including weight, body fat percentage, and other measurements over time. Dates accept 'today', 'yesterday', 'YYYY-MM-DD', or ISO 8601; bare dates are whole days in the user's local timezone. Each measurement carries its own |
| get_profileA | Get the user's profile including demographics, training goals, methodology, experience level, and app settings. |
| get_training_summaryA | Get aggregate training statistics including total workouts, exercise frequency, streaks, and workout patterns. |
| get_training_volumeB | Get volume adaptation records showing how training volume has been adjusted for each muscle group over time, including fatigue levels and recovery decisions. |
| get_trainer_analysisB | Get weekly AI trainer analysis logs containing training recommendations, progress assessments, and coaching insights. |
| get_weekly_scheduleB | Get the planned weekly training schedule showing which muscle groups or workout types are assigned to each day. |
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 19 tools
Most tools have clearly distinct purposes, with detailed descriptions that clarify overlaps (e.g., get_nutrition_log vs get_food_entries). A few pairs like get_workout_history/get_workout_detail and get_exercise_progress/get_personal_records could cause minor confusion, but descriptions resolve boundaries.
All tools follow a consistent verb_object pattern in snake_case (e.g., get_*, log_*, update_*, list_*). No mixing of conventions like camelCase or inconsistent verb styles.
19 tools cover the full domain of fitness tracking (training, nutrition, hydration, body measurements, profile) without feeling bloated or sparse. Each tool serves a clear purpose within the scope.
Covers nutrition and hydration entry well, but training tools are mostly read-only (no create/update workouts, no log training sessions). Body measurements are get-only. Notable gaps in data entry for training and measurements limit full lifecycle coverage.