Skip to main content
Glama
futureweb

Futureweb Intervals MCP

by futureweb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

add_or_update_event

Destructive

Create or update planned workouts, races, and events on the Intervals.icu calendar; validate structured workouts and update fields via event_id before writing.

Instructions

Use only when the athlete asks to put a planned workout, race or other event on the calendar or to change one. Writes to Intervals.icu.

Without event_id a new event is created (name required, date default today, category WORKOUT; a duplicate of that day is refused: allow_duplicate); with event_id only the passed fields change, a new date keeps the time of day. workout_doc REPLACES the planned workout and is validated like validate_workout: with errors nothing is written. Text-only sessions (strength, yoga) go into description; text never silently replaces a structured workout (replace_workout). dry_run shows the exact request; the answer reads back what Intervals.icu stored and parsed. Read intervals://workout-syntax (get_guide) before writing steps.

Input Schema

NameRequiredDescriptionDefault
nameNoEvent name; required when creating
indoorNoIndoor/trainer session; omit to leave unchanged
dry_runNotrue = check and return the exact request, write nothing
categoryNoEvent category; WORKOUT when creating, unchanged when updating
distanceNoPlanned distance in metres (>= 0)
event_idNoEvent to update; omit to create a new event
athlete_idNoDefault: the configured athlete
start_dateNoDay YYYY-MM-DD; default today when creating, unchanged when updating
descriptionNoText instead of workout_doc: an exercise list or native Intervals.icu workout text, sent as-is; replaces the text
moving_timeNoPlanned moving time in seconds (>= 0)
workout_docNoStructured workout (steps); REPLACES the planned workout. Format: intervals://workout-syntax
workout_typeNoSport, e.g. Ride, Run, Swim, Walk, Row, WeightTraining; needed for a new workout or race unless the name names exactly one sport
allow_duplicateNoCreate even if that day has the same event (name or workout)
replace_workoutNoAllow text or a workout without timed steps to replace a structured workout

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only give readOnlyHint=false and destructiveHint=true; the description supplies the operational detail that matters — duplicates are refused unless allow_duplicate, workout_doc fully REPLACES the planned workout, validation failure means nothing is written, text never silently overwrites a structured workout without replace_workout, dates retain time of day, and dry_run returns the exact request. That is substantial disclosure beyond the annotation set.

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 usage condition, then create/update semantics, then replacement and validation rules, then dry_run — each sentence carries non-redundant information. It is dense enough that the reader must parse carefully, but nothing is filler.

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?

For a 14-parameter mutation tool with no output schema, the description covers creation, update, replacement, validation atomicity, duplicate handling, dry-run preview, and what the response reads back, plus a pointer to intervals://workout-syntax. Nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

With 100% schema coverage the baseline is 3, and the description earns above that by explaining conditional cross-parameter behavior the per-field schema cannot: omitting event_id creates, name is required on create, date defaults to today, category defaults to WORKOUT, and allow_duplicate/replace_workout guard specific failure modes. Some overlap with schema text (name/category defaults) keeps it from a 5.

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 and resource ('put a planned workout, race or other event on the calendar or change one') and names the write target (Intervals.icu). The create-vs-update split on event_id makes it distinguishable from read siblings like get_events and get_event_by_id.

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?

Opens with an explicit gate ('Use only when the athlete asks to...'), which is a real usage constraint, and routes to validate_workout and get_guide for the syntax reference. It never names the closest write alternatives (add_event_from_library, create_library_workout), so the when-not-this branch is left to inference.

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

Deploy Server

Other Tools