MoveMate: Gym Workout Tracker

by app.movemate

Overview Discussions Admin

Server Details

Schedule workouts from the MoveMate exercise library and review history, PRs and progression.

Ownership verified

Status: Healthy
Uptime: 25.4% over 21 days
OAuth: Works in Glama
Last Tested: 2026-10-07 21:50
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored 2026-10-03 11:55 across 14 tools

Disambiguation4/5

Most tools target clearly distinct resources and actions, with explicit usage rules in descriptions. Minor overlap remains between get_workout and list_workouts when retrieving by workout_id, and get_profile vs get_body_profile could require careful reading, but descriptions largely resolve these.

Naming Consistency5/5

All tools use consistent snake_case and follow a predictable verb_noun pattern such as create_planned_workout, get_recent_workouts, and list_planned_workouts. The prefixes create/get/list/search/update/delete are used coherently throughout.

Tool Count5/5

The 14 tools sit comfortably in the ideal range and each addresses a distinct capability: exercise search/creation, workout browsing/retrieval, planned workout CRUD, history, stats, PRs, and profile data. No tool feels redundant or missing from a count perspective.

Completeness4/5

The set covers core lifecycle needs for a workout tracker: exercise discovery, planned workout creation/update/deletion, workout browsing, recent history, progression, personal records, training stats, and profile data. Minor gaps exist around editing/deleting custom exercises or explicitly logging a completed workout, though the app may handle those outside chat.

Available Tools

14 tools

create_custom_exerciseCreate custom exerciseAInspect

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.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Exercise name as the user will see it in the app, e.g. "Incline hammer curl". Max 80 characters.
`notes`	No	Optional setup or coaching cues shown with the exercise. Max 500 characters.
`equipment`	No	Free text, e.g. "dumbbell" — best-effort matched against the library; omitted if no match.
`muscle_group`	No	Free text, e.g. "chest" or "hamstrings" — best-effort matched against the library; omitted if no match.
`exercise_type`	No	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).

Output Schema

ParametersJSON Schema

Name	Required	Description
`name`	Yes
`exercise_id`	Yes
`exercise_type`	Yes
`equipment_matched`	Yes
`muscle_group_matched`	Yes

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare idempotentHint=false and destructiveHint=false, but the description goes further with the concrete consequence: re-calling with the same name creates a separate duplicate rather than the same exercise, and it warns never to invent an exercise_id. It also discloses that exercise_type cannot be changed afterwards because no tool exists for it.

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?

Three sentences, each earning its place: creation scope, how to use the returned id, and the non-idempotency warning. The most consequential caveats (duplicate creation) are stated directly rather than buried.

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 no prose, yet the description still ties the returned exercise_id to the next tool in the workflow. For a 5-param mutation with an irreversible enum, all decision-relevant context is present.

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 baseline is 3, but the description adds meaning the schema does not: exercise_type determines which targets create_planned_workout will accept and is immutable post-creation. That cross-tool consequence is genuine added value beyond the schema's own enum documentation.

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 immediately distinguishes it from the sibling search_exercises, including the conditioning-use case via exercise_type. An agent can tell exactly what this creates without opening the 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 ('for when search_exercises doesn't have what they're after'), the alternative to check first ('check search_exercises first if unsure whether it already exists'), and the downstream consumer ('create_planned_workout'). No condition is left to inference.

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

create_planned_workoutCreate planned workoutAInspect

Schedules a planned workout in the app on a chosen date. 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.

ParametersJSON Schema

Name	Required	Description
`notes`	No	Optional note for the whole session, shown in the app. Max 500 characters.
`title`	Yes	Workout name shown in the app calendar, e.g. "Push day". Max 60 characters.
`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. 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.
`exercises`	Yes	The exercises in the order they are performed — at least one.
`scheduled_for`	Yes	ISO 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_id`	No	Idempotency 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

ParametersJSON Schema

Name	Required	Description
`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

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare readOnly=false, idempotent=false, destructive=false; the description goes well beyond that with the idempotency key mechanics, the superset adjacency constraint and pointer to the field rule, and the fact that strength and conditioning exercises can be mixed and are measured by their own exercise_type. This is behaviorally rich, non-duplicative context for a mutation tool.

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 the purpose, then a sequence of one-rule-per-sentence statements that all earn their place (idempotency, superset rule, type mixing). It is dense rather than padded, though a few points repeat schema text verbatim and could have been trimmed.

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?

With an output schema present, the description correctly avoids explaining return values and instead covers the things structured data cannot: idempotent retry behavior, superset grouping constraints, mixed-modality workouts, and unit/type expectations. Nothing an agent needs to invoke this correctly appears to be missing.

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 nonetheless adds cross-field semantics the schema states only per-field — e.g. that each exercise carries its own exercise_type and that only the targets that type accepts should be sent, and that superset membership is governed by the superset_group rule. Some of its parameter content (exercise_id provenance, superset labels) duplicates what the schema already says, keeping it below a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: "Schedules a planned workout in the app on a chosen date." It also names the required upstream tools (search_exercises, create_custom_exercise) for exercise_id, which helps an agent locate the tool in a workflow. It does not explicitly distinguish itself from update_planned_workout or list_planned_workouts, so it stops short of full sibling differentiation.

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 concrete preconditions and alternatives: exercise_id must come from search_exercises or create_custom_exercise and never be invented, and it explains the retry policy (reuse the same client_request_id rather than blindly retrying). It does not state when to prefer update_planned_workout over creating a new session, which is the one obvious sibling decision left unaddressed.

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

delete_planned_workoutDelete planned workoutA

DestructiveIdempotent

Inspect

Cancels a planned (not yet done) workout and takes it off the schedule. Only affects upcoming planned workouts — a workout already marked done or skipped cannot be removed from chat.

ParametersJSON Schema

Name	Required	Description	Default
`workout_id`	Yes	From create_planned_workout or list_planned_workouts — never invented.

Output Schema

ParametersJSON Schema

Name	Required	Description
`deleted`	Yes
`workout_id`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real context beyond annotations: only upcoming planned workouts are affected, and done/skipped entries are unreachable. It does not say what happens to the schedule slot beyond removal, but the added constraint is substantive.

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?

Two sentences, zero filler, with the core action front-loaded and the scoping restriction following. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 described, and annotations carry the destructive/idempotent profile. The description covers purpose and scope limitations well; the only minor gap is not mentioning which sibling handles modifying a plan instead of deleting it.

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?

Only one parameter with 100% schema description coverage, so the schema already documents workout_id and warns against inventing values. The description adds no parameter-level detail. Baseline 3 applies when the schema does the heavy lifting.

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 (cancels/removes) plus the resource (a planned, not yet done workout) and the effect (takes it off the schedule). The scope qualifier 'not yet done' clearly separates it from update_planned_workout, list_planned_workouts, and done-workout tools.

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 when-not guidance: workouts already marked done or skipped cannot be removed via this tool. It does not name the alternative tool (e.g. update_planned_workout) for modifying an existing plan, so routing is implied rather than stated.

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

get_body_profileGet body profileA

Read-only

Inspect

Body stats and training preferences the user entered in MoveMate (height, weight, age, gender, fitness level, activity level, goals, available equipment), whether MoveMate onboarding is complete, and the lifetime count of completed workouts. Use for program design or nutrition estimates that depend on these values.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`age`	Yes
`goals`	Yes
`gender`	Yes
`height_cm`	Yes
`weight_kg`	Yes
`fitness_level`	Yes
`activity_level`	Yes
`available_equipment`	Yes
`onboarding_complete`	Yes
`lifetime_completed_workouts`	Yes

TDQS

A3.9/5.0

Behavior3/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 the safety profile is covered. The description adds that the data was 'entered in MoveMate' and includes onboarding and lifetime workout count, but much of this is likely restated from the output schema rather than adding new behavioral context.

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?

The description is two tight sentences: the first front-loads what the tool returns, and the second states the intended use. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not explain return values, and annotations cover safety. It is nearly complete, but the lack of differentiation from the sibling get_profile leaves a small ambiguity for tool selection.

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?

There are zero input parameters, so there is no parameter semantics for the description to clarify. The baseline for a parameterless tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource (body stats and training preferences) and enumerates its fields, so the agent knows exactly what data is returned. It does not explicitly distinguish this tool from the sibling get_profile, which is the main gap.

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?

It gives a clear use case: 'Use for program design or nutrition estimates that depend on these values.' This tells the agent when the tool is appropriate. It does not mention when not to use it or name an alternative sibling tool.

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

get_exercise_progressionGet exercise progressionA

Read-only

Inspect

Per-exercise trend over time — weight, reps, and estimated 1RM per workout. Returns a chart for one explicitly requested exercise. Call at most once and only when the user names a specific exercise. For broad PR or overall-progress requests, use get_personal_records and get_training_stats instead; never fan this tool out across PRs or exercises.

ParametersJSON Schema

Name	Required	Description
`period`	No	Rolling window ending today. Default last_90d.
`exercise_id`	No	From search_exercises or an earlier result. Takes precedence over exercise_name.
`exercise_name`	No	Exercise name, fuzzy-matched against the library and the user's custom exercises. If several match, the result lists candidates to pick from. Send exercise_id or exercise_name.

Output Schema

ParametersJSON Schema

Name	Required	Description
`trend`	No
`locale`	No
`period`	No
`points`	No
`candidates`	No
`exercise_id`	No
`exercise_name`	No
`plateau_weeks`	No
`progression_mode`	No
`progression_metric`	No
`excluded_incompatible_sessions`	No

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral constraints beyond that: call at most once, one exercise per call, and that it returns a chart rather than raw rows. It doesn't describe pagination or empty-result behavior, but for a read-only tool that is minor.

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?

Three sentences, all earning their place, with the core purpose front-loaded and the anti-fan-out constraint closing. No filler.

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. Combined with 100% schema coverage and the explicit single-call/no-fan-out guidance, an agent has everything needed to invoke this correctly.

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 all three parameters (period enum, exercise_id, exercise_name, including precedence rules) are already documented in the schema. The description adds no parameter syntax or format detail beyond that, so 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+resource (per-exercise trend over time) and enumerates the returned metrics (weight, reps, estimated 1RM per workout). It clearly carves itself out from siblings like get_personal_records and get_training_stats, so an agent can route without opening schemas.

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?

Explicit when-to-use ('only when the user names a specific exercise'), when-not ('never fan this tool out across PRs or exercises'), and names the alternatives for broad requests. Nothing is left to inference.

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

get_personal_recordsGet personal recordsA

Read-only

Inspect

The user's best set per exercise (by estimated 1RM), most impressive first. Returns the complete requested PR list in one call. Never call get_exercise_progression for every returned record; only use progression when the user explicitly names one exercise.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many records to return, most impressive first. Default 20, max 100.
`exercise_id`	No	Return only the record for this exercise, from search_exercises or an earlier result. Omit for all exercises.

Output Schema

ParametersJSON Schema

Name	Required	Description
`records`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the result set is complete in a single call (no pagination/iteration implied) and is pre-sorted by impressiveness, which is not derivable from the schema.

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?

Three tight sentences, zero filler, with the defining scope ('best set per exercise by estimated 1RM') front-loaded before the ordering and the sibling guidance. Every sentence earns its place.

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?

Output schema exists so return shape needn't be explained, annotations cover the safety profile, and both parameters are fully documented. For a two-param read tool, nothing an agent needs to call it 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 both limit and exercise_id are already documented, including the default/max and the 'omit for all exercises' semantics. The description's 'most impressive first' ordering reinforces the limit param but adds no new syntax or constraints beyond the schema; baseline 3 is appropriate.

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+resource: the user's best set per exercise, ranked by estimated 1RM and ordered most-impressive-first. It also names the sibling it must not be confused with (get_exercise_progression), so an agent can distinguish it without opening either 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 routes usage: this call returns the complete PR list in one call, and get_exercise_progression should only be used when the user explicitly names a single exercise — including a prohibition on looping progression over the returned records. Both when-to-use and when-not-to-use are stated.

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

get_profileGet profileA

Read-only

Inspect

Returns the connected user's display name, timezone, and training frequency.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`timezone`	Yes
`display_name`	Yes
`member_since`	Yes
`workouts_per_week_avg`	Yes

TDQS

A3.5/5.0

Behavior3/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 the safety profile is fully covered. The description adds the useful detail that the target is the 'connected user' (i.e., implicit identity, no parameters), but nothing about failure modes or auth requirements.

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?

A single front-loaded sentence with no filler; the returned fields are listed compactly and nothing needs trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description needn't explain return values, and for a zero-argument read tool the description covers what an agent needs. Only the lack of sibling routing keeps it from being fully complete.

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?

Zero parameters, so there is no parameter semantics to document; baseline for a no-param tool is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Returns') and resource (the connected user's profile) and enumerates the returned fields (display name, timezone, training frequency), which helps distinguish it from the sibling get_body_profile. It stops short of explicitly contrasting with that sibling, so it lands just below the top tier.

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

Usage Guidelines2/5

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

The description says only what is returned; it offers no guidance on when to call this versus get_body_profile or the other profile/stats siblings. No prerequisites or exclusions are stated.

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

get_recent_workoutsGet recent workoutsA

Read-only

Inspect

What the user ACTUALLY did in past sessions, set by set — reps and weight of every completed set, total reps per exercise, and the planned targets they were working against. This is the tool for "how did I do?", for coaching progressive overload, and for anything about bodyweight work, where reps per set and total reps are the result and volume in kg is always 0. Narrow with exercise_name to get the same movement across its last few sessions.

ParametersJSON Schema

Name	Required	Description
`limit`	No	How many most recent sessions to return. Default 3, max 10. Use 1 for "how did my last workout go".
`workout_id`	No	A specific completed session, by the workout_id returned in an earlier result from this tool.
`exercise_id`	No	Return only sessions containing this exercise. From search_exercises or an earlier result.
`exercise_name`	No	Same filter by name, fuzzy-matched. Use this to compare one movement across its last few sessions.

Output Schema

ParametersJSON Schema

Name	Required	Description
`locale`	No
`workouts`	No
`candidates`	No
`filtered_by_exercise`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description earns credit by disclosing the shape of the data: per-set reps and weight, total reps per exercise, and the planned targets being worked against. The bodyweight caveat (volume in kg always 0) is genuinely useful behavioral context. It stops short of discussing limits beyond what the schema says.

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?

Dense but front-loaded: the core purpose comes first, then usage contexts, then the narrowing hint. Every sentence carries information, though the bodyweight aside is a slight tangent that lengthens an already packed paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description need not explain return values, yet it helpfully characterizes the payload anyway. Combined with full parameter documentation and annotations, an agent has everything needed to call it correctly; only explicit alternative-routing 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 the baseline is 3. The description reinforces the exercise_name use case ('compare one movement across its last few sessions') but adds no syntax or format detail beyond what the schema already documents for limit, workout_id, exercise_id, and exercise_name.

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?

The description states a specific verb and resource — retrieving completed sets with reps, weight, and planned targets — and clearly distinguishes this tool from siblings like get_workout, list_workouts, and get_exercise_progression by framing it as 'what the user ACTUALLY did', set by set. An agent can identify the tool's domain without opening the 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?

It gives explicit usage contexts ('how did I do?', progressive overload coaching, bodyweight work) and a narrowing pattern via exercise_name for comparing a movement across sessions. It lacks explicit when-not-to-use guidance or named alternatives, but the contextual routing is strong.

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

get_training_statsGet training statsA

Read-only

Inspect

Answers "how am I doing" — totals, volume, weekday frequency, and streak over a rolling period. Returns one complete training-stats summary for one rolling period. Call exactly once per distinct requested period (for a 7-day/30-day comparison, exactly two calls: last_7d and last_30d). Never call once per day, workout, exercise, set, or muscle group, and never repeat an identical period in the same answer.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Rolling window ending today. Default last_30d.
`muscle_group`	No	MoveMate muscle-group id — NOT a name such as "chest", which matches nothing and zeroes the volume. Usually omit it: the result already breaks sets down per muscle group in sets_per_muscle_group.

Output Schema

ParametersJSON Schema

Name	Required	Description
`locale`	Yes
`period`	Yes
`streak`	Yes
`avg_rir`	No
`rated_sets`	No
`total_volume`	Yes
`total_workouts`	Yes
`last_workout_at`	Yes
`avg_duration_min`	Yes
`sets_per_muscle_group`	Yes
`days_since_last_workout`	Yes
`workout_frequency_by_weekday`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish the safe read-only, non-destructive, closed-world profile, so the description need not restate safety. It does add genuinely non-obvious behavioral context: the one-call-per-period contract and the prohibition on repeating identical periods, which prevents over-calling. It does not describe pagination or response size, but with an output schema present that gap is small.

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?

Three sentences, front-loaded with the user-facing purpose before the return contract and the call discipline. Every sentence carries operative information; nothing is redundant or decorative.

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-value detail is unnecessary, and the description covers the two things the schema cannot: what the summary contains and how many times to call it. Complete for a zero-required-parameter read tool.

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 coverage is 100% and the schema itself already explains the period window and the muscle_group id-vs-name trap, so the schema carries the parameter burden. The description only references 'last_7d' and 'last_30d' as examples, adding no syntax or semantics beyond the enum. Baseline 3 is appropriate.

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 with concrete scope: totals, volume, weekday frequency, and streak over a rolling period, and clarifies it returns one summary per period. The call-discipline sentences ('never call once per day, workout, exercise, set, or muscle group') implicitly separate it from the per-entity siblings like get_workout and get_recent_workouts, so an agent can route correctly 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 Guidelines5/5

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

Explicit when-to-use rules: call exactly once per distinct requested period, exactly two calls for a 7-day/30-day comparison, and explicit never-call-per-entity exclusions. Alternatives and anti-patterns are both named, leaving nothing to inference.

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

get_workoutGet workoutA

Read-only

Inspect

Returns one specific MoveMate workout by its exact workout_id and renders the same workout card as list_workouts. Use this whenever the user asks to show, open, or display a particular workout already identified earlier in the conversation, especially one returned by create_planned_workout, update_planned_workout, list_planned_workouts, or list_workouts. Do not answer with only a text summary when a valid workout_id is available.

ParametersJSON Schema

Name	Required	Description	Default
`workout_id`	Yes	Exact workout_id returned by create_planned_workout, update_planned_workout, list_planned_workouts, or list_workouts.

Output Schema

ParametersJSON 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
`workouts`	Yes

TDQS

A4.2/5.0

Behavior3/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 the safety profile is covered. The description adds a genuine behavioral detail: the output is a rendered workout card identical to list_workouts. Beyond that it discloses nothing about lookup failure behavior, and the output schema already carries the return shape.

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 the core behavior and scoping, and the id provenance list is useful routing information. It is slightly longer than needed, but each sentence carries distinct value (what, when, and the anti-summary directive).

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?

With an output schema covering return values and annotations covering the safety profile, the description only needs to cover selection and invocation. It does both fully, including the conversational context ('identified earlier') that determines correct use.

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% for the single workout_id parameter, so the schema already documents format and provenance. The description reinforces the id's origin and demands exactness, but adds no syntax or validation detail beyond what's structured.

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 ('Returns one specific MoveMate workout') and pins the lookup key to an exact workout_id. It explicitly distinguishes itself from list_workouts by noting it renders the same workout card, so an agent can tell the two apart without opening either 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 when-to-use conditions ('show, open, or display a particular workout already identified earlier') and enumerates the sibling tools that produce a valid workout_id. It also adds a when-not directive: do not respond with only a text summary when an id is available.

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

list_planned_workoutsList planned workoutsC

Read-only

Inspect

What's coming up — so the model can answer that and avoid double-booking.

ParametersJSON Schema

Name	Required	Description	Default
`to`	No	ISO date, default: today + 14 days
`from`	No	ISO date, default: today

Output Schema

ParametersJSON Schema

Name	Required	Description
`planned_workouts`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, covering the safety profile entirely. The description adds no behavioral context beyond usage motivation — no note about date-window defaults, result ordering, or scope limits. With annotations doing the work, the description contributes essentially nothing here.

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

Conciseness3/5

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

It is a single short sentence with no padding, so nothing is wasted, but it is a subjectless fragment rather than a front-loaded statement of what the tool returns. Brevity here reflects under-specification more than disciplined conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists and annotations cover the safety profile, so return values and read-only nature need no explanation. What is missing is the one thing only the description can provide: how this planned-workout list differs from sibling list_workouts/get_recent_workouts, leaving the definition minimally viable but incomplete.

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% and both 'from'/'to' already document ISO format and their defaults (today, today+14 days), so the schema fully carries parameter meaning. The description adds no syntax, format, or filtering nuance, which is the expected baseline-3 outcome when the schema is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The fragment 'What's coming up' only implies listing upcoming planned workouts; the resource (planned workouts) comes entirely from the name/title. It gestures at a date-windowed, forward-looking list, which is somewhat distinguishing, but it never states the verb+resource explicitly, so an agent must lean on the tool name to know what it does.

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

Usage Guidelines3/5

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

'so the model can answer that and avoid double-booking' does give a use context — answer 'what's coming up' questions and check for conflicts before scheduling — which is better than nothing. However, it names no alternative (e.g. list_workouts for past sessions, get_workout for a specific one) and states no exclusions, so routing versus siblings is left to inference.

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

list_workoutsList workoutsA

Read-only

Inspect

Browses MoveMate's workout catalog — both the shared library and the user's own custom workouts, together by default. Use this to find an existing workout to schedule (with create_planned_workout) rather than building one from scratch, to browse by body focus ("give me a leg workout" — use category), or to look up one the user just opened in the app by its workout_id. Not the user's calendar (see list_planned_workouts) and not training history (see get_recent_workouts).

ParametersJSON Schema

Name	Required	Description
`type`	No	Restrict to only the shared library or only the user's own custom workouts. Omit for both.
`limit`	No	How many workouts to return. Default 20, max 50.
`query`	No	Matches workout titles and exercise names inside them — e.g. "push day" (a title) or "deadlift" (finds any workout containing it, even if the title doesn't mention it).
`category`	No	Body focus, style, or goal — e.g. "legs", "upper body", "full body", "core", "cardio", "hiit", "strength", "bodyweight", "stretching", "muscle gain", "get shredded", "recovery", "home workout", "beginner". Use this for "give me a leg workout"-style requests; use query instead for a specific exercise or title. Not for own/saved workouts — use type: "custom" for those.
`workout_id`	No	Look up one specific workout by its id — from an earlier result, a deep link, or context the app handed off. Overrides query.

Output Schema

ParametersJSON 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
`workouts`	Yes

TDQS

A4.4/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 the safety profile is covered and the bar is lower. The description still adds useful behavioral context — that the shared library and custom workouts are returned together by default, and that this tool is a discovery step feeding create_planned_workout. It stops short of describing pagination or result shaping, which keeps it from a 5.

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?

Roughly three sentences of dense content, front-loaded with the tool's scope before routing guidance. The parenthetical examples ('give me a leg workout') earn their place as disambiguation, though the list of siblings at the end makes it slightly list-heavy.

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 no explanation, and annotations cover the read-only safety profile. With usage, routing, and default-merging behavior all covered, an agent has everything required to call this tool correctly.

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 every parameter (type, limit, query, category, workout_id) is already documented, including the category-vs-query distinction and workout_id overriding query. The description largely restates that routing guidance ('give me a leg workout — use category'), adding little beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.

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?

The description states a specific verb and resource (browses the workout catalog) and immediately defines scope: shared library plus the user's custom workouts, merged by default. It explicitly distinguishes itself from list_planned_workouts and get_recent_workouts, so an agent can differentiate it from siblings 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 Guidelines5/5

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

It gives three concrete use cases (find a workout to schedule with create_planned_workout, browse by body focus via category, look up by workout_id) and two explicit exclusions with named alternatives (calendar → list_planned_workouts, history → get_recent_workouts). This is close to the ideal when/when-not/alternatives structure.

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

search_exercisesSearch exercisesA

Read-only

Inspect

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) — it decides which target fields create_planned_workout will accept for it, so read it before writing sets.

ParametersJSON Schema

Name	Required	Description
`limit`	No	How many exercises to return. Default 20, max 50.
`query`	No	Exercise name or part of it, fuzzy-matched — e.g. "bench press" or "romanian". Omit to browse by muscle_group or equipment.
`equipment`	No	Equipment name, e.g. "dumbbell", "barbell", "kettlebell" or "bodyweight". Common synonyms are accepted.
`muscle_group`	No	Muscle group name. Broad lower-body aliases are supported: legs, leg, lower body, and lower-body include quads, hamstrings, glutes, and calves.

Output Schema

ParametersJSON Schema

Name	Required	Description
`locale`	Yes
`exercises`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond them: it discloses that results include custom exercises and that each result carries an exercise_type governing which target fields are valid downstream. It does not mention pagination or ranking behavior, keeping it short of a 5.

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?

Three sentences, all front-loaded and purposeful: scope first, then the hard constraint, then the downstream dependency. No filler or restatement of the name.

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 in full, yet the description still highlights the one return field (exercise_type) that gates correct downstream usage. Combined with full schema coverage and read-only annotations, an agent has everything needed to call it correctly.

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 the schema already documents query, equipment, muscle_group, and limit with examples and aliases. The description adds no further parameter detail, so the 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 (Searches) and resource (MoveMate's exercise library) and clarifies scope by including the user's own custom exercises. An agent can immediately distinguish this from create_custom_exercise or get_exercise_progression.

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 the constraint that workouts must only be composed from exercises returned here and never invented, and instructs the agent to read exercise_type before writing sets — directly tying its use to the downstream create_planned_workout call. This is clear when-to-use and when-not-to-invent guidance.

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

update_planned_workoutUpdate planned workoutA

DestructiveIdempotent

Inspect

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. Because the list is replaced wholesale, any superset_group labels left out are removed too. 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.

ParametersJSON 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.
`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

ParametersJSON Schema

Name	Required	Description
`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

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, but the description adds substantive behavior: a skipped session becomes upcoming again when rescheduled, `exercises` is a wholesale replacement, and omitted superset_group labels are dropped. These are destructive side effects an agent could not infer from the annotations alone.

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 the core action and organized as one dense, informative paragraph with no filler. It is on the longer side, and the closing sentence about mixing strength and conditioning is somewhat discursive, but nearly every clause carries operational weight.

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, idempotent patch-style mutation on a nested exercise structure, the description covers eligibility, replacement semantics, label loss and unit/target conventions. An output schema exists, so return-value explanation is unnecessary, and nothing an agent needs to call it correctly is missing.

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 cross-parameter semantics the schema only states locally: the replace-whole-list rule for exercises ('to add an exercise, pass the existing ones plus the new one'), the loss of superset_group labels on omission, and the exercise_type-driven target selection across mixed strength/conditioning lists.

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 what can change: reschedule, rename, replace exercise list. An agent can distinguish this from create_planned_workout and delete_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?

Explicitly defines the eligible states (upcoming session, or one the app marked skipped because time passed) and the exclusion ('A finished workout cannot be changed'). It also gives the patch contract explicitly ('Pass only the fields you want to change; anything omitted stays as-is'), which removes the main ambiguity for an update tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateOct 3, 2026

Changedget_body_profile2 fields changed

removedOutput schema / properties / injuries_or_limitations

Removed value: -{
-  "items": {
-    "type": "string"
-  },
-  "type": "array"
-}

changedOutput schema / required

Previous value: -[
-  "onboarding_complete",
-  "height_cm",
-  "weight_kg",
-  "gender",
-  "age",
-  "fitness_level",
-  "activity_level",
-  "goals",
-  "available_equipment",
-  "injuries_or_limitations",
-  "lifetime_completed_workouts"
-]New value: +[
+  "onboarding_complete",
+  "height_cm",
+  "weight_kg",
+  "gender",
+  "age",
+  "fitness_level",
+  "activity_level",
+  "goals",
+  "available_equipment",
+  "lifetime_completed_workouts"
+]

14 tool updatesOct 1, 2026
- First observedcreate_custom_exercise
- First observedcreate_planned_workout
- First observeddelete_planned_workout
- First observedget_body_profile
- First observedget_exercise_progression
- First observedget_personal_records
- First observedget_profile
- First observedget_recent_workouts
- First observedget_training_stats
- First observedget_workout
- First observedlist_planned_workouts
- First observedlist_workouts
- First observedsearch_exercises
- First observedupdate_planned_workout

Publisher details

Operator: MoveMate Inc.
Operator website: https://movemate.app
Vendor relationship: First-party
Documentation: https://movemate.app/ai
Trust center: Unknown
Restrictions: None

Related MCP Connectors

LiftTrack AOAuth
com.lifttrackapp
Manage strength workouts and track exercise progress. Requires a LiftTrack account.
Health & Wellness
221
fitaf-ai-fitaf-mcp
ai.smithery
Track workouts, nutrition, body metrics, habits, and SMART goals with insights and trends. Connect…
Fitness Tracking Health & Wellness Note Taking
2
EvertrainOAuth
app.evertrain
Manage your Evertrain training — programs, workouts, exercises, history, and coaching notes.
Fitness Tracking Health & Wellness
1
Joti AOAuth
com.kompetic
Read your workouts, history, and stats; create and schedule new workouts. Writes are additive only.
Fitness Tracking Health & Wellness
141

Related MCP Servers

hevy-mcp
Health & Wellness Fitness Tracking
Caiuse
F
license
Not graded
quality
D
maintenance
Access your Hevy workout data through natural language. Query workout history, exercise details, routines, and track progress.
Updated a year ago (2025-10-29 10:40 UTC)
-
Caliverse MCP
Fitness Tracking Health & Wellness
somaticbits
A
license
Not graded
quality
B
maintenance
Enables AI assistants to plan, build, and log calisthenics workouts in a user's own account, including searching exercises, managing custom workouts and plans, reading progress and coaching data, and logging completed sessions. Account mutations require explicit confirmation, and workouts can be displayed as interactive cards in the chat.
Updated 10 hours ago (2026-10-07 12:19 UTC)
MIT
mcp-fitbod
Fitness Tracking Health & Wellness
Muno459
A
license
Not graded
quality
B
maintenance
Enables reading Fitbod training history, generating workouts via Fitbod's engine, configuring workout programs, and tracking body composition over time.
Updated a month ago (2026-08-28 13:26 UTC)
2
MIT
hevy-mcp
Fitness Tracking Health & Wellness
hmemcpy
A
license
Not graded
quality
C
maintenance
Enables ChatGPT to read and manage one Hevy account's workouts, routines, exercise history, body measurements, and active workout drafts, including previewing and applying routine or workout changes with revision checks.
Updated 4 days ago (2026-10-03 11:47 UTC)
10,338 npm
Apache 2.0

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?