MoveMate: Gym Workout Tracker

Update planned workout

update_planned_workout

DestructiveIdempotent

Changes a workout that has not been done yet — reschedule it, rename it, or replace its exercise list. Works on an upcoming session and on one the app marked skipped because its time passed; rescheduling a skipped session makes it upcoming again. A finished workout cannot be changed. Pass only the fields you want to change; anything omitted stays as-is. exercises, if given, replaces the whole list — to add an exercise, pass the existing ones plus the new one; to remove one, pass the list without it. Read the current list with get_workout_details first; never rebuild it from memory. Because the list is replaced wholesale, any superset_group labels left out are removed too. A session's title, notes and exercises belong to the workout it uses: if that workout is one of the user's saved workouts, the change applies to it and to every other session using it, as editing it in the app does; if it is a MoveMate library workout, which cannot be changed, the user's sessions of it switch to their own edited copy. Rescheduling and reminders only ever affect the one session. When the same workout is scheduled more than once, pass session_date to pick the session. A workout can mix strength and conditioning freely: each exercise is measured by its own exercise_type (from search_exercises), so a run, a skipping round or a set of sprints sits in the same list as the lifts — send the targets that type accepts.

Input Schema

Name	Required	Description
`notes`	No	New note for the whole session. Send an empty string to clear it; omit to keep the current one.
`title`	No	New workout name. Omit to keep the current one.
`reminder`	No	Push reminder for this session, as an offset before it starts — "oneHour" is one hour before, "thisDay" fires at the workout time itself, "none" removes an existing reminder. Omit it to leave the current setting alone. A reminder needs the session to have a time of day.
`exercises`	No	Replaces the ENTIRE exercise list — send every exercise the workout should keep, not only the changed ones. Omit to keep the current exercises.
`workout_id`	Yes	From create_planned_workout or list_planned_workouts — never invented.
`session_date`	No	The date (YYYY-MM-DD, the date part of scheduled_for in list_planned_workouts) of the session to change. Only needed when this workout_id is scheduled more than once; without it the next upcoming session is changed. Not the new date — that is scheduled_for.
`scheduled_for`	No	ISO 8601 date or datetime as local wall-clock time in the user's own timezone, with NO offset — '2026-08-29T21:00:00' for 9pm where the user lives. A trailing 'Z' or numeric offset is accepted and converted, but plain local time is preferred.

Output Schema

Name	Required	Description	Default
`title`	Yes
`locale`	Yes
`web_url`	Yes
`warnings`	No
`deep_link`	Yes
`total_sets`	Yes
`workout_id`	Yes
`scheduled_for`	Yes
`exercise_count`	Yes
`display_warnings`	No
`estimated_duration_min`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 10, 2026

changedInput schema / properties / exercises / items / properties / sets / items / properties / target_distance_m / description

Previous value: -"Target distance in METRES — 5 km is 5000. Belongs to exercise_type \"distance_time\" and \"weight_distance\". If the user speaks in miles or kilometres, convert here and keep talking to them in their own unit."New value: +"Target distance in METRES — 5 km is 5000. Belongs to exercise_type \"distance_time\" and \"weight_distance\". If the user speaks in miles or kilometres, convert here and keep talking to them in their own unit. Not for \"cardio_machine\": there the distance is derived from speed and duration."

changed

Input schema / properties / exercises / items / properties / sets / items / properties / target_duration_seconds / description

Previous value: -"Target duration in SECONDS, for work measured by time: a 20-minute run is 1200, a 45-second plank is 45. Belongs to exercise_type \"time\", \"time_weight\" and \"distance_time\". One timed effort is one set — 8 hill sprints of 30s is 8 sets of 30, not a single set of 240."New value: +"Target duration in SECONDS, for work measured by time: a 20-minute run is 1200, a 45-second plank is 45. Belongs to exercise_type \"time\", \"time_weight\", \"distance_time\" and \"cardio_machine\". One timed effort is one set — 8 hill sprints of 30s is 8 sets of 30, not a single set of 240 — and a steady cardio session is ONE set: 20 minutes on the treadmill is a single set of 1200."

addedInput schema / properties / exercises / items / properties / sets / items / properties / target_level

Added value: +{
+  "description": "The machine's own difficulty number, as shown on its display: incline % on a treadmill, resistance on a bike or stepmill. -20 to 100; 0 is a real setting (flat), negative is decline. Belongs to exercise_type \"cardio_machine\" only. Omit it when the user did not name one.",
+  "maximum": 100,
+  "minimum": -20,
+  "type": "number"
+}

addedInput schema / properties / exercises / items / properties / sets / items / properties / target_speed_kmh

Added value: +{
+  "description": "Target machine speed in KM/H, one decimal — e.g. 10.5. Belongs to exercise_type \"cardio_machine\" only (treadmill, stationary bike, stepmill). If the user speaks in mph, convert here (1 mph = 1.609 km/h).",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

Changed2 schema fields changedOct 9, 2026

changedInput schema / properties / exercises / items / properties / superset_group / description

Previous value: -"Label marking exercises performed back-to-back as one superset or circuit — e.g. \"A\" for the first pair, \"B\" for the second. Omit it for a normal exercise done on its own. HARD CONSTRAINT: exercises sharing a label MUST be adjacent in this array, in the order they are performed — membership is defined purely by position in the list, so never interleave two groups and never separate members with an ungrouped exercise. A label used by only ONE exercise is dropped. Labels are replaced by internal ids when saved, so never send back a label read from an earlier response. Since `exercises` replaces the whole list, re-send the labels for any grouping you want to keep."New value: +"Label marking exercises performed back-to-back as one superset or circuit — e.g. \"A\" for the first pair, \"B\" for the second. Omit it for a normal exercise done on its own. HARD CONSTRAINT: exercises sharing a label MUST be adjacent in this array, in the order they are performed — membership is defined purely by position in the list, so never interleave two groups and never separate members with an ungrouped exercise. A label used by only ONE exercise is dropped. The letters get_workout_details returns can be sent back as-is to keep a grouping; never reuse any other label read from an earlier response. Since `exercises` replaces the whole list, re-send the labels for any grouping you want to keep."

addedInput schema / properties / session_date

Added value: +{
+  "description": "The date (YYYY-MM-DD, the date part of scheduled_for in list_planned_workouts) of the session to change. Only needed when this workout_id is scheduled more than once; without it the next upcoming session is changed. Not the new date — that is scheduled_for.",
+  "type": "string"
+}

First observedOct 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description justifies both in concrete terms: exercises replaces the whole list, omitted superset_group labels are silently removed, and shared saved workouts propagate the change to every other session using them. It also discloses the MoveMate library fallback (sessions switch to their own edited copy) and the session-scoped behavior of rescheduling and reminders, none of which is inferable from the annotations.

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 purpose and the primary mutation, then the replacement semantics, then the shared-workout edge case. Dense but each sentence carries a distinct rule; the length is justified by the tool's many mutation modes, though the exercise-list replacement rule is restated twice (description and schema).

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 7-parameter destructive mutation with nested set objects and a rich output schema, the description covers the failure modes an agent would otherwise get wrong: finished workouts, wholesale list replacement, superset label loss, shared-workout propagation, and multi-scheduling disambiguation. Return values need not be described since an output schema exists.

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; the description still adds cross-parameter synthesis not stated in any single field, notably that each exercise is measured by its own exercise_type so strength and conditioning can share one list, and the session_date-versus-scheduled_for distinction. The add/remove workflow for exercises largely restates the schema's own wholesale-replacement note.

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 ('Changes a workout that has not been done yet') and enumerates the three mutations it performs: reschedule, rename, replace exercise list. It also draws the boundary against the sibling update_custom_workout by explaining that editing a saved workout propagates to sessions while rescheduling affects only one session.

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

Usage Guidelines5/5

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

Explicitly states when the tool applies ('has not been done yet'), when it does not ('A finished workout cannot be changed'), the prerequisite read ('Read the current list with get_workout_details first; never rebuild it from memory'), the partial-update contract, and when session_date is needed versus omitted. An agent has everything needed to route to this tool rather than update_custom_workout or create_planned_workout.

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

All MoveMate: Gym Workout Tracker 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?