Skip to main content
Glama
Intervals.icu MCP Server

Intervals.icu MCP Server

by farhoodlabs

update_wellness

Create or update a signed-in athlete's daily wellness record in Intervals.icu, sending only supplied nutrition, hydration, vitals, sleep, and ratings while preserving omitted fields.

Instructions

Create or update the signed-in athlete's wellness record for a single day.

Writes nutrition, hydration, vitals, sleep, and subjective ratings to
Intervals.icu (PUT /athlete/{id}/wellness/{date}). Only the fields you pass are
sent; anything omitted is left untouched. To CLEAR an existing numeric value,
pass ``-1``. Set ``locked=True`` to stop Intervals.icu from overwriting these
values on its next sync from a connected device or app.

Args:
    date: Day to update in YYYY-MM-DD format (optional, defaults to today).
    weight: Body weight in kg.
    resting_hr: Resting heart rate in bpm.
    hrv: Heart rate variability (rMSSD).
    sleep_hours: Sleep duration in hours (stored by Intervals.icu as seconds).
        Pass -1 to clear.
    sleep_quality: Sleep quality rating, as used in the Intervals.icu app.
    calories_consumed: Energy intake in kcal.
    carbohydrates: Carbohydrate intake in grams.
    protein: Protein intake in grams.
    fat: Fat intake in grams.
    hydration_volume: Fluid intake volume, in your Intervals.icu units.
    hydration_score: Subjective hydration score, as used in the app.
    soreness: Subjective soreness rating, as used in the Intervals.icu app.
    fatigue: Subjective fatigue rating, as used in the Intervals.icu app.
    stress: Subjective stress rating, as used in the Intervals.icu app.
    mood: Subjective mood rating, as used in the Intervals.icu app.
    motivation: Subjective motivation rating, as used in the Intervals.icu app.
    injury: Injury level rating, as used in the Intervals.icu app.
    comments: Free-text note for the day.
    locked: If True, lock the record so device/app syncs won't overwrite it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_wellness"
  }
}

Input Schema

NameRequiredDescriptionDefault
fatNo
hrvNo
dateNo
moodNo
injuryNo
lockedNo
stressNo
weightNo
fatigueNo
proteinNo
commentsNo
sorenessNo
motivationNo
resting_hrNo
sleep_hoursNo
carbohydratesNo
sleep_qualityNo
hydration_scoreNo
hydration_volumeNo
calories_consumedNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden and does well: it discloses the PUT endpoint, the partial-update semantics, the -1 clearing sentinel, and the lock/overwrite behavior. It omits permission/auth specifics and failure behavior, keeping it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the operation and key semantics before the long Args list. The Args block is long but each entry earns its place given 20 undocumented parameters; only slight verbosity ('as used in the Intervals.icu app' repeated).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, mutation semantics, all params, and interaction with device sync. With an output schema present, return values needn't be explained. A note on auth/ownership or empty-payload behavior would round it out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the description fully compensates, documenting all 20 params with units, formats (YYYY-MM-DD), defaults (today), representation quirks (sleep stored as seconds), and the -1 clear sentinel. This is meaningfully richer than the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+scope ('Create or update the signed-in athlete's wellness record for a single day') and even names the endpoint. It is unmistakably distinct from get_wellness_data (read) and update_wellness_bulk (multi-day/multi-record).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating context: only passed fields are sent, omitted fields are untouched, -1 clears a value, and locked=True prevents sync overwrites. It never explicitly routes to a sibling (e.g. update_wellness_bulk for multiple days), so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.