MoveMate: Gym Workout Tracker

Update saved workout

update_custom_workout

DestructiveIdempotent

Changes one of the user's own saved workouts ("My workouts" in the app) — rename it, change its note, or replace its exercise list — the same as editing it in the app. Every scheduled session that uses this workout shows the change too, including upcoming ones; the response says how many. Library workouts cannot be changed: to make a personal version, save one with create_custom_workout. 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 in the right position; to remove one, pass the list without it. ALWAYS read the current list with get_workout_details first and send it back with your change — never rebuild it from memory, or the exercises, sets and weights you leave out are lost. Confirm the change with the user before calling. Each exercise is measured by its own exercise_type — send the targets that type accepts.

Input Schema

Name	Required	Description
`notes`	No	New note for the whole workout. Send an empty string to clear it; omit to keep the current one.
`title`	No	New workout name. Omit to keep the current one.
`exercises`	No	Replaces the ENTIRE exercise list — send every exercise the workout should keep (as read with get_workout_details), not only the changed ones. Omit to keep the current exercises.
`workout_id`	Yes	The saved workout — from list_workouts (type custom), create_custom_workout or get_workout_details. Never invented.

Output Schema

Name	Required	Description
`total`	Yes	Total workouts matching the filter, which can exceed the returned list — narrow with query or type if it does.
`locale`	Yes
`warnings`	No
`workouts`	Yes
`total_sets`	Yes
`workout_id`	Yes	The saved workout — pass it to create_planned_workout to schedule it.
`display_warnings`	No
`upcoming_sessions`	Yes	How many upcoming scheduled sessions use this workout — they show any change made to it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 12, 2026

addedOutput schema / properties / workouts / items / properties / content_summary

Added value: +{
+  "description": "Compact catalog tags used to compare muscle emphasis, goal, and duration when selecting a program.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / workouts / items / required

Previous value: -[
-  "workout_id",
-  "title",
-  "type",
-  "duration_min",
-  "fitness_level",
-  "exercises",
-  "exercise_count",
-  "is_premium",
-  "image_url",
-  "deep_link",
-  "web_url"
-]New value: +[
+  "workout_id",
+  "title",
+  "type",
+  "duration_min",
+  "fitness_level",
+  "content_summary",
+  "exercises",
+  "exercise_count",
+  "is_premium",
+  "image_url",
+  "deep_link",
+  "web_url"
+]

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"
+}

AddedOct 9, 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 earns its keep beyond that by disclosing propagation to every scheduled session (including upcoming) and that the response reports how many, that omitted fields are preserved, and that a careless exercises payload silently destroys sets/weights left out. That is exactly the destructive-behavior context an agent needs.

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?

Purpose and the central replacement-warning are front-loaded, and the longer run of sentences about exercises/get_workout_details is the highest-risk part of the operation so it justifies its length. Slightly verbose, with a few clauses that restate schema text.

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 mutation with an output schema already covering the return, the description supplies everything else an agent needs: scope of the change, propagation side effects, replacement semantics, prerequisite read, and confirmation step. No material gap remains.

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 semantics beyond it: exercises is a full replacement (add/remove must be done by re-sending the complete list) and each exercise is measured by its own exercise_type. It also repeats some schema content (omitted fields stay as-is), which keeps it from a 5.

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 precise verb and resource (change a saved 'My workouts' entry), enumerates the three mutable aspects (rename, note, exercise list), and draws an explicit boundary against library workouts with a named alternative (create_custom_workout). An agent can distinguish this from create_custom_workout and update_planned_workout without opening any schema.

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?

Gives explicit routing rules: library workouts cannot be changed, use create_custom_workout instead; always read the current list with get_workout_details before calling; confirm with the user first. These are when-to-use, when-not-to-use and prerequisite conditions, not merely implied context.

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?