coros-training-mcp

Overview Schema Source Related Servers Discussions Admin

Create Bike Workout

create_bike_workout

Creates structured COROS cycling workouts with explicit bike-step semantics, including warmup, intervals, rest, and cooldown, plus time or distance targets and power, heart rate, or cadence intensity.

Instructions

Create a cycling workout with explicit bike-step semantics.

Use get_bike_workout_schema for the exact accepted fields.

Each plain step uses the shared bike-step contract:

kind: warmup, training, rest, cooldown, interval
target_type: time, distance, or open
target_duration_seconds or target_distance_meters (omit both for open steps — an open step has no target and runs until the athlete presses the lap button)

Optional fields include:

name
overview
intensity_label (values come from the checked-in live Training Hub bike correlations — common labels: Power, %FTP, Heart Rate, % Max Heart Rate, % Lactate Threshold HR, Cadence, Speed)
power: human string like '220W' or '220-260W', expands to intensity_type=6 with watts in intensity_value / intensity_value_extend
raw intensity fields like intensity_type, hr_type, is_intensity_percent, intensity_percent, intensity_percent_extend, intensity_value, intensity_value_extend, intensity_display_unit
rest_type
rest_value
sets

Repeat groups use:

repeat
steps

Notes:

The tool sets COROS cycling sportType = 2.
If bike intensity_label presets aren't available yet (catalog not captured), pass the raw intensity fields directly or use power.

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": {
      "name": "<name>",
      "steps": "<steps>"
    },
    "name": "create_bike_workout"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`steps`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Oct 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral burden well. It discloses the shared bike-step contract, open-step lap-button behavior, power-string expansion to intensity_type=6, repeat-group structure, and that the tool sets COROS cycling sportType=2. It does not discuss auth, validation failures, or mutation side effects, but the core behavioral traits are covered.

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?

The description is long, but the complexity of the freeform nested steps object justifies much of the detail. It is front-loaded with purpose and a pointer to get_bike_workout_schema, then organized into bulleted contracts and notes, though the optional-field list is verbose enough to lose some crispness.

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?

An output schema exists, so return values need not be explained. Given the poor input schema coverage and complex bike-step domain, the description supplies enough nested-field semantics, defaults, fallback behavior, and structural guidance for an agent to call the tool correctly.

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 description coverage is 0%, and the input schema only exposes name and a freeform steps array. The description compensates extensively by defining step kind values, target_type semantics, target_duration_seconds versus target_distance_meters behavior for open steps, optional fields, power-string format, raw intensity fields, and repeat-group keys.

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 description opens with a specific verb and resource: 'Create a cycling workout with explicit bike-step semantics.' The bike/cycling framing distinguishes it from run, strength, and generic workout creation siblings, and the mention of sportType=2 reinforces the COROS cycling scope.

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

Usage Guidelines3/5

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

It usefully points to get_bike_workout_schema for exact accepted fields and explains fallback behavior when bike intensity presets are unavailable. However, it does not explicitly state when to use create_bike_workout versus create_workout or update_bike_workout, so the when-to-use guidance remains implied rather than explicit.

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