Skip to main content
Glama
turnnoblindeye

Wellness Project MCP

update_workout

DestructiveIdempotent

Correct workout sessions after logging: fix weights, reps, notes, or dates; add, remove, rename, or move exercises; and update saved workouts—so your fitness history stays accurate.

Instructions

UNIT INPUTS: never convert units yourself. Pass the user's number for a _lb / _mi / _in field exactly as stated, and when they gave kg / km / cm set input_weight_unit / input_distance_unit / input_length_unit in that same object. Omit the companion when the number is already lb / mi / in. The tool converts once before storage, so this overrides any wording that asks you to do the arithmetic.

Update a workout session: correct metadata, fix set values, rename/add/remove exercises or individual sets, or move exercises between supersets. Use for any post-log correction.

FIND THE SESSION: pass session_id if already known. Otherwise pass session_date (YYYY-MM-DD, defaults to today) and, only if more than one session was logged that day, name (a substring of the workout's focus/type, case-insensitive) to narrow it down. A match that isn't exactly one session returns an error explaining why, with nothing changed — retry with session_id or a narrower name, never guess. get_workout still gives full detail (exercise names, slot names SS1/SS2/WarmUp/Finisher) when needed; list_exercises first if adding or renaming. Call with only the fields that change — operations can combine in one call.

OPERATIONS:

  • Metadata: date, focus_type, location, notes, rpe, heart_points_moderate/peak.

  • set_updates: patch reps/weight/notes/equipment on a set, addressed by set_id OR by exercise_name + set_position (1-based, matches get_workout's "Set N").

  • remove_sets: delete sets, same set_id-or-exercise_name+set_position addressing; remaining sets renumber; an emptied exercise/slot is removed automatically.

  • rename_exercises: renames every set of an exercise in place (preserves set IDs, RPE, notes; rebuilds NSI), never remove + add.

  • remove_exercises: deletes all sets for named exercises; empty slots removed automatically.

  • add_exercises: new exercises with sets; to_superset_slot joins an existing slot, omit for standalone.

  • move_exercises: reassigns an exercise to a different slot; "new" makes it standalone.

SUPERSET SLOTS: rename_exercises/remove_exercises match by exercise name alone unless scoped. If a name is in more than one slot and the user means only one, pass superset_slot (or { name, superset_slot } for remove_exercises) naming that slot from get_workout. Omitting it hits every occurrence, a real corruption risk.

LITERAL NAME: literal_name: true keeps the user's exact wording instead of the closest library match, skips the resolver, and gets no NSI score (no benchmark to compare an unmatched name against). Use for "call it exactly X", "not the standard one", "literally X", or a rejected match. Applies below.

EQUIPMENT (load basis): dumbbell_pair is one dumbbell in EACH hand, weight_lb PER HAND (2x for NSI); dumbbell_single is one implement total. Laterality (single-leg/arm) does NOT decide this alone. Set it when the user describes the load (each hand, machine, band); a wrong or missing tag silently halves or doubles NSI. Values: barbell, dumbbell_pair, dumbbell_single, machine, kettlebell, bodyweight, band, cable, trx, other.

A set_id or exercise_name+set_position matching more than one set (the same exercise in two superset slots) is ambiguous and errors rather than guessing — use the exact set_id from get_workout to disambiguate.

The result discloses a mismatched name from rename_exercises/add_exercises; relay it in your own words. If a name matches nothing closely enough, the result names near-miss library exercises; ask the user which they meant rather than accept the unscored custom log silently.

INFER — do not ask: session_date defaults to today, set positions count from 1 per exercise. Slot names and set_ids beyond what's inferable come from get_workout; canonical exercise names come from list_exercises.

SAVED WORKOUTS: pass saved_workout_id to edit a reusable Saved Workout instead of completed workout history. Use saved_workout_title and/or saved_exercise_updates. For progression requests, inspect real exercise history first rather than applying a deterministic formula.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rpeNoSession RPE, 1-10, half steps allowed: 5 moderate, 7 hard, 9 one rep left, 10 failure. Infer from comments about overall difficulty, or omit.
dateNoNew session date, YYYY-MM-DD.
nameNoSubstring of the focus/type, e.g. "Push", case-insensitive, to pick between sessions on session_date. Only without session_id.
notesNoNew session notes.
locationNoNew location, e.g. Gym, Home.
focus_typeNoNew category, e.g. Push, Pull, Legs.
session_idNoSession ID, if known. See FIND THE SESSION above.
remove_setsNoSets to delete. See OPERATIONS above.
set_updatesNoIndividual set corrections.
session_dateNoYYYY-MM-DD, defaults to today. Finds the session when session_id is omitted. Distinct from `date`, which CHANGES the stored date.
add_exercisesNoNew exercises to add. Call list_exercises first for canonical names.
move_exercisesNoMove exercises between superset slots.
remove_exercisesNoExercises to remove; matched sets deleted, empty slots removed automatically. See SUPERSET SLOTS above.
rename_exercisesNoRename logged exercises in place.
saved_workout_idNoSaved Workout ID to update instead of a completed workout session.
heart_points_peakNoNew peak heart points.
saved_workout_titleNoOptional new title for the Saved Workout.
heart_points_moderateNoNew moderate heart points.
saved_exercise_updatesNoOptional prescription edits matched by exercise name inside the Saved Workout.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesHuman-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.2.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only state readOnlyHint=false, destructiveHint=true, idempotentHint=true. The description adds exactly the contextual detail the rubric asks for: what gets destroyed ("remaining sets renumber; an emptied exercise/slot is removed automatically"), side effects (rename "preserves set IDs, RPE, notes; rebuilds NSI"), silent failure modes (missing equipment tag "silently halves or doubles NSI"), and error semantics (ambiguous matches "error rather than guessing," with "nothing changed"). No contradiction with the annotations.

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

Conciseness4/5

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

The description is long (~450 words) but earns most of its length: 19 parameters, 8 operation types, and multiple addressing schemes justify dense detail, and the section headers (UNIT INPUTS, FIND THE SESSION, OPERATIONS, SUPERSET SLOTS, LITERAL NAME, EQUIPMENT, SAVED WORKOUTS) make it scannable, with the highest-risk guardrail (units) front-loaded. It loses a point for minor redundancies — the set-addressing concept is restated a few times, and it references input_distance_unit/input_length_unit that do not appear in the schema.

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

Completeness5/5

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

An output schema exists, so return-value documentation is unnecessary. The description covers every operational need: session disambiguation rules, ambiguity/error behavior, cross-tool prerequisites (get_workout for slot names and set_ids, list_exercises for canonical names, get_exercise_history for progression), the Saved Workout alternative, and post-call user communication ("relay it in your own words," "ask the user which they meant"). Nothing required for correct invocation is missing.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes far beyond type/format notes: UNIT INPUTS explains when to set input_weight_unit and when to omit the companion; OPERATIONS defines the set_id vs exercise_name+set_position addressing duality; EQUIPMENT gives the load-basis meaning ("dumbbell_pair is one dumbbell in EACH hand, weight_lb PER HAND"); LITERAL NAME explains resolver-skipping and NSI implications. These are value semantics the schema alone could not convey.

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

Purpose5/5

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

The description states a specific verb and resource — "Update a workout session: correct metadata, fix set values, rename/add/remove exercises or individual sets, or move exercises between supersets" — and closes the scope with "Use for any post-log correction." This clearly differentiates it from log_workout (creation) and delete_workout (removal) among the large sibling set.

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

Usage Guidelines5/5

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

Explicit when-to-use guidance is given: "Use for any post-log correction." It routes to siblings with concrete conditions — "get_workout still gives full detail ... when needed; list_exercises first if adding or renaming" — and covers the alternative target via "pass saved_workout_id to edit a reusable Saved Workout instead of completed workout history." It even provides an exclusion: "For progression requests, inspect real exercise history first rather than applying a deterministic formula."

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/turnnoblindeye/wellness-project-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server