LiftTrack

update_workout

DestructiveIdempotent

Change an existing workout template. workout_name is the exact current name; optional workout_folder_name disambiguates duplicate names and does not change folder membership. Omitted fields keep their current values.

name renames the workout. exercises replaces the entire exercise list, including all exercises and sets to retain. Progression links are preserved for exercises that keep their name. Each exercise uses an exact catalog or custom exercise display name, target (reps|time), load (weight|percent), working sets, and rest configuration, with optional warmup sets, supersets, RPE, and notes. The input schema defines the fields and constraints. Notes appear on the watch in the workout step description.

A rename-only request contains workout_name and name, plus workout_folder_name if needed; it does not require exercises.

Input Schema

Name	Required	Description
`name`	No	New name for the workout (a rename)
`exercises`	No	Full replacement exercise list, including all exercises and sets to retain. Exercises absent from this array are removed. Omission of this field preserves the existing exercise list. 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.
`workout_name`	Yes	Exact current name of the workout to update
`workout_folder_name`	No	Folder of the target workout, only needed when several workouts share the name. Identity only: this tool never moves a workout between folders.

Output Schema

Name	Required	Description
`name`	Yes	Final workout name after the update
`updated`	Yes	Which slices were written
`set_count`	Yes
`previous_name`	No	Present only when the name actually changed
`exercise_count`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 21, 2026

changedInput schema / properties / exercises / description

Previous value: -"Full replacement exercise list, including all exercises and sets to retain. Exercises absent from this array are removed. Omission of this field preserves the existing exercise list."New value: +"Full replacement exercise list, including all exercises and sets to retain. Exercises absent from this array are removed. Omission of this field preserves the existing exercise list. 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 / description

Previous value: -"Full replacement exercise list. Read the workout with get_workout_detail first, edit the returned object, and pass the COMPLETE array back, including exercises you are not changing."New value: +"Full replacement exercise list, including all exercises and sets to retain. Exercises absent from this array are removed. Omission of this field preserves the existing exercise list."

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."

First observedSep 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations declare destructive/idempotent, but the description adds the concrete destructive semantics: 'exercises replaces the entire exercise list' and exercises absent are removed, while omission preserves the list. It also discloses non-obvious side effects — progression links preserved only for exercises keeping their name, folder membership never changes, and notes surface on the watch step description.

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 mutation model and the rename-only shortcut, and every paragraph carries operational content. It is somewhat dense and could compress the exercise-field enumeration, which the schema already documents.

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 destructive, 4-parameter mutation tool with nested exercise payloads, the description covers replacement semantics, rename-only path, disambiguation, preserved progression links, and side effects, while deferring field constraints to the schema and return values to the output schema.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: workout_name must be the exact current name, workout_folder_name is identity-only disambiguation that never moves folders, and exercises is a full-replacement operation rather than a merge.

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 opening sentence states a specific verb and resource ('Change an existing workout template') and immediately scopes what can be changed (rename via name, full replacement via exercises). An agent can distinguish this from create_workout and delete_workout without opening the schema.

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?

It gives clear conditional guidance: omitted fields keep current values, workout_folder_name is only needed for duplicate names, and a rename-only request contains workout_name plus name and omits exercises. It does not name a sibling tool as an alternative, so it stops short of a 5.

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?