Skip to main content
Glama

MoveMate: Gym Workout Tracker

by app.movemate
OverviewDiscussionsAdmin

Search exercises

search_exercises
Read-only

Searches MoveMate's exercise library (including the user's own custom exercises). The model must only compose workouts from exercises returned here — never invented ones. Each result carries an exercise_type saying how that movement is measured (reps, time, distance, or speed and level on a cardio machine) — it decides which target fields create_planned_workout will accept for it, so read it before writing sets.

Input Schema

NameRequiredDescriptionDefault
limitNoHow many exercises to return. Default 20, max 50.
queryNoExercise name or part of it, fuzzy-matched — e.g. "bench press" or "romanian". Omit to browse by muscle_group or equipment.
equipmentNoEquipment name, e.g. "dumbbell", "barbell", "kettlebell" or "bodyweight". Common synonyms are accepted.
muscle_groupNoMuscle group name. Broad lower-body aliases are supported: legs, leg, lower body, and lower-body include quads, hamstrings, glutes, calves, abductors, and adductors. Also accepted: full body, cardio, inner/outer thigh.

Output Schema

NameRequiredDescriptionDefault
localeYes
exercisesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / exercises / items / properties / exercise_type / description
      Previous value: -"How this movement is measured, and therefore which targets a set for it accepts: 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 this movement is measured, and therefore which targets a set for it accepts: 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."
    • changedOutput schema / properties / exercises / items / 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. Changed1 schema field changed
    • changedInput schema / properties / muscle_group / description
      Previous value: -"Muscle group name. Broad lower-body aliases are supported: legs, leg, lower body, and lower-body include quads, hamstrings, glutes, and calves."New value: +"Muscle group name. Broad lower-body aliases are supported: legs, leg, lower body, and lower-body include quads, hamstrings, glutes, calves, abductors, and adductors. Also accepted: full body, cardio, inner/outer thigh."
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds meaningful domain behavior beyond that: results include the user's custom exercises, each result carries an exercise_type describing its measurement mode, and that field determines which target fields create_planned_workout accepts. No return format or rate-limit detail, but the key behavioral semantics are disclosed.

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 what is searched and immediately followed by the most important constraint (no invented exercises). Almost every clause earns its place, though the final sentence about exercise_type and create_planned_workout is dense and could be split for readability.

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 enumerated, and the description supplies exactly the context the schema cannot: that custom exercises are included, that exercise_type governs downstream target fields, and that no exercises may be invented. Nothing an agent needs in order to call 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% -- the limit, query, equipment, and muscle_group parameters are all thoroughly documented in the schema itself, including aliases and fuzzy-match behavior. The description adds nothing about parameters, so the baseline 3 applies; the schema carries this dimension entirely.

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 (searches) and resource (MoveMate's exercise library), and scopes it precisely by noting it includes the user's own custom exercises. This cleanly separates it from siblings like create_custom_exercise or get_exercise_progression, so an agent can pick it 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 a clear operational rule -- only compose workouts from exercises returned here, never invented ones -- and names create_planned_workout as the downstream consumer whose accepted target fields depend on the returned exercise_type. It lacks explicit 'when not to use' guidance or mention of alternatives for browsing, but the intended context is unambiguous.

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