Skip to main content
Glama
Intervals.icu MCP Server

Intervals.icu MCP Server

by farhoodlabs

add_or_update_event

Create or update an athlete's Intervals.icu event with workout details and structured steps; provide an event ID to modify an existing event instead of creating a new one.

Instructions

Post event for an athlete to Intervals.icu this follows the event api from intervals.icu If event_id is provided, the event will be updated instead of created.

Many arguments are required as this MCP tool function maps directly to the Intervals.icu API parameters.

Args:
    event_id: The Intervals.icu event ID (optional, will use event_id from .env if not provided)
    start_date: Start date in YYYY-MM-DD format (optional, defaults to today)
    name: Name of the activity
    workout_doc: steps as a list of Step objects (optional, but necessary to define workout steps)
    workout_type: Workout type (e.g. Ride, Run, Swim, Walk, Row)
    moving_time: Total expected moving time of the workout in seconds (optional)
    distance: Total expected distance of the workout in meters (optional)

Example:
    "workout_doc": {
        "description": "High-intensity workout for increasing VO2 max",
        "steps": [
            {"power": {"value": 80, "units": "%ftp"}, "duration": 900, "warmup": true},
            {"reps": 2, "text": "High-intensity intervals", "steps": [
                {"power": {"value": 110, "units": "%ftp"}, "distance": 500, "text": "High-intensity"},
                {"power": {"value": 80, "units": "%ftp"}, "duration": 90, "text": "Recovery"}
            ]},
            {"power": {"value": 80, "units": "%ftp"}, "duration": 600, "cooldown": true},
            {"text": ""}
        ]
    }

Step properties:
    distance: Distance of step in meters
        {"distance": 5000}
    duration: Duration of step in seconds
        {"duration": 1800}
    power/hr/pace/cadence: Define step intensity
        Percentage of FTP: {"power": {"value": 80, "units": "%ftp"}}
        Absolute power: {"power": {"value": 200, "units": "w"}}
        Heart rate: {"hr": {"value": 75, "units": "%hr"}}
        Heart rate (LTHR): {"hr": {"value": 85, "units": "%lthr"}}
        Cadence: {"cadence": {"value": 90, "units": "cadence"}}
        Pace by ftp: {"pace": {"value": 80, "units": "%pace"}}
        Pace by zone: {"pace": {"value": 2, "units": "pace_zone"}}
        Zone by power: {"power": {"value": 2, "units": "power_zone"}}
        Zone by heart rate: {"hr": {"value": 2, "units": "hr_zone"}}
    Ranges: Specify ranges for power, heart rate, or cadence:
        {"power": {"start": 80, "end": 90, "units": "%ftp"}}
    Ramps: Instead of a range, indicate a gradual change in intensity (useful for ERG workouts):
        {"ramp": true, "power": {"start": 80, "end": 90, "units": "%ftp"}}
    Repeats: include the reps property and add nested steps
        {"reps": 3,
         "steps": [
            {"power": {"value": 110, "units": "%ftp"}, "distance": 500, "text": "High-intensity"},
            {"power": {"value": 80, "units": "%ftp"}, "duration": 90, "text": "Recovery"}
        ]}
    Free Ride: Include freeride to indicate a segment without ERG control, optionally with a suggested power range:
        {"freeride": true, "power": {"value": 80, "units": "%ftp"}}
    Comments and Labels: Add descriptive text to label steps:
        {"text": "Warmup"}

How to use steps:
- Set distance or duration as appropriate for step
- Use "reps" with nested steps to define repeat intervals (as in example above)
- Define one of "power", "hr" or "pace" to define step intensity

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workout_type": "<workout_type>",
      "name": "<name>"
    },
    "name": "add_or_update_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYes
distanceNo
event_idNo
start_dateNo
moving_timeNo
workout_docNo
workout_typeYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.5/5.0
Behavior4/5

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

Since no annotations exist, the description carries the full burden, providing rich detail on input formats (e.g., moving time in seconds) and default behavior (using .env if `event_id` is missing). It is highly informative about data requirements, making it very transparent.

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

Conciseness2/5

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

The description is excessively long, containing verbose explanations, a massive example, and a detailed glossary. Its sheer length and lack of a streamlined structure make it difficult to digest quickly, even though the information is useful.

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

Completeness5/5

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

Given the complexity of mapping to the external Intervals.icu API and defining nested data structures, the definition is nearly exhaustive. It covers the primary use cases (create/update), detailed data types (power, HR, pace), and complex scenarios (ramps, repeats, freerides).

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?

With 0% schema description coverage, the description is necessary and excels at defining the complex semantics of every parameter. It provides a full breakdown of the `workout_doc` structure, giving meaning to all parameters beyond what the schema itself provides.

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?

The purpose is clearly defined as posting/updating an event for an athlete to Intervals.icu, and it is distinct from other event/activity management siblings by focusing on the event API interaction.

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

Usage Guidelines5/5

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

It explicitly states a critical usage rule: if `event_id` is provided, the event is updated; otherwise, it is created. This clear conditional logic is highly actionable.

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