Daash

Overview Schema Source Related Servers Discussions Admin

create_workout

Create a new structured Garmin Connect workout with ordered steps and repeat blocks plus pace, heart rate, or power targets, ready to schedule and sync to your watch.

Instructions

Create a structured workout in Garmin Connect: always a new one, never an edit.

schedule_workout then puts it on a date so it syncs to the watch.

Args: name: Shown in Garmin Connect and on the watch. steps: Ordered steps, each with "type" (warmup, interval, recovery, rest, cooldown or repeat) and exactly one of "duration_seconds", "distance_meters" or "until_lap": true (ends on the lap button: a walk recovery between strides, a warm-up by feel, a rep to a landmark; still its own lap, so recoveries stay out of the rep splits). A repeat is {"type": "repeat", "times": 5, "steps": [...]} and can't contain another repeat. Optional target: "pace" ("4:05" or ["4:00", "4:10"], min/km), "hr" ([150, 165] bpm, or their Garmin zone: "z2", "z3-z4") or "power" (watts, 250 or [240, 260]; a share of the FTP set in Garmin, "95%" or ["88%", "94%"]; or a power zone, "z3"). By default only the work reps carry a target, pace for a run; warm-ups, cool-downs and recoveries carry none, so the watch stays quiet, and the chat and the workout's description say what easy pace to run them at: marathon pace plus 45-75 s/km, from get_fitness. The watch beeps off target, so a pace target is never narrower than 5 s/km either side ("4:00" becomes 3:55-4:05; tighter is widened around its middle): about 5 either side for reps, 10 for tempo and threshold, 15-20 for steady and long runs, or heart rate for easy running. A ride uses power on the work steps when the rider has a power meter or smart trainer (power shows on rides in get_activities) and an FTP (get_fitness): sweet spot 88-94%, threshold 95-105%, VO2 max 106-120%, endurance 56-75%. One value becomes a range 5% either side. Without a power meter, heart rate. Example, 15 min warm-up, 5 x 1 km at 4:05 with 90 s recoveries, 10 min cool-down: [{"type": "warmup", "duration_seconds": 900}, {"type": "repeat", "times": 5, "steps": [{"type": "interval", "distance_meters": 1000, "pace": "4:05"}, {"type": "recovery", "duration_seconds": 90}]}, {"type": "cooldown", "duration_seconds": 600}] sport: running (default), cycling, swimming, walking or hiking. description: Optional note stored with the workout. pool_length_meters: For a swim, 25 (default) or 50; the watch counts lengths with it.

A swim's steps are whole pool lengths (100, 200...), each with an optional "stroke": freestyle, backstroke, breaststroke, butterfly, im, drill or any. "pace" is per 100 m ("1:45") and shows on the step as a note, not a beeping target. A "rest" with no duration waits for the lap button, as swimmers rest at the wall; "duration_seconds" fixes it. A "note" (e.g. "kick with board") shows on the step. Set paces from recent swims (get_activities, per 100 m) or their CSS. Example, 8 x 100 free at 1:45 with 15 s rest: [{"type": "warmup", "distance_meters": 400, "stroke": "any"}, {"type": "repeat", "times": 8, "steps": [{"type": "interval", "distance_meters": 100, "stroke": "freestyle", "pace": "1:45"}, {"type": "rest", "duration_seconds": 15}]}, {"type": "cooldown", "distance_meters": 200, "stroke": "any"}]

Input Schema

Name	Required	Default
`name`	Yes
`sport`	No	running
`steps`	Yes
`description`	No
`pool_length_meters`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.1.1Oct 26, 2026
- removedInput schema / properties / description / title
```
Removed value: -"Description"
```
- removedInput schema / properties / name / title
```
Removed value: -"Name"
```
- addedInput schema / properties / pool_length_meters
```
Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
```
- removedInput schema / properties / sport / title
```
Removed value: -"Sport"
```
- removedInput schema / properties / steps / title
```
Removed value: -"Steps"
```
- removedInput schema / title
```
Removed value: -"create_workoutArguments"
```
- removedOutput schema / title
```
Removed value: -"create_workoutDictOutput"
```
First observedv0.1.0Sep 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well beyond annotations by explaining that this always creates a new workout, never edits, and that scheduling is a separate action. It also discloses important behavioral details such as default target assignment, automatic pace-range widening, watch beeping behavior, swim note handling, lap-button semantics, and repeat nesting limits.

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 opening sentence is front-loaded and the Args section is organized around the actual inputs. It is long, with substantial coaching heuristics and examples, but most of that detail is necessary for correctly constructing nested workout steps.

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 complex nested steps schema, zero schema description coverage, and the existence of an output schema, the description is complete enough for an agent to construct valid workouts. It fills the schema gaps with detailed step semantics, examples, and sport-specific behavior.

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 steps parameter is a free-form array, so the description carries the full burden. It thoroughly documents every parameter and the nested step grammar, including types, duration/distance/until_lap, target formats, repeat structure, sport defaults, and pool length.

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: creates a structured workout in Garmin Connect. It also explicitly distinguishes creation from editing with "always a new one, never an edit," making it clearly different from update_workout.

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?

Makes the create-vs-edit boundary clear and explains that schedule_workout is the next step to put the workout on a date. It also references get_fitness and get_activities for target-setting context, though it does not explicitly name update_workout or create_strength_workout as alternatives.

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