Skip to main content
Glama
turnnoblindeye

Wellness Project MCP

log_workout

Destructive

Record completed workout sessions with exercises, sets, reps, weights, RPE, and focus so training history is captured accurately and available for future queries.

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.

Log a complete workout session: exercises, sets, reps, weights, and session metadata. Use when the user describes finishing a workout, lists exercises performed, or asks to log training. A workout they have not done yet is not a log: use propose_workout for that.

EXERCISE NAMES:

  • Call list_exercises first; match each exercise to the closest canonical name. No reasonable match → use the name as stated. Don't ask before logging, match silently and log.

  • "Chest press" (machine) and "bench press" (barbell) are DISTINCT — pass the user's term through so the resolver's aliases pin the right one.

  • name is ONLY the exercise name, never reps/weights/sets — those go in the sets array.

  • 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.

  • The result says when a name was matched to something other than what the user said. Relay it in your own words rather than repeating the line verbatim. 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.

  • 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.

SETS:

  • "3 sets of 15 reps" → 3 set objects with reps: 15. "15/12/10" → 3 sets with reps 15, 12, 10.

  • Pure isometric holds (planks, dead hangs, wall sits) have no reps: "30 second plank" = { hold_length_sec: 30 }.

  • Tempo/pause work combines reps + weight_lb + hold_length_sec (seconds per rep) on the same set, never in notes.

  • Loaded carries (farmers carry, sled push, weighted plank) are one set per trip: hold_length_sec + weight_lb, omit reps unless a trip count is given. weight_lb is PER HAND for a two-implement carry, TOTAL for one implement. Distance has no column and is never a duration — put it in notes.

INFER — do not ask:

  • date: today, or from context

  • focus_type: from the exercises (bench/shoulders/triceps=Push, rows/pulldowns/curls=Pull, squats/deadlifts/lunges=Legs, mixed upper=Upper, everything=Full Body)

  • is_bodyweight: true for pull-ups, push-ups, dips, bodyweight squats

  • superset_group: same integer for exercises done back-to-back or as a superset

  • slot_type: 'warmup' for prep at the start, 'finisher' for burnout/cardio at the end, 'working' (default) otherwise

RPE (Rate of Perceived Exertion) — 1-10 scale, half steps allowed (7.5, 8.5):

  • Session-level RPE: overall session difficulty. Infer from user comments like "brutal session" (8-9) or "easy day" (3-4). Optional.

  • Per-set RPE: how hard each individual set felt. Include only if the user explicitly mentions per-set effort or failure. Optional.

  • Scale: 1=minimal effort, 5=moderate, 7=hard, 8=few reps left, 9=one rep left, 10=maximal/failure.

ASK (single batched question) only if missing and not inferable: location, focus_type (list ambiguous), heart_points (tracker provides them but not mentioned).

RETURNS the new session's ID (as "[ID NN]"). Pass it to update_workout / delete_workout / get_workout / add_exercises for follow-ups in this conversation.

SAVED WORKOUT MODE: when the user asks to save a workout for reuse, set save_as_saved_workout=true and pass the full prescription through this same tool. In saved mode the workout is NOT logged as completed history. To replace an existing Saved Workout, also pass saved_workout_id; the supplied prescription fully replaces its prior prescribed sets/reps/weights. Use saved_workout_title when the reusable name should differ from focus_type.

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.
dateYesYYYY-MM-DD. Default to today.
notesNoSession notes: how it went, PRs hit, how they felt.
locationNoGym, Home, Outdoor. Infer from context or ask.
exercisesYesEvery exercise performed, in order.
focus_typeNoInfer from the exercises: Push, Pull, Legs, Upper, Lower, Full Body, Cardio, Mobility. Ask only if genuinely unclear.
saved_workout_idNoExisting Saved Workout ID to replace in saved mode. Omit to create a new Saved Workout.
heart_points_peakNoPeak-intensity heart points, if mentioned.
saved_workout_titleNoOptional reusable workout name in saved mode. Defaults to focus_type.
heart_points_moderateNoModerate-intensity heart points, Google Fit or equivalent, if mentioned.
save_as_saved_workoutNoTrue when this payload is a reusable Saved Workout prescription, not a completed workout. Defaults to false.

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?

Discloses the tool's own unit conversion, exercise-name resolution, near-miss prompting, silent matching behavior, and saved-workout semantics. The destructive annotation aligns with logging side effects, with no contradiction.

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 but well-sectioned and each section conveys important rules. A few repeated emphases could be tightened, but the length is largely warranted by the tool's complexity.

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?

Provides enough context to call the tool correctly: what to infer, when to ask, how to structure sets, how to handle units and equipment, and what the tool returns. Even without an explicit output schema, the return value and follow-up usage are covered.

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?

Adds substantial meaning beyond the schema: unit-input overrides, per-set reps/holds/carries, equipment load basis, superset grouping, slot inference, RPE interpretation, and saved-workout fields. This goes well beyond the field descriptions.

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?

Clearly states the tool logs a complete workout session with exercises, sets, reps, weights, and metadata. It also distinguishes itself from related actions like updating, deleting, or proposing workouts.

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

Usage Guidelines5/5

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

Explicitly says when to use it: when the user describes finishing a workout or asks to log training. It also says not to use it for future workouts and explains saved-workout mode and follow-up use with the returned ID.

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