LiftTrack

create_workout

Create a workout template with exercises, sets, loads, rest modes, and optional supersets. Exercise names must be exact display names from the catalog or the user's custom exercises.

Each exercise: name, target (reps|time), load (weight|percent), working_rest_mode (timed|off|lap), working_rest_seconds (required when working_rest_mode is 'timed'; omit otherwise), optional warmup_sets[], optional warmup_rest_mode (required when warmup_sets is present; same allowed values as working_rest_mode), optional warmup_rest_seconds (required when warmup_rest_mode is 'timed'), working_sets[] (min 1), and an optional superset label. working_rest_mode 'off' means continue straight to the next set/exercise with no rest. 'lap' means the watch pauses until the user presses the lap button. The same rest setting applies between sets within the exercise and after the exercise's last set (the inter-exercise rest). Each set has reps (when target=reps) or seconds (when target=time), and weight (when load=weight) or percent (when load=percent), plus optional rpe. weight is in the user's units (0 = bodyweight). percent is the percentage of training max itself, e.g. 65 for 65%, not a computed weight. The server computes the weight from the user's training max, and the call fails with a clear error if the exercise has no training max set. superset is an optional short label (case-insensitive, max 16 chars). Exercises sharing a label run as one superset on the watch — at least two exercises must share a label, max 16 distinct labels per workout. Optional folder_name is an exact folder name; it places the workout in that folder, or creates the folder if no folder has that name.

Example with a two-exercise superset: {"name":"Push","exercises":[{"name":"Barbell Bench Press","target":"reps","load":"weight","working_rest_mode":"timed","working_rest_seconds":90,"working_sets":[{"reps":5,"weight":185}],"superset":"A"},{"name":"Cable Row","target":"reps","load":"weight","working_rest_mode":"lap","working_sets":[{"reps":8,"weight":80}],"superset":"A"}]}

Input Schema

Name	Required	Description
`name`	Yes
`exercises`	Yes	Exercises in workout order. The workout must fit within 100 steps: each warmup or working set counts as one step, plus one for each timed or lap rest. Off rests add no steps.
`folder_name`	No	Optional exact folder name to place the workout in. The folder is created if no folder has this name.

Output Schema

Name	Required	Description	Default
`name`	Yes
`set_count`	Yes
`workout_id`	Yes
`folder_name`	No
`exercise_count`	Yes
`folder_created`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 3, 2026

addedOutput schema / properties / workout_id
```
Added value: +{
+  "type": "string"
+}
```

changedOutput schema / required

Previous value: -[
-  "name",
-  "exercise_count",
-  "set_count",
-  "folder_created"
-]New value: +[
+  "workout_id",
+  "name",
+  "exercise_count",
+  "set_count",
+  "folder_created"
+]

Changed4 schema fields changedSep 21, 2026
- addedInput schema / properties / exercises / description
```
Added value: +"Exercises in workout order. The workout must fit within 100 steps: each warmup or working set counts as one step, plus one for each timed or lap rest. Off rests add no steps."
```
- removedInput schema / properties / exercises / items / properties / warmup_sets / maxItems
```
Removed value: -10
```
- removedInput schema / properties / exercises / items / properties / working_sets / maxItems
```
Removed value: -10
```
- changedInput schema / properties / exercises / maxItems
```
Previous value: -12New value: +100
```

Changed3 schema fields changedSep 11, 2026

changedInput schema / properties / exercises / items / properties / name / description

Previous value: -"Exact name from search_exercises"New value: +"Exact display name from the exercise catalog or the user's custom exercises"

changedInput schema / properties / exercises / items / properties / warmup_sets / items / properties / percent / description

Previous value: -"Percent of training max, e.g. 70 for 70% — required when the exercise load is percent. Pass the percentage, not a computed weight."New value: +"Percent of training max, e.g. 70 for 70%, not a computed weight — required when the exercise load is percent."

changedInput schema / properties / folder_name / description

Previous value: -"Optional folder to place the workout in. The folder is created if no folder has this name. Call get_folders to see existing folders."New value: +"Optional exact folder name to place the workout in. The folder is created if no folder has this name."

First observedSep 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the write/safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false), so the added behavioral context is a bonus: it discloses the training-max failure mode ('the call fails with a clear error if the exercise has no training max set') and the folder side effect (creates the folder if none matches). It does not mention duplicate-name behavior or overall size limits in prose, but the core failure/side-effect behavior is 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?

Front-loads purpose, then groups set/rest/load/superset rules into discrete paragraphs and closes with a worked superset example. It is long but densely informative; a few sentences restate schema-level detail (weight units, rest modes), which is the only real slack.

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 complex nested-payload create tool with an output schema present, the description covers required field relationships, conditional requirements, rest semantics, superset constraints, folder behavior, and failure modes, plus a full example. Only minor edge cases (duplicate workout names, whether creation is idempotent) are left unaddressed.

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 67% schema coverage, the description meaningfully supplements the schema: it clarifies that percent is 'the percentage of training max itself... not a computed weight', that weight=0 means bodyweight, the 'off' vs 'lap' rest semantics, and superset rules the schema omits (at least two exercises must share a label, max 16 distinct labels). Some of this overlaps schema descriptions, keeping it short of a 5.

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?

Opens with a precise verb and resource ('Create a workout template') and enumerates the payload it accepts (exercises, sets, loads, rest modes, supersets). It is clearly distinguishable from update_workout/delete_workout, though it never explicitly names which sibling it differs from or routes to.

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?

There is implied guidance ('Exercise names must be exact display names from the catalog or the user's custom exercises'), which hints that a lookup/validation step should precede the call, but no sibling such as search_exercises or validate_exercise_names is named. No when-to-use vs. when-to-update framing is given.

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

All LiftTrack tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?