Skip to main content
Glama

MoveMate: Gym Workout Tracker

Create custom exercise

create_custom_exercise

Adds a new exercise to the user's own library, for when search_exercises doesn't have what they're after — including conditioning work such as a run, skipping or sprints, via exercise_type. The returned exercise_id can then be used with search_exercises results in create_planned_workout — never invent an exercise_id. Not safe to retry: calling this again with the same name creates a separate duplicate exercise, not the same one — check search_exercises first if unsure whether it already exists.

Input Schema

NameRequiredDescriptionDefault
nameYesExercise name as the user will see it in the app, e.g. "Incline hammer curl". Max 80 characters.
notesNoOptional setup or coaching cues shown with the exercise. Max 500 characters.
equipmentNoFree text, e.g. "dumbbell" — best-effort matched against the library; omitted if no match.
muscle_groupNoFree text, e.g. "chest" or "hamstrings" — best-effort matched against the library; omitted if no match.
exercise_typeNoHow the movement is measured. This decides which targets create_planned_workout will accept for it and which inputs the app shows while training, and there is no tool to change it afterwards — pick it deliberately. Defaults to "default". default = weight and reps (most strength work, and bodyweight work with reps such as pull-ups or hill sprints); time = duration only (planks, dead hangs, skipping); time_weight = duration and weight (weighted plank, farmer hold); distance_time = distance and duration (outdoor running, cycling or swimming, rowing machine, SkiErg — anything whose monitor shows distance rather than km/h); weight_distance = weight and distance (farmer walk, sled push); cardio_machine = speed in km/h, the machine level (incline or resistance) and duration — treadmill, stationary bike, stepmill; distance is derived from speed and time. Continuous cardio (cardio_machine, distance_time) is ONE set per session — a 20-minute treadmill walk is a single set of 1200 seconds, not three.

Output Schema

NameRequiredDescriptionDefault
nameYes
exercise_idYes
exercise_typeYes
equipment_matchedYes
muscle_group_matchedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / exercise_type / description
      Previous value: -"How the movement is measured. This decides which targets create_planned_workout will accept for it and which inputs the app shows while training, and there is no tool to change it afterwards — pick it deliberately. Defaults to \"default\". default = weight and reps (most strength work, and bodyweight work with reps such as pull-ups or hill sprints); time = duration only (planks, dead hangs, skipping); time_weight = duration and weight (weighted plank, farmer hold); distance_time = distance and duration (running, rowing machine, treadmill, cycling); weight_distance = weight and distance (farmer walk, sled push)."New value: +"How the movement is measured. This decides which targets create_planned_workout will accept for it and which inputs the app shows while training, and there is no tool to change it afterwards — pick it deliberately. Defaults to \"default\". default = weight and reps (most strength work, and bodyweight work with reps such as pull-ups or hill sprints); time = duration only (planks, dead hangs, skipping); time_weight = duration and weight (weighted plank, farmer hold); distance_time = distance and duration (outdoor running, cycling or swimming, rowing machine, SkiErg — anything whose monitor shows distance rather than km/h); weight_distance = weight and distance (farmer walk, sled push); cardio_machine = speed in km/h, the machine level (incline or resistance) and duration — treadmill, stationary bike, stepmill; distance is derived from speed and time. Continuous cardio (cardio_machine, distance_time) is ONE set per session — a 20-minute treadmill walk is a single set of 1200 seconds, not three."
    • changedInput schema / properties / exercise_type / enum
      Previous value: -[
      -  "default",
      -  "time",
      -  "time_weight",
      -  "distance_time",
      -  "weight_distance"
      -]New value: +[
      +  "default",
      +  "time",
      +  "time_weight",
      +  "distance_time",
      +  "weight_distance",
      +  "cardio_machine"
      +]
    • changedOutput schema / properties / exercise_type / enum
      Previous value: -[
      -  "default",
      -  "time",
      -  "time_weight",
      -  "distance_time",
      -  "weight_distance"
      -]New value: +[
      +  "default",
      +  "time",
      +  "time_weight",
      +  "distance_time",
      +  "weight_distance",
      +  "cardio_machine"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare idempotentHint=false, and the description goes beyond the boolean by spelling out the concrete consequence: retrying with the same name creates a separate duplicate rather than the same exercise. It also warns 'never invent an exercise_id', a real behavioral constraint not expressible in 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?

Three sentences, front-loaded with the purpose before the retry caveat and downstream usage. Efficient overall, though the middle sentence packs the exercise_id guidance into a dense clause that slightly crowds the routing message.

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?

An output schema exists, so return values need not be explained, and the description still covers the creation scope, the retry/duplication hazard, and how the returned id feeds create_planned_workout. Nothing an agent needs to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so name, notes, equipment, muscle_group and exercise_type are already fully documented by the schema, including the enum semantics. The description only alludes to exercise_type for conditioning work, adding marginal value over the structured field; baseline 3 applies.

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 ('Adds a new exercise to the user's own library') and explicitly positions it against the sibling search_exercises, which reads rather than creates. An agent can distinguish it from create_custom_workout and search_exercises 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?

Explicitly names the trigger condition ('when search_exercises doesn't have what they're after') and the alternative ('check search_exercises first if unsure whether it already exists'). It also routes the output downstream to create_planned_workout, so both the entry and exit paths are documented.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources