coros-training-mcp

Overview Schema Source Related Servers Discussions Admin

Create Run Workout

create_run_workout

Create structured COROS running workouts with explicit step semantics for warmup, intervals, rest, and cooldown, including time/distance targets, repeat groups, and intensity settings.

Instructions

Create a running workout with explicit run-step semantics.

Use get_run_workout_schema for the exact accepted fields.

Each plain step uses the shared run-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, which is how you author an open warm-up or cool-down)

Optional fields include:

name
overview
intensity_label
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

Repeat groups use:

repeat
steps

Notes:

intensity_label can now use the checked-in live Training Hub labels such as Pace, % Threshold Pace, Heart Rate, or % Max Heart Rate.
The tool sets COROS running sportType = 1.

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_run_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

A3.5/5.0

Behavior3/5

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

No annotations at all, so the description carries the full behavioral burden. It does disclose real behavior: open steps run until the athlete presses the lap button, and the tool forces COROS `sportType = 1`. It omits auth requirements, what side effect lands on the server, whether the workout is created immediately or as a draft, and how failures are surfaced.

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

Conciseness3/5

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

Front-loaded with purpose and the schema-tool pointer, which is good, but the 'Repeat groups use: - repeat - steps' block appears twice verbatim, and a long raw dump of intensity field names is presented without explanation rather than being curated.

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?

For a two-parameter create tool with an output schema (so returns needn't be explained), the description covers the genuinely hard part — nested step authoring semantics and open-step behavior. The remaining gap is creation context: auth prerequisite and how it relates to the update/create siblings.

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?

Schema description coverage is 0% and `steps` is a free-form object array (additionalProperties: true), so the description is the only source of meaning — and it supplies a detailed step contract (kind, target_type, timing/distance fields, open-step omission rule) plus an optional-field list. Deductions for delegating the 'exact accepted fields' to get_run_workout_schema and for unexplained fields like `intensity_percent_extend` and `rest_type`.

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

Purpose4/5

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

Starts with a specific verb+resource: 'Create a running workout with explicit run-step semantics.' The sport qualifier ('run') implicitly separates it from the sibling create_bike_workout/create_strength_workout/create_workout, though it never names those siblings explicitly or contrasts with update_run_workout.

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 does give one useful workflow pointer — 'Use `get_run_workout_schema` for the exact accepted fields' — which tells the agent to consult a sibling before authoring. But there is no explicit when-to-use vs update_run_workout vs create_workout, no mention that COROS authentication is prerequisite (despite authenticate_coros/check_coros_auth siblings), and no exclusions.

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