Gym workout tracker: review your training, PRs and progression, and schedule workouts in the app.
Scored across 18 tools
Most tools have distinct purposes, but there is some subtle overlap between get_workout (card display) and get_workout_details (full contents for editing), and between create_custom_workout (saved routine) and create_planned_workout (scheduled session). The verbose descriptions clarify these boundaries well, but an agent could still occasionally misselect.
All 18 tools follow a consistent snake_case verb_noun pattern (create_, get_, list_, update_, delete_, search_, log_) with no mixing of conventions. Resource names are predictable and readable.
18 tools is slightly above the ideal range (3-15), but each tool earns its place by covering distinct facets of a full-featured fitness tracker: workouts, planned sessions, exercises, logging, stats, and profiles. The set feels comprehensive but not bloated.
Core lifecycles are covered: planned workouts have full CRUD, custom workouts have create/update/read, and exercises have search/create. However, there is no delete_custom_workout, no update/delete for custom exercises, and no way to remove or edit logged history — minor gaps that agents can work around but that prevent a perfect score.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 (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. |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| exercise_id | Yes | |
| exercise_type | Yes | |
| equipment_matched | Yes | |
| muscle_group_matched | Yes |
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.
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.
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.
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.
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.
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.
Saves a new workout to the user's own workouts ("My workouts" in the app) without putting it on the calendar — a reusable routine such as "Chest day". To also schedule it, pass the returned workout_id to create_planned_workout; to put a one-off session on a date, use create_planned_workout with an exercise list instead. Every exercise_id must come from search_exercises or create_custom_exercise — never invented. Propose the workout and get the user's agreement before calling. Not safe to blindly retry, though an identical call within two minutes returns the workout already saved instead of a second copy. Supersets and circuits are set with the superset_group label on each exercise — see that field for the rule it requires. Each exercise is measured by its own exercise_type (from search_exercises) — send the targets that type accepts. Free accounts can save a limited number of workouts from chat; a refusal for that reason says so and must not be retried.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional note for the whole workout, shown in the app. Max 500 characters. | |
| title | Yes | Workout name shown in the app, e.g. "Chest day". Max 60 characters. | |
| exercises | Yes | The exercises in the order they are performed — at least one. |
| Name | Required | Description |
|---|---|---|
| total | Yes | Total workouts matching the filter, which can exceed the returned list — narrow with query or type if it does. |
| locale | Yes | |
| warnings | No | |
| workouts | Yes | |
| total_sets | Yes | |
| workout_id | Yes | The saved workout — pass it to create_planned_workout to schedule it. |
| display_warnings | No | |
| upcoming_sessions | Yes | How many upcoming scheduled sessions use this workout — they show any change made to it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the mutation profile is covered. The description goes further with a concrete retry behavior — an identical call within two minutes returns the existing workout instead of a duplicate — and a quota refusal that must not be retried, which are genuinely useful operational details. It stops short of describing failure behavior for other error classes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose and the sibling routing, then layers constraints. It is dense and mostly earns its space, though the exercise_id provenance rule and the exercise_type targeting advice partially duplicate what the schema already says.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 the description still tells the agent to reuse the returned workout_id. Combined with the retry/quota behavior, sibling routing, and grouping constraints, an agent has everything needed to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 every field, including set_type semantics, per-hand weights, and superset_group's positional constraint. The description restates the exercise_id provenance rule that the schema also carries verbatim and points to superset_group without adding syntax, so it earns the baseline 3 rather than more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Saves a new workout to the user's own workouts"), identifies the UI location ("My workouts"), and names the sibling it is not ("without putting it on the calendar"), distinguishing it from create_planned_workout and update_custom_workout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes between alternatives: use create_planned_workout with the returned workout_id to schedule, or with an exercise list for a one-off session. It also states prerequisites (get the user's agreement before calling) and the condition for the free-account refusal and that it must not be retried.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | Optional note for the whole session, shown in the app. Max 500 characters. Not used with workout_id. | |
| title | No | 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. | |
| 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 | No | The exercises in the order they are performed — at least one. Required when building a new workout; not used with workout_id. | |
| workout_id | No | 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. | |
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
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. Removes only the session: a saved workout it was scheduled from stays in the user's saved workouts. When the same workout is scheduled more than once, pass session_date to pick the session.
| Name | Required | Description | Default |
|---|---|---|---|
| workout_id | Yes | From create_planned_workout or list_planned_workouts — never invented. | |
| session_date | No | The date (YYYY-MM-DD, the date part of scheduled_for in list_planned_workouts) of the session to cancel. Only needed when this workout_id is scheduled more than once; without it the next upcoming session is cancelled. |
| Name | Required | Description |
|---|---|---|
| deleted | Yes | |
| workout_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint. The description adds valuable context beyond annotations: the scope limit (only upcoming), that done/skipped workouts are unaffected, and that the underlying saved workout is preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place, with the core action and main constraint front-loaded before edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the operation, its limits, side effects on related saved workouts, and the duplicate-schedule case. With an output schema present, no return-value explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description reinforces session_date usage for duplicate schedules but adds no syntax 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.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (cancels/removes) and resource (planned workout), and it clearly distinguishes from siblings like list_planned_workouts and update_planned_workout by describing removal from the schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when it applies (upcoming planned workouts only) and the exclusion (done or skipped cannot be removed from chat), plus the session_date disambiguation for repeated schedules. No explicit alternative tool named, but conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
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.
| 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. |
| Name | Required | Description |
|---|---|---|
| records | Yes |
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.
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.
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.
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.
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.
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.
Returns the connected user's display name, timezone, and training frequency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| timezone | Yes | |
| display_name | Yes | |
| member_since | Yes | |
| workouts_per_week_avg | Yes |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| Name | Required | Description |
|---|---|---|
| locale | No | |
| workouts | No | |
| candidates | No | |
| filtered_by_exercise | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/safe profile, and the description adds real behavioral context: results include planned targets alongside actuals, and volume in kg is always 0 for bodyweight exercises (a genuinely useful interpretation caveat). It does not discuss limits/defaults, though the schema handles that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences that lead with what is returned before moving to use cases. Dense with quoted phrasing but every clause carries information; nothing is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering safety and an output schema covering return structure, the remaining burden is purpose and usage, both addressed. The description is self-sufficient for a zero-required-parameter read tool, though it never contrasts itself with the nearest siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 schema already explains limit, workout_id, exercise_id, and exercise_name. The description only echoes the exercise_name use case (comparing a movement across recent sessions), adding marginal meaning beyond the structured field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource and scope (completed sets, reps, weight, planned targets from past sessions) in vivid terms rather than restating the name. It distinguishes itself from progression/target-oriented siblings implicitly by emphasizing 'what the user ACTUALLY did', though it never names a sibling it must be told apart from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete scenarios — 'how did I do?', coaching progressive overload, bodyweight work — and tells the agent to narrow by exercise_name for cross-session comparison. There is no explicit exclusion or named alternative (e.g. get_exercise_progression), so the routing guidance is contextual rather than decisive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| workout_id | Yes | Exact workout_id returned by create_planned_workout, update_planned_workout, list_planned_workouts, or list_workouts. |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds useful context: it renders the same workout card as list_workouts, giving output-shape consistency across tools. It does not, however, state what happens with an invalid or stale workout_id, so error behavior remains undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause and the behavioral instruction is a short, forceful sentence. The enumeration of four source tools is duplicated verbatim from the input schema, which is mild waste, but the text stays readable and earns most of its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 does not need to explain return values, and it still notes card parity with list_workouts. The only material omission for a read tool operating alongside get_workout_details is a one-line distinction between the two, which an agent in this tool family will need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema description already states the id must come from create_planned_workout, update_planned_workout, list_planned_workouts, or list_workouts. The description repeats that constraint ('exact workout_id') without adding format, validation, or failure semantics beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It gives a specific verb+resource (returns one specific workout by exact workout_id) and ties the output to the list_workouts card format, so the agent knows what it produces. The gap is that the sibling get_workout_details exists and is never mentioned, so this tool is not fully differentiated from the closest alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong contextual routing: use it when the user asks to show/open/display a workout already identified in the conversation, and it explicitly discourages replying with a text summary when a valid workout_id exists. It also names the upstream tools that produce valid ids. It stops short of 5 because it never says when to prefer get_workout_details over this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a workout's full contents — every exercise with its exercise_id, exercise_type, sets and targets, rest, notes and superset grouping — in exactly the shape update_custom_workout, update_planned_workout and create_custom_workout accept. Call it before changing a workout's exercises: those tools replace the whole list, so start from this one, change what the user asked for, and send the rest back unchanged. Works for the user's saved workouts, library workouts and the workouts of scheduled sessions (workout_id from list_workouts, list_planned_workouts or an earlier write). To show the user a workout card instead, use get_workout.
| Name | Required | Description | Default |
|---|---|---|---|
| workout_id | Yes | From list_workouts, list_planned_workouts, get_workout or an earlier write — never invented. |
| Name | Required | Description |
|---|---|---|
| type | Yes | |
| notes | Yes | |
| title | Yes | |
| locale | Yes | |
| editable | Yes | True for the user's own saved workouts (update_custom_workout). False for library workouts and program workouts. |
| exercises | Yes | |
| workout_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this read-only and non-destructive, and the description adds genuinely new context the annotations cannot: the output shape is byte-compatible with three write tools and those write tools overwrite the entire exercise list. That downstream mutation behavior is exactly the kind of trait an agent needs before invoking a read to seed an edit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the payload description, then the when-to-use, then the alternative. Every sentence carries distinct information, though the workout_id sourcing is repeated verbatim from the schema and could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a single-parameter read with an output schema, so return-value documentation is not strictly required, yet the description covers the payload, the call ordering, valid ID sources and the sibling alternative. Nothing needed 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single workout_id parameter is already documented with its valid sources. The description restates the same sourcing guidance without adding syntax, format or constraint detail, so it sits at the baseline for a fully-covered schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource and enumerates exactly what the response contains (exercises, exercise_id, exercise_type, sets/targets, rest, notes, superset grouping). It explicitly distinguishes itself from the sibling get_workout, which returns a display card, so an agent can choose between them 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit read-modify-write workflow: call this before updating because update_custom_workout, update_planned_workout and create_custom_workout replace the whole list, then send the rest back unchanged. It also names get_workout as the alternative for card display and clarifies which sources produce a valid workout_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What's coming up — so the model can answer that and avoid double-booking.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ISO date, default: today + 14 days | |
| from | No | ISO date, default: today |
| Name | Required | Description |
|---|---|---|
| planned_workouts | Yes |
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.
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.
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.
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.
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.
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.
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 (pass its workout_id to create_planned_workout) rather than building one from scratch, to find one of the user's saved workouts to change (update_custom_workout, after reading it with get_workout_details), 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).
| Name | Required | Description | Default |
|---|---|---|---|
| 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. |
| 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 |
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's main behavioral addition is that library and custom results are merged by default, but the schema's `type` parameter already says 'Omit for both.' It adds no return shape, ordering, or pagination behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but front-loaded: the core purpose lands in the first clause, followed by usage routing and exclusions. The long parenthetical list of use cases is efficient, though the single-sentence structure makes it slightly harder to scan than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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. The description covers purpose, the merged-source default, parameter routing, downstream follow-ups, and the two nearest alternatives — everything an agent needs to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but the description goes further by tying parameters to workflows: category for body-focus requests vs query for exercise/title matches, and workout_id for deep links or handoff context passed to create_planned_workout. This cross-parameter routing guidance is meaningfully more than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Browses MoveMate's workout catalog') and immediately scopes it to the two underlying sources (shared library plus the user's custom workouts). It explicitly names the sibling tools it is not (list_planned_workouts, get_recent_workouts), so an agent can distinguish 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives four concrete use cases with the follow-up tool for each (pass workout_id to create_planned_workout, update_custom_workout after get_workout_details, category for 'give me a leg workout', workout_id for a recently opened workout). It also states the two exclusions explicitly and routes to the correct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Records workouts the user has ALREADY FINISHED into their MoveMate history — "log yesterday's workout: bench 4x8 at 80 kg, squats 3x5 at 100", or a short history the user is moving over from notes or another app. Send whole sessions with the sets actually done, up to 20 workouts per call. Not a live tracker: if the user wants to log set by set while training, point them to the workout tracker in the MoveMate app (rest timer, weight suggestions) instead of calling this after every set. Dates: a workout from before the user joined MoveMate is history and may have any date; a workout from since they joined must be from today or the last 14 days. For a future date use create_planned_workout. At most 300 past workouts can be moved in through chat in total; for a longer history or an export file from another app (Hevy, Strong and others), tell the user about the workout import in the MoveMate app instead. Every exercise_id must come from search_exercises or create_custom_exercise — never invented. Each exercise is measured by its exercise_type (from search_exercises); send the fields that type uses: 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. If you had to guess any exercise, weight, rep count or date, read the workouts back and get the user's agreement before calling. Safe to retry: a workout already in the history (same date, start time and title) is not added twice. Free accounts can finish 3 workouts in total (in the app and here together); workouts from before they joined do not count. A refusal for that reason says so and must not be retried.
| Name | Required | Description | Default |
|---|---|---|---|
| workouts | Yes | The finished workouts, oldest first. At most 20 per call. |
| Name | Required | Description |
|---|---|---|
| failed | Yes | |
| logged | Yes | Workouts done since the user joined that were added. |
| app_url | No | Opens the MoveMate app (or its store page) where the logged history is; give it to the user as is. |
| history_added | Yes | Workouts from before the user joined that were added. |
| already_logged | Yes | Workouts that were already in the history and were not added again. |
| free_workouts_left | Yes | |
| completed_workout_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Far beyond what the annotations say: discloses the 20-workouts-per-call and 300-total-moved limits, the free-account cap of 3 finished workouts, the date-window rules (any date before joining, today or last 14 days after), and that a refusal states its reason and must not be retried. It also gives dedupe semantics ('same date, start time and title' is not added twice), which the agent needs in order to reason about retries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then constraints, then field semantics — a sensible order and almost every sentence carries a distinct rule. It is dense, though, packing date rules, quotas, exercise_type mapping and dedupe into one block, so an agent must parse a long paragraph to extract the type-to-field mapping.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nested write tool with real quota and date edge cases, nothing essential is missing: identity of the operation, alternatives, per-type field requirements, unit conventions, limits, and failure behavior are all covered, and return values are carried by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even at 100% schema coverage this description adds meaning the schema cannot: it maps each exercise_type (default, time, time_weight, distance_time, weight_distance, cardio_machine) to the specific fields to send, and states that continuous cardio is one set per session rather than three. It also reinforces the exercise_id sourcing rule and the 'read back and confirm if you guessed' discipline that the schema does not express.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource ('Records workouts the user has ALREADY FINISHED into their MoveMate history') and immediately scopes it as backfill/history rather than live tracking. It explicitly separates itself from the in-app live tracker and from create_planned_workout, so an agent can pick between them 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use examples ('log yesterday's workout: bench 4x8 at 80 kg'), and explicit when-not: not set-by-set during training (point to the in-app tracker), future dates go to create_planned_workout, large histories go to the in-app import. It also names the escalation path for a quota refusal and forbids retrying it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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, calves, abductors, and adductors. Also accepted: full body, cardio, inner/outer thigh. |
| Name | Required | Description |
|---|---|---|
| locale | Yes | |
| exercises | Yes |
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.
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.
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.
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.
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.
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.
Changes one of the user's own saved workouts ("My workouts" in the app) — rename it, change its note, or replace its exercise list — the same as editing it in the app. Every scheduled session that uses this workout shows the change too, including upcoming ones; the response says how many. Library workouts cannot be changed: to make a personal version, save one with create_custom_workout. Pass only the fields you want to change; anything omitted stays as-is. exercises, if given, replaces the whole list — to add an exercise, pass the existing ones plus the new one in the right position; to remove one, pass the list without it. ALWAYS read the current list with get_workout_details first and send it back with your change — never rebuild it from memory, or the exercises, sets and weights you leave out are lost. Confirm the change with the user before calling. Each exercise is measured by its own exercise_type — send the targets that type accepts.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | New note for the whole workout. Send an empty string to clear it; omit to keep the current one. | |
| title | No | New workout name. Omit to keep the current one. | |
| exercises | No | Replaces the ENTIRE exercise list — send every exercise the workout should keep (as read with get_workout_details), not only the changed ones. Omit to keep the current exercises. | |
| workout_id | Yes | The saved workout — from list_workouts (type custom), create_custom_workout or get_workout_details. Never invented. |
| Name | Required | Description |
|---|---|---|
| total | Yes | Total workouts matching the filter, which can exceed the returned list — narrow with query or type if it does. |
| locale | Yes | |
| warnings | No | |
| workouts | Yes | |
| total_sets | Yes | |
| workout_id | Yes | The saved workout — pass it to create_planned_workout to schedule it. |
| display_warnings | No | |
| upcoming_sessions | Yes | How many upcoming scheduled sessions use this workout — they show any change made to it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true, and the description earns its keep beyond that by disclosing propagation to every scheduled session (including upcoming) and that the response reports how many, that omitted fields are preserved, and that a careless exercises payload silently destroys sets/weights left out. That is exactly the destructive-behavior context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and the central replacement-warning are front-loaded, and the longer run of sentences about exercises/get_workout_details is the highest-risk part of the operation so it justifies its length. Slightly verbose, with a few clauses that restate schema text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with an output schema already covering the return, the description supplies everything else an agent needs: scope of the change, propagation side effects, replacement semantics, prerequisite read, and confirmation step. No material gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics beyond it: exercises is a full replacement (add/remove must be done by re-sending the complete list) and each exercise is measured by its own exercise_type. It also repeats some schema content (omitted fields stay as-is), which keeps it from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource (change a saved 'My workouts' entry), enumerates the three mutable aspects (rename, note, exercise list), and draws an explicit boundary against library workouts with a named alternative (create_custom_workout). An agent can distinguish this from create_custom_workout and update_planned_workout without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit routing rules: library workouts cannot be changed, use create_custom_workout instead; always read the current list with get_workout_details before calling; confirm with the user first. These are when-to-use, when-not-to-use and prerequisite conditions, not merely implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Read the current list with get_workout_details first; never rebuild it from memory. Because the list is replaced wholesale, any superset_group labels left out are removed too. A session's title, notes and exercises belong to the workout it uses: if that workout is one of the user's saved workouts, the change applies to it and to every other session using it, as editing it in the app does; if it is a MoveMate library workout, which cannot be changed, the user's sessions of it switch to their own edited copy. Rescheduling and reminders only ever affect the one session. When the same workout is scheduled more than once, pass session_date to pick the session. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| session_date | No | The date (YYYY-MM-DD, the date part of scheduled_for in list_planned_workouts) of the session to change. Only needed when this workout_id is scheduled more than once; without it the next upcoming session is changed. Not the new date — that is scheduled_for. | |
| 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. |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and idempotentHint=true, and the description justifies both in concrete terms: exercises replaces the whole list, omitted superset_group labels are silently removed, and shared saved workouts propagate the change to every other session using them. It also discloses the MoveMate library fallback (sessions switch to their own edited copy) and the session-scoped behavior of rescheduling and reminders, none of which is inferable from 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and the primary mutation, then the replacement semantics, then the shared-workout edge case. Dense but each sentence carries a distinct rule; the length is justified by the tool's many mutation modes, though the exercise-list replacement rule is restated twice (description and schema).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter destructive mutation with nested set objects and a rich output schema, the description covers the failure modes an agent would otherwise get wrong: finished workouts, wholesale list replacement, superset label loss, shared-workout propagation, and multi-scheduling disambiguation. Return values need not be described since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 still adds cross-parameter synthesis not stated in any single field, notably that each exercise is measured by its own exercise_type so strength and conditioning can share one list, and the session_date-versus-scheduled_for distinction. The add/remove workflow for exercises largely restates the schema's own wholesale-replacement note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the three mutations it performs: reschedule, rename, replace exercise list. It also draws the boundary against the sibling update_custom_workout by explaining that editing a saved workout propagates to sessions while rescheduling affects only one session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when the tool applies ('has not been done yet'), when it does not ('A finished workout cannot be changed'), the prerequisite read ('Read the current list with get_workout_details first; never rebuild it from memory'), the partial-update contract, and when session_date is needed versus omitted. An agent has everything needed to route to this tool rather than update_custom_workout or create_planned_workout.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
log_completed_workouts1 field changedOutput schema / properties / app_urlAdded value: +{
+ "description": "Opens the MoveMate app (or its store page) where the logged history is; give it to the user as is.",
+ "type": "string"
+}log_completed_workoutscreate_custom_workout2 fields changedOutput schema / properties / workouts / items / properties / content_summaryAdded value: +{
+ "description": "Compact catalog tags used to compare muscle emphasis, goal, and duration when selecting a program.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / workouts / items / requiredPrevious value: -[
- "workout_id",
- "title",
- "type",
- "duration_min",
- "fitness_level",
- "exercises",
- "exercise_count",
- "is_premium",
- "image_url",
- "deep_link",
- "web_url"
-]New value: +[
+ "workout_id",
+ "title",
+ "type",
+ "duration_min",
+ "fitness_level",
+ "content_summary",
+ "exercises",
+ "exercise_count",
+ "is_premium",
+ "image_url",
+ "deep_link",
+ "web_url"
+]get_workout2 fields changedOutput schema / properties / workouts / items / properties / content_summaryAdded value: +{
+ "description": "Compact catalog tags used to compare muscle emphasis, goal, and duration when selecting a program.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / workouts / items / requiredPrevious value: -[
- "workout_id",
- "title",
- "type",
- "duration_min",
- "fitness_level",
- "exercises",
- "exercise_count",
- "is_premium",
- "image_url",
- "deep_link",
- "web_url"
-]New value: +[
+ "workout_id",
+ "title",
+ "type",
+ "duration_min",
+ "fitness_level",
+ "content_summary",
+ "exercises",
+ "exercise_count",
+ "is_premium",
+ "image_url",
+ "deep_link",
+ "web_url"
+]list_workouts2 fields changedOutput schema / properties / workouts / items / properties / content_summaryAdded value: +{
+ "description": "Compact catalog tags used to compare muscle emphasis, goal, and duration when selecting a program.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / workouts / items / requiredPrevious value: -[
- "workout_id",
- "title",
- "type",
- "duration_min",
- "fitness_level",
- "exercises",
- "exercise_count",
- "is_premium",
- "image_url",
- "deep_link",
- "web_url"
-]New value: +[
+ "workout_id",
+ "title",
+ "type",
+ "duration_min",
+ "fitness_level",
+ "content_summary",
+ "exercises",
+ "exercise_count",
+ "is_premium",
+ "image_url",
+ "deep_link",
+ "web_url"
+]update_custom_workout2 fields changedOutput schema / properties / workouts / items / properties / content_summaryAdded value: +{
+ "description": "Compact catalog tags used to compare muscle emphasis, goal, and duration when selecting a program.",
+ "type": [
+ "string",
+ "null"
+ ]
+}Output schema / properties / workouts / items / requiredPrevious value: -[
- "workout_id",
- "title",
- "type",
- "duration_min",
- "fitness_level",
- "exercises",
- "exercise_count",
- "is_premium",
- "image_url",
- "deep_link",
- "web_url"
-]New value: +[
+ "workout_id",
+ "title",
+ "type",
+ "duration_min",
+ "fitness_level",
+ "content_summary",
+ "exercises",
+ "exercise_count",
+ "is_premium",
+ "image_url",
+ "deep_link",
+ "web_url"
+]create_custom_exercise3 fields changedInput schema / properties / exercise_type / descriptionPrevious 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."Input schema / properties / exercise_type / enumPrevious value: -[
- "default",
- "time",
- "time_weight",
- "distance_time",
- "weight_distance"
-]New value: +[
+ "default",
+ "time",
+ "time_weight",
+ "distance_time",
+ "weight_distance",
+ "cardio_machine"
+]Output schema / properties / exercise_type / enumPrevious value: -[
- "default",
- "time",
- "time_weight",
- "distance_time",
- "weight_distance"
-]New value: +[
+ "default",
+ "time",
+ "time_weight",
+ "distance_time",
+ "weight_distance",
+ "cardio_machine"
+]create_custom_workout4 fields changedInput schema / properties / exercises / items / properties / sets / items / properties / target_distance_m / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_duration_seconds / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_levelAdded 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"
+}Input schema / properties / exercises / items / properties / sets / items / properties / target_speed_kmhAdded 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"
+}create_planned_workout4 fields changedInput schema / properties / exercises / items / properties / sets / items / properties / target_distance_m / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_duration_seconds / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_levelAdded 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"
+}Input schema / properties / exercises / items / properties / sets / items / properties / target_speed_kmhAdded 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"
+}get_recent_workouts2 fields changedOutput schema / properties / workouts / items / properties / exercises / items / properties / sets / items / properties / levelAdded value: +{
+ "type": "number"
+}Output schema / properties / workouts / items / properties / exercises / items / properties / sets / items / properties / speed_kmhAdded value: +{
+ "type": "number"
+}get_workout_details2 fields changedOutput schema / properties / exercises / items / properties / sets / items / properties / target_levelAdded value: +{
+ "type": "number"
+}Output schema / properties / exercises / items / properties / sets / items / properties / target_speed_kmhAdded value: +{
+ "type": "number"
+}search_exercises2 fields changedOutput schema / properties / exercises / items / properties / exercise_type / descriptionPrevious 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."Output schema / properties / exercises / items / properties / exercise_type / enumPrevious value: -[
- "default",
- "time",
- "time_weight",
- "distance_time",
- "weight_distance"
-]New value: +[
+ "default",
+ "time",
+ "time_weight",
+ "distance_time",
+ "weight_distance",
+ "cardio_machine"
+]update_custom_workout4 fields changedInput schema / properties / exercises / items / properties / sets / items / properties / target_distance_m / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_duration_seconds / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_levelAdded 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"
+}Input schema / properties / exercises / items / properties / sets / items / properties / target_speed_kmhAdded 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"
+}update_planned_workout4 fields changedInput schema / properties / exercises / items / properties / sets / items / properties / target_distance_m / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_duration_seconds / descriptionPrevious 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."Input schema / properties / exercises / items / properties / sets / items / properties / target_levelAdded 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"
+}Input schema / properties / exercises / items / properties / sets / items / properties / target_speed_kmhAdded 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"
+}search_exercises1 field changedInput schema / properties / muscle_group / descriptionPrevious 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."create_custom_workoutcreate_planned_workout5 fields changedInput schema / properties / exercises / descriptionPrevious 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."Input schema / properties / notes / descriptionPrevious 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."Input schema / properties / title / descriptionPrevious 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."Input schema / properties / workout_idAdded 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"
+}Input schema / requiredPrevious value: -[
- "title",
- "scheduled_for",
- "exercises"
-]New value: +[
+ "scheduled_for"
+]delete_planned_workout1 field changedInput schema / properties / session_dateAdded value: +{
+ "description": "The date (YYYY-MM-DD, the date part of scheduled_for in list_planned_workouts) of the session to cancel. Only needed when this workout_id is scheduled more than once; without it the next upcoming session is cancelled.",
+ "type": "string"
+}get_workout_detailsupdate_custom_workoutupdate_planned_workout2 fields changedInput schema / properties / exercises / items / properties / superset_group / descriptionPrevious value: -"Label marking exercises performed back-to-back as one superset or circuit — e.g. \"A\" for the first pair, \"B\" for the second. Omit it for a normal exercise done on its own. HARD CONSTRAINT: exercises sharing a label MUST be adjacent in this array, in the order they are performed — membership is defined purely by position in the list, so never interleave two groups and never separate members with an ungrouped exercise. A label used by only ONE exercise is dropped. Labels are replaced by internal ids when saved, so never send back a label read from an earlier response. Since `exercises` replaces the whole list, re-send the labels for any grouping you want to keep."New value: +"Label marking exercises performed back-to-back as one superset or circuit — e.g. \"A\" for the first pair, \"B\" for the second. Omit it for a normal exercise done on its own. HARD CONSTRAINT: exercises sharing a label MUST be adjacent in this array, in the order they are performed — membership is defined purely by position in the list, so never interleave two groups and never separate members with an ungrouped exercise. A label used by only ONE exercise is dropped. The letters get_workout_details returns can be sent back as-is to keep a grouping; never reuse any other label read from an earlier response. Since `exercises` replaces the whole list, re-send the labels for any grouping you want to keep."Input schema / properties / session_dateAdded value: +{
+ "description": "The date (YYYY-MM-DD, the date part of scheduled_for in list_planned_workouts) of the session to change. Only needed when this workout_id is scheduled more than once; without it the next upcoming session is changed. Not the new date — that is scheduled_for.",
+ "type": "string"
+}get_body_profile2 fields changedOutput schema / properties / injuries_or_limitationsRemoved value: -{
- "items": {
- "type": "string"
- },
- "type": "array"
-}Output schema / requiredPrevious 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"
+]create_custom_exercisecreate_planned_workoutdelete_planned_workoutget_body_profileget_exercise_progressionget_personal_recordsget_profileget_recent_workoutsget_training_statsget_workoutlist_planned_workoutslist_workoutssearch_exercisesupdate_planned_workoutStrength-training log for iPhone: read workouts, records and progress; plan and log training.
Workout tracker with a chat assistant: routines, live workouts, history and progress stats.
Plan workouts, find exercises and gyms, log sessions and track progress with Gym Navigator.
Workout log your AI fills in: sets from text or notebook photos, daily plans, history and records.
Add one secure layer between your agents and this server.