Do Workout

Scheduled workouts for a from_date–to_date calendar range. Use for "what is on my schedule this week?"; not for Home next-action (get_training_status) or progression/deload cards (get_program_status). Host must supply IANA timezone (e.g. Europe/Kyiv) via time_zone or tools/call _meta.clientContext.timezone. Do not ask the human. Do not invent today from raw logs — call this view.

get_week_schedule

Read recent completed workout session logs (dates, volume, notes). For "what should I train today?" use get_training_status instead of inventing from history.

get_workout_history

Search the merged Do Workout system + user exercise catalog when exercise IDs are not already available from get_program, prior list_exercises calls, or other Do Workout tool results. Reuse returned IDs; do not re-query merely to verify them because proposal tools validate referenced exercise IDs server-side. Prefer one broad filtered search with an appropriate limit over many single-exercise text searches; paginate with cursor alone when more matches are needed (nextCursor is an offset into the query-matched list). exclude_exercise_ids is optional — it only drops IDs from the returned page after the cursor offset; do not rely on it to walk the catalog. Call this tool sparingly while building a program.

list_exercises

List training program summaries for the authenticated user (id, title, workout names, revision, progression flags). Call this first to obtain program_id and revision for get_program or propose_program_changes.

list_programs

List the authenticated user's AI program proposals (default statuses: pending). Use after propose_* to check status; never claim the program was updated until status is accepted.

list_training_change_requests

Creates a pending proposal in Do Workout (TrainingChangeRequest + in-app notification). Does NOT modify the Program. The user must Accept or Reject in the Do Workout app; only Accept applies changes. Never tell the user the program was updated after this tool alone. Requires program_id and expected_revision from list_programs or get_program, plus title, summary, changes[], and idempotency_key (16–128 chars). Referenced catalog/configuration IDs are validated by Do Workout when the proposal is created. After transport uncertainty, retry with the SAME idempotency_key; a new key may create a separate pending proposal. Call get_program_change_command_schema before composing changes[] (all types, fields, clientWorkoutKey workout refs, examples). Each item: { change: { type, ...fields }, reason }. addWorkout: set clientWorkoutKey; reuse it as workoutId / in reorderWorkouts.workoutIds in the SAME proposal. Progression: setProgramProgression = whole-program overwrite (cascades exceptions); setExerciseProgression = per-lift Mixed/exceptions only (assignment none|profile|inherit).

propose_program_changes

Creates a pending new-program proposal in Do Workout (TrainingChangeRequest + notification). Does NOT create the Program. The user must Accept or Reject in the Do Workout app; only Accept creates it. Never tell the user the program exists after this tool alone. Gather enough context first and reuse exercise IDs from prior Do Workout results. Call list_exercises only for missing IDs, preferring one or a few broad searches; do not make per-exercise verification calls. Requires proposal title, summary, idempotency_key (16–128 chars), and a complete definition shaped as {title, workouts:[{name?, clientWorkoutKey?, exercises:[{exerciseId, prescription?, progression?}], timers?, blocks?}], schedule?, progression?}. progression.enabled required when progression is present; exercise progression: assignment inherit|none|profile (+ profileId) — not targetRepRange (profile summary read-only). blocks? follows workoutBlocks in the command schema (omit id). Reject unknown fields (e.g. equipmentProfileId). Validate catalog IDs at propose time. After transport uncertainty, retry with the SAME idempotency_key; a new key may create a separate pending proposal.

propose_program_creation