Skip to main content
Glama
RosTeHeA

Iridium MCP Server

by RosTeHeA

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
IRIDIUM_SYNC_IDYesYour Iridium Sync ID, found in the Iridium app under Settings > AI Data Sync.
IRIDIUM_SYNC_KEYYesYour 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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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 from and to. IMPORTANT: a day often contains MORE THAN ONE workout — report every workout in the response, not just the first or the most recent.

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_food_entries instead. Dates accept 'today', 'yesterday', 'YYYY-MM-DD', or full ISO timestamps; bare dates are interpreted in the user's local timezone. IMPORTANT — each summary row includes: (a) consumed — an object with the day's actual totals (calories, protein, carbs, fat, fiber, sugar, sodium, cholesterol, saturatedFat, transFat); always live, includes food logged via this tool earlier even before the iOS app has synced, (b) calorieGoal — the static BASE: BMR ± weight-goal deficit, BEFORE activity, (c) effectiveCalorieGoal — the real daily target that includes activeCalories burned and the daily-minimum floor; matches what the Iridium app actually displays. (d) hydration — an object with consumedML, goalML, remainingML, progress, and individual hydration entries when hydration data exists. ALWAYS compare consumed.calories vs effectiveCalorieGoal, not vs calorieGoal. For water/hydration, compare hydration.consumedML vs hydration.goalML when goalML is present. Some rows may have consumed populated but no goal fields — that's a day where food was logged before any goal-bearing data existed for that day; fall back to the top-level goals for targets. The same applies to the goals object at the top level for today.

get_nutrition_goalsA

Get the user's current nutrition intent — what they are trying to do with food right now. Returns: goalType (lose | maintain | gain), weeklyWeightChangeGoal (e.g. -1 for losing 1 per week; negative means loss, positive means gain) with weeklyWeightChangeUnit (lbs or kg), daily targets calorieGoal / proteinGoal / carbGoal / fatGoal (grams for macros), hydration fields when available (hydrationGoalML, hydrationGoalOz, and hydration for today's consumed/goal/progress), and mode context (calorieGoalMode, macroDistributionMode, macroPriority, macroPresetSplit). IMPORTANT — calorieGoal is the LIVE EFFECTIVE target for today, matching what the Iridium app shows on the Nutrition tab. In automatic + HealthKit-active mode this includes today's active calories burned, so it changes throughout the day as the user moves. The static base (BMR ± deficit, before activity) is exposed separately as calorieGoalBase. When you compare consumed vs target, ALWAYS use calorieGoal (not calorieGoalBase). The optional todaySnapshot field breaks down where the number came from: restingEnergyBurned (BMR), activeCalories, goalMode, hydration, and lastUpdated (the iOS sync timestamp — be aware the active-calories and hydration numbers may be a few minutes stale). Use this when coaching the user ("am I on track?", "how much room for dinner?", "is this deficit aggressive or conservative?"), or whenever your recommendation depends on whether they are cutting, bulking, or maintaining. Combine with get_food_entries(date: today) for what has already been consumed.

get_food_entriesA

Get full individual food entries with name, macros, and all nutrients — plus hydration entries and a hydrationByDay rollup with consumed water and saved daily goals when available — for a single day or a date range (up to 90 days). Use this when the user asks about WHAT they ate ("what did I eat yesterday?", "show me everything I logged this week", "what was my dinner Tuesday?") or when you need entry-level detail for analysis (meal patterns, top sources of a macro, identifying repeat items, etc.). For daily totals / goal tracking / trends, use get_nutrition_log instead. Pass EITHER date (single day) OR from + to (range). Date parameters accept 'today', 'yesterday', 'YYYY-MM-DD', or full ISO timestamps; bare dates are interpreted in the user's LOCAL timezone so late-night meals correctly land on the same day the user went to bed. Ranges are inclusive on both ends and capped at 90 days; results are capped at 1000 entries with a truncated flag if that cap hits.

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 log_hydration, which is the only thing that feeds the hydration ring the user sees. For a drink that is both food and fluid (shake, juice, milk), log the calories/macros here AND the volume with log_hydration. The entry appears in the iOS app on the next sync (typically within minutes when the app is foregrounded). DATE/TIMEZONE: pass date in any of these forms — 'today', 'yesterday', 'YYYY-MM-DD', 'today T14:00', 'yesterday 14:30', 'YYYY-MM-DDTHH:MM:SS', or a full ISO 8601 timestamp with offset. All bare/relative forms are interpreted in the user's local timezone, so 'yesterday' lands on the user's yesterday — you do not need to know their timezone. DEDUPLICATION: calls with identical arguments within one hour are deduplicated (the same entry is returned, not a new one). If the user genuinely ate the same thing twice and wants two entries, set numberOfServings: 2 on a single call, OR include a differentiating value like a distinct notes line or a more specific date on the second call.

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 log_food_entry — whenever the user says they drank water, e.g. 'I had a glass of water', 'log 16 oz of water', 'just finished my water bottle'. The water field on a food entry is the water CONTENT of that food and does NOT count toward the hydration ring the user sees in the app; only this tool does. Pass EITHER amountOz OR amountML — give whichever unit the user used and the server stores both. Common volumes: a cup is 8 oz, a pint 16 oz, a standard bottle 16.9 oz (500 mL), a litre 33.8 oz. If the user drank something that is both food and fluid (a protein shake, juice, milk), log the calories and macros with log_food_entry AND the fluid volume with this tool — they are separate records and the app expects both. Plain water needs only this tool. DATE/TIMEZONE: date accepts 'today', 'yesterday', 'YYYY-MM-DD', 'today T14:00', 'yesterday 14:30', or a full ISO 8601 timestamp; bare and relative forms resolve in the user's local timezone. Defaults to now. DEDUPLICATION: identical calls within an hour are treated as the same entry. For a genuine second drink, pass a more specific date or a distinguishing note.

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 byDay carries consumedML/consumedOz, goalML/goalOz, remainingML, and progress (0-1) when a goal exists for that day. Compare consumedML against goalML, and report in whichever unit the user speaks in. Note this covers hydration only — it does NOT include the water content of foods, which the Iridium app also excludes from the hydration ring. Dates accept 'today', 'yesterday', 'YYYY-MM-DD', or ISO 8601; bare dates are whole days in the user's local timezone. Pass EITHER date for a single day OR from + to for a range.

update_hydration_entryA

Correct a hydration entry you previously logged via log_hydration — e.g. "that was a 32 oz bottle, not 16". Required: id (from the prior log_hydration response). Only pass what you want to change. This only works on entries logged via chat; water added in the Iridium app itself returns a 404 and has to be edited there.

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 unit — mass types are converted to the user's preference, while circumference measurements have a null unit because the app records the number without a unit.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RosTeHeA/iridium-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server