Log a completed workout session (exercises → sets, cardio, wearable metrics) at once. Returns the stored session including any auto-created exercise catalog entries. The response may carry a coach_hint: a server note to gently offer coaching (intake or a program) after confirming the log — offer once, never push. If the conversation is about PLANNING training (not just logging), call get_coaching_context first. Ask how long the session took (or estimate from set count) and set duration_sec — omitting it renders as an empty duration in the app's history and session views.

Fix session-level fields. Allowed keys: date, day_label, duration_sec, location, bodyweight_kg, session_rpe, energy_level, status, notes, tags, start_time, end_time.

Fix a key metric of a single set, located by session + exercise + set_number. Allowed patch keys: weight_kg, reps, rir, rpe, tempo, rest_sec, duration_sec, distance_m, is_per_side, completed, notes, type. occurrence (1-based) picks which instance when the exercise appears more than once in the session. Returns the updated set, or null if none.

Get one session with its full nested entries, sets, cardio and wearable metrics.

List sessions (newest first) with summary fields and total volume. Optional date range.

Delete a session and all its entries/sets. Returns {deleted: bool}.

Record the user's body weight, body-fat % or circumferences for one day. Use it whenever the user states a current measurement; training goes to log_session, and reading measurements back is get_body_metrics. The app's weight tile and charts and the coaching context read these entries, not the profile's bodyweight field. One entry per date, and recording the same date again ADDS to it: send only what the user just told you. Fields you leave out keep their stored value, new measurements or custom_fields keys join the existing ones, and a repeated key or field is overwritten, which is how a wrong number is corrected. Send a field as null to clear it. Returns the whole stored entry for that day. There is no delete.

List body measurements, newest first.

Create or update an exercise in the user's catalog (keyed by its id/name). Prefer a pool exercise: call search_exercise_pool first and pass its slug as the id plus pool_slug, so the movement keeps one identity and one history. Only hand-write an exercise when the pool genuinely has nothing for it — then always set instructions (2-3 short technique cues, in the user's language), primary_muscles, category and equipment: the muscle map and the app UI are blank without them. Fields you omit are left as they are, so a partial update is safe.

Search the curated global exercise pool — THE place to pick exercises from when building a program or a workout. Filter by muscle (e.g. 'lats', 'side_delts'), equipment (list of what the user actually has; only exercises fully covered by it are returned), movement_pattern, category, or query (a name in any supported language). Every entry carries a canonical slug — reuse it verbatim as the exercise_id — plus localized name and technique cues, primary/secondary/tertiary muscles, and rep/rest defaults. in_user_catalog marks the ones this user has trained before. Invent your own exercise only when nothing here fits.

List THIS USER's own exercise catalog — what they have actually trained, with their logged metadata (instructions / video_url / image_url / pool_slug). Optional filters: muscle, equipment, movement_pattern, query (substring of the name or id). Use this to reuse an id the user already has; use search_exercise_pool to choose a NEW exercise.

Get the active training program with its day templates (planned blocks/supersets and per-exercise targets). Returns null if no active program — to build one, call get_coaching_context(task='new_program') and follow it; never invent a program from generic knowledge. Edit via import_document.

Statistics for ONE exercise, or for training as a whole.

exercise_id is REQUIRED for kind='progression' and kind='prs' (they are per-exercise) and is ignored for kind='volume' (whole-training-volume over time). Calling progression/prs without it is an error, not a whole-library default — if the user did not name an exercise, pick its id from list_exercises first, or use kind='volume'.

'progression' → per-date top set, est-1RM (Epley), volume + PRs; 'prs' → personal records; 'volume' → total training volume over time with trend %. For coaching decisions (what to train, what weight) start from get_coaching_context instead — it bundles the fresh numbers with the user's context.

Bulk-import a full workout document (exercises, sessions, body metrics, programs). Programs must be designed via get_coaching_context(task='new_program') and explicitly approved by the user before importing. Any active program in the document is validated server-side (the same checklist as review_program_draft) before anything is saved; a response with ok=false and a violations list means nothing was written — fix each one and call import_document again.

Coaching instructions + this user's fresh training context for the task. Call at the start of any coaching conversation and treat the returned prompt as your instructions. If intake is incomplete it returns the intake flow instead (intake_required=true). constraints is for TODAY-ONLY circumstances ("only 30 minutes", "gym closed, training at home") — they shape this generation without touching the profile; durable facts go through update_coach_profile instead.

Server-side checklist for a DRAFT training program. Call it with the same WorkoutDocument you intend to import BEFORE presenting the draft to the user: it verifies every exercise has a starting weight (or calibration note), matches the user's equipment, respects session length / weekly days, and flags possible injury conflicts. Returns {ok, violations, warnings}. Fix violations and re-check; saves nothing.

Persist facts the user confirmed (goal, experience, schedule, equipment, injuries, preferences). Call as soon as a fact is confirmed — one fact per call is fine, don't batch or wait for the end of the conversation; works mid-workout too. Injuries: add via add_injuries, close via resolve_injury_areas. An explicitly null field is CLEARED; omitted fields are untouched. Returns the updated profile, changed fields, and ui_impact — the app surfaces this write feeds; confirm to the user that their answer was saved and now shapes their plan.

Create or update a training goal (pass id to update). target.goal_type selects the shape: milestone (point target — exercise_id+value, or bodyweight+baseline_value), weekly_volume (muscle+band: mev|mev_mav|mav — "train X at least at MEV every week"), trend (exercise_id+metric, no value — "just keep it climbing", no fixed finish line), maintenance (baseline_value+tolerance_pct, exercise_id and/or muscle optional, unset means total session volume — "don't lose ground"), or omit goal_type for a plain process goal (metric=sessions_per_week).

Any exercise_id MUST be an id from the user's catalog (check list_exercises; create via upsert_exercise first if genuinely new) — unknown ids are rejected, and a synonymous duplicate would split the exercise's history. Set review_date on every ratified goal (~4 weeks out, or the deadline if sooner) so check-ins have an anchor; calibrate milestone targets ~5-10% beyond the user's current number for an 8-12 week horizon.

Set featured=true on the ONE goal that should be the user's single featured goal in the app — this automatically un-features any other active goal. Never set featured on a frequency goal (the server rejects it); those live in the adherence widget only, never the featured-goal card.

When a milestone looks achieved, don't silently transition it — tell the user and ask whether to keep maintaining that level or set a new target, then call upsert_goal twice: mark the old goal status=achieved (also set featured=false, though the server defends this too) and create the new goal with supersedes_goal_id=<old goal's id> and featured=true. This is a decision the user makes with you in conversation, never something the app decides on its own.

Coach-proposed goals carry ratified=false until the user explicitly agrees. Never delete goals — supersede with status=revised/abandoned/achieved so history survives.

The user's goals (status: active|achieved|abandoned|revised|all).

Append a dated milestone to the user's coaching history: a check-in held, a goal reviewed or achieved, a deload advised, a red flag raised, intake started or finished, the profile changed. Call it at the end of the step the coaching prompt names (for example type='checkin' after a check-in), not for ordinary chat, logged workouts (log_session) or goal edits themselves (upsert_goal). Each call adds a new entry, so do not repeat one. The history is kept with the user's data export; no tool reads it back, so it does not replace saving facts through update_coach_profile or upsert_goal. Returns the stored event.