Skip to main content
Glama

MoveMate: Gym Workout Tracker

by app.movemate
OverviewDiscussionsAdmin

Create planned workout

create_planned_workout

Schedules a workout in the app on a chosen date, in one of two ways. To schedule a workout that already exists — one of the user's saved workouts or a library workout, found with list_workouts — pass its workout_id and no title, notes or exercises: the session links to that workout exactly as scheduling it in the app does, so no copy appears in the user's saved workouts, and later edits to that saved workout show up in this session too. To build a new session, omit workout_id and pass title and exercises. Every exercise_id must come from search_exercises or create_custom_exercise — never invented. Not safe to blindly retry: client_request_id makes retries safe — a repeat call with the same ID returns the existing workout instead of creating a duplicate. Supersets and circuits are set with the superset_group label on each exercise — see that field for the rule it requires. 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. Free accounts can hold a limited number of upcoming planned workouts; a refusal for that reason says so and must not be retried.

Input Schema

NameRequiredDescriptionDefault
notesNoOptional note for the whole session, shown in the app. Max 500 characters. Not used with workout_id.
titleNoWorkout name shown in the app calendar, e.g. "Push day". Max 60 characters. Required when building a new workout; not used with workout_id.
reminderNoPush reminder for this session, as an offset before it starts — "oneHour" is one hour before, "thisDay" fires at the workout time itself. Send it ONLY when the user asks to be reminded: leaving it out means no reminder, which is what the app itself does by default. Needs a time in scheduled_for; a date-only session cannot carry a reminder.
exercisesNoThe exercises in the order they are performed — at least one. Required when building a new workout; not used with workout_id.
workout_idNoSchedule this existing workout instead of building one — from list_workouts or create_custom_workout, never invented. When given, leave out title, notes and exercises.
scheduled_forYesISO 8601 date or datetime as local wall-clock time in the user's own timezone, with NO offset — '2026-08-29' or '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: it is what the user means and cannot drift a day.
client_request_idNoIdempotency key. Generate a NEW unique value (e.g. a UUID) for each new workout, and reuse the SAME value when retrying a call that may already have succeeded — a repeat with the same value returns the existing workout instead of creating a duplicate.

Output Schema

NameRequiredDescriptionDefault
titleYes
localeYes
web_urlYes
warningsNo
deep_linkYes
total_setsYes
workout_idYes
scheduled_forYes
exercise_countYes
display_warningsNo
estimated_duration_minYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • 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."
    • changedInput 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"
+}
  2. Changed5 schema fields changed
    • changedInput schema / properties / exercises / description
      Previous value: -"The exercises in the order they are performed — at least one."New value: +"The exercises in the order they are performed — at least one. Required when building a new workout; not used with workout_id."
    • changedInput schema / properties / notes / description
      Previous value: -"Optional note for the whole session, shown in the app. Max 500 characters."New value: +"Optional note for the whole session, shown in the app. Max 500 characters. Not used with workout_id."
    • changedInput schema / properties / title / description
      Previous value: -"Workout name shown in the app calendar, e.g. \"Push day\". Max 60 characters."New value: +"Workout name shown in the app calendar, e.g. \"Push day\". Max 60 characters. Required when building a new workout; not used with workout_id."
    • addedInput schema / properties / workout_id
      Added value: +{
+  "description": "Schedule this existing workout instead of building one — from list_workouts or create_custom_workout, never invented. When given, leave out title, notes and exercises.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "title",
-  "scheduled_for",
-  "exercises"
-]New value: +[
+  "scheduled_for"
+]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that a workout_id session is a live link whose later edits propagate and creates no copy, that retries are unsafe without client_request_id (which returns the existing workout), that free accounts cap upcoming planned workouts with a non-retryable refusal, and that exercise_type drives mixed strength/conditioning sessions. This is exactly the extra behavioral context the structured fields do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the two-mode split are front-loaded, and each subsequent sentence carries a distinct actionable rule (id sourcing, retry/idempotency, superset labels, mixed exercise types, account limit). No filler or restatement of the title.

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 mutation tool with nested exercise/set arrays, the description covers both invocation modes, the idempotency contract, and the account-level refusal case; return values need not be explained because an output schema exists and annotations cover the safety profile.

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 per-parameter detail is already documented; the description still adds value by stating the cross-field contract (workout_id excludes title/notes/exercises; title and exercises are required for the build path) and the sourcing rule for exercise_id. It stops short of adding new syntax or semantics beyond the schema.

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?

Opens with a specific verb + resource + scope: 'Schedules a workout in the app on a chosen date, in one of two ways.' It then names both modes (link an existing workout by id vs. build a new one), which lets an agent distinguish this from update_planned_workout or log_completed_workouts without opening a 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?

Gives explicit conditional routing: pass workout_id (and no title/notes/exercises) to link an existing workout found with list_workouts, or omit workout_id and pass title/exercises to build one. It also names the required upstream tools (search_exercises, create_custom_exercise) and states exclusions, but never addresses when to prefer this over the sibling update_planned_workout or log_completed_workouts.

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 toolsInspect
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