Povver — Strength Training

Your strength-training data, in any AI assistant.

От сообществаСбоиБез входаГлобальныйБесплатноМожет изменять данные

Что умеет

  • Check Connection: Verify the connection is working and get basic user info: display name, subscription status, selected language (locale), whether the user has an active routine, and whether they have
  • Get User Profile: Get the user's coaching profile: name, primary goal (e.g. build muscle / lose fat), experience level, target training days per week, equipment preference (e.g. full gym / home), heig
  • Get Training Snapshot: Get a compact overview of the user's training setup and recent activity: profile, active routine with template names, next scheduled workout, last 10 workout summaries, and stre

Какие данные видит

Нужен ли аккаунт

Не нужен: сервер работает без входа

Your strength-training data, in any AI assistant.

Povver is a strength-training app for iOS. This connector gives an AI assistant read and write access to your own Povver data over MCP:

  • Workout history at set level — weight, reps, RIR, set type — plus per-session volume and records
  • Strength progress — per-lift e1RM trends, plateau detection, personal records, and the Strength Climb signal
  • Muscle-group volume — weekly hard sets against MEV/MAV/MRV targets, fatigue (ACWR), balance
  • AI training insights and pending recommendations you can accept, reject, or revert
  • Injury memories — report pain so the coach steers around it
  • Full program management — routines, workout templates, and periodization plans (create, update, pause, resume)

40 tools, 6 attachable resources, 4 prompts. Every tool carries readOnlyHint / destructiveHint, so a client can tell reads from writes from deletes.

Sign in with your Povver account (OAuth 2.1). Requires a Povver premium subscription. For automation, an API key from the app (More → Integrations → Developer access) works as a Bearer token.

Try: "Act as my strength coach: review my recent training, find my biggest weakness, and update my program to fix it." · "How's my bench press trending over the last 8 weeks?" · "Which muscle groups am I under-training?"

Docs: https://mcp.povver.ai · Privacy: https://povver.ai/privacy · Support: info@povver.ai

Как подключить

Как подключить Povver — Strength Training к Claude

Адрес сервера, который нужно вставить в настройках Claude:

https://mcp-server--povver.run.tools

  1. Откройте Claude (сайт claude.ai или приложение для компьютера).
  2. Перейдите в Настройки → Коннекторы (в английском интерфейсе: Settings → Connectors).
  3. Нажмите Добавить пользовательский коннектор (Add custom connector).
  4. Вставьте адрес сервера, скопированный ниже, в поле URL удалённого MCP-сервера и нажмите Добавить.
  5. В чате нажмите + → Коннекторы и включите новый коннектор.

Пользовательские коннекторы доступны на тарифах Free, Pro, Max, Team и Enterprise. На Free можно добавить только один. В Team и Enterprise коннектор сначала добавляет владелец организации в Настройки организации → Коннекторы.

Авторизация

После нажатия Добавить откроется окно входа в сервис. Войдите под своим аккаунтом и подтвердите доступ. Пароль Claude не видит.

Как подключить Povver — Strength Training к ChatGPT

Адрес сервера, который нужно вставить в настройках ChatGPT:

https://mcp-server--povver.run.tools

  1. Откройте ChatGPT в браузере (chatgpt.com). Нужен тариф Plus, Pro, Business, Enterprise или Edu.
  2. Один раз включите режим разработчика: Настройки → Приложения → Дополнительные настройки → Режим разработчика (Settings → Apps → Advanced settings → Developer mode).
  3. Откройте Настройки → Коннекторы и нажмите Создать (Create).
  4. Заполните форму: Название (любое), Описание (одна фраза, что делает сервис), URL MCP-сервера (скопируйте ниже).
  5. В поле Аутентификация выберите OAuth, если сервис требует вход, иначе Нет. Нажмите Создать.
  6. В новом чате откройте + → Приложения/Коннекторы и включите коннектор.

Название раздела у OpenAI менялось (Connectors → Apps/Plugins). Если пункт называется иначе, ищите «режим разработчика» в настройках. В рабочих пространствах Business/Enterprise администратор должен разрешить пользовательские коннекторы.

Авторизация

При первом использовании ChatGPT откроет окно входа в сервис. Войдите и подтвердите доступ.

Как подключить Povver — Strength Training к Cursor

Адрес сервера, который нужно вставить в настройках Cursor:

https://mcp-server--povver.run.tools

Быстрый способ: нажмите кнопку Открыть в Cursor ниже, Cursor сам предложит добавить сервер.

Вручную:

  1. В Cursor откройте Settings → Cursor Settings → MCP и нажмите Add new global MCP server.
  2. Вставьте JSON, скопированный ниже, в открывшийся файл ~/.cursor/mcp.json (для одного проекта: .cursor/mcp.json в корне проекта).
  3. Сохраните файл. Сервер появится в списке MCP; при необходимости пройдите авторизацию по кнопке рядом с ним.

Авторизация

Если сервис требует вход, рядом с сервером в списке MCP появится кнопка авторизации.

Список инструментов сервера (40)

Технические названия из tools/list. Нужны только разработчикам.

check_connectionVerify the connection is working and get basic user info: display name, subscription status, selected language (locale), whether the user has an active routine, and whether they have logged workouts. Use this as a first call to confirm the integration is live and to discover the user's language for localized queries.
get_user_profileGet the user's coaching profile: name, primary goal (e.g. build muscle / lose fat), experience level, target training days per week, equipment preference (e.g. full gym / home), height and weight (with units), timezone, and member-since date. Use this to CONTEXTUALIZE advice to the user's background and constraints — tailor volume, exercise selection, and progression to their experience level and available equipment. Excludes account/billing internals and contact info. For current-week training activity use get_training_snapshot; for subscription/connection status use check_connection.
get_training_snapshotGet a compact overview of the user's training setup and recent activity: profile, active routine with template names, next scheduled workout, last 10 workout summaries, and strength records. Use this as a first call to orient yourself on who the user is and what they're doing. Set include_data_quality=true to also get a data_quality block (overall e1RM coverage, fragmented exercise variants, lifts that can't trend yet, stale trends) — the coverage context that tells you which numbers the data actually supports; for the full per-exercise list use list_trained_exercises. For deeper analysis, use get_training_insights. For adherence trends, use get_training_status.
list_routinesList all of the user's routines (name, ID, template IDs, frequency, active status). Use when the user asks "what routines do I have?" or you need to find a routine ID. Returns summary data — use get_routine for full template details.
get_routineGet a specific routine with its template names and exercise summaries. Use when you need the structure of a particular routine — which templates it contains and in what order. Set include_templates=false if you only need the routine metadata.
list_templatesList all workout templates (names + IDs only, no exercise details). Use when the user asks "what templates do I have?" or you need template IDs for creating/updating a routine. For full exercise prescriptions, use get_template with a specific ID.
get_templateGet a specific template with its full exercise list and set prescriptions (reps, weight, RIR). Use when you need to see or discuss the contents of a specific workout template. An exercise carries `coach_note` when someone wrote one — the authored reason that lift is in the program (an injury, a preference, a deliberate emphasis). Read it before proposing to change or remove the exercise, and pass it back on update_template or you will erase it.
list_workoutsList recent workouts as summaries: date, exercise names, and set counts. Each workout and exercise carries the same two labelled counts as get_workout — `working_set_count` (non-warm-up) and `total_set_count_including_warmups` — plus aggregate analytics (total volume). Use for "what did I do this week?" or "show my recent workouts." Returns summaries — use get_workout with a specific ID for full set-level data. A workout or exercise the athlete annotated in the app carries a `notes` field (absent when they wrote none) — read it, it is the athlete's own account of what happened. When `hasMore` is true, pass the returned `next_cursor` back as `cursor` for the next page.
get_workoutGet a specific workout's exercises and set-level data (weight_kg, reps, RIR, set type, completion), sets ordered warm-ups-first. Returns two labelled, unambiguous set counts at workout AND per-exercise level: `working_set_count` (non-warm-up sets, counted regardless of completion — each set carries `is_completed` if you need to exclude abandoned ones) and `total_set_count_including_warmups` (all sets) — use these, not raw array lengths. verbosity="compact" (DEFAULT) returns the lean set-level view for "what did I do this session?"; verbosity="full" additionally returns the per-muscle analytics maps (weight/reps/sets/hard-sets per muscle & group) for muscle-attribution questions — larger payload. A workout, and each exercise in it, carries `notes` when the athlete wrote one in the app ("left shoulder ached on the last rep", "25s were taken so I used 20s"); the field is absent when they did not. Those notes explain deviations the numbers alone cannot — read them before judging a session. Use when the user asks about a specific session.
delete_workoutPermanently delete a logged workout. This cannot be undone. The workout's analytics data will also be removed.
create_workoutRecord one or more COMPLETED workouts. Use this to log a session the user has just finished, or to import training history from another app. Maximum 25 workouts per call. Each workout needs: client_ref (a stable key from your source data, e.g. "strong-row-412" or "session-2024-03-11"), end_time, and exercises with their sets. Every exercise_id must exist in the catalog - use search_exercises to find them. An unrecognised exercise_id rejects that workout and returns up to three suggested matches, so correct the id and resubmit that item. client_ref makes calls safe to repeat: the same client_ref always maps to the same workout, so a retry after a timeout updates rather than duplicating. Use the SAME client_ref when resubmitting a failed item. Partial success is normal. Read results[] for the per-item outcome and next_action for what to do next; a failed item never prevents the others from being written. IMPORTING HISTORY: send workouts in chunks of 25 and set is_final=true on the LAST chunk only. Workouts older than 7 days are stored as data and deliberately do NOT generate insights, recommendations, or changes to current training state - analysing an old session would overwrite the athlete's present-day training picture. Say so rather than promising insights that will not appear. A recent session (within 7 days) does update their training state. For very large migrations, be honest about the cost: transcribing several hundred workouts takes a long time and risks per-field errors. Ask whether the full history is wanted, or only recent months.
update_workoutCorrect a workout that is already recorded - fix a weight, add a note, adjust reps. Supply only the fields to change: anything omitted is left exactly as it is. Call get_workout first to see the current state. Do NOT build an exercises array from list_workouts - that returns set COUNTS, not sets, and a replacement assembled from it would write zeroes over what the athlete logged. A replacement that would drop most of the logged sets is rejected outright. To change the exercise list, pass the COMPLETE exercises array - it replaces the existing list wholesale, so omitting an exercise removes it. Omit the exercises field entirely to leave every exercise untouched. Two things survive a replacement you do not mention: leave the sets field off an exercise and its existing sets are kept (so you can rename or reorder without resending set data), and leave the notes field off and the athlete's own note is kept - pass null to clear it. Idempotent on workout_id: repeating the same call is safe. To remove a workout instead, use delete_workout.
search_exercisesSearch the exercise catalog by name, muscle group, or keyword. Returns lean records: exercise ID, name, category, equipment, and `primary_muscle_groups` — the groups the lift TRAINS, which is what to choose on. Note this is narrower than "involves": a shoulder press works the chest but is not a chest exercise, and only `fields: full` (via getExercise) carries the full involvement list. Use when building or modifying templates, or when acting on a recommendation that names a muscle group. Natural-language queries work ("chest exercises", "best back movements", "barbell row"): filler words are ignored and results are ranked by why they matched, with lifts that train the named group above lifts that merely involve it. A muscle-group query spreads results across distinct movements rather than returning many equipment variants of one; naming a movement ("chest dip") keeps its variants together. Exercise names are returned in the user's selected language when a translation exists (English otherwise); override with the optional `locale`.
get_strength_climbGet the user's Strength Climb — the headline strength-progress signal shown at the top of the Intelligence tab, and the answer to "am I getting stronger?" over the 8-WEEK window (every state here carries window_weeks: 8). The per-lift strength_state on get_exercise_progress / list_trained_exercises is classified over 6 weeks and can legitimately differ for the same lift; when they disagree, the climb (8 wk) is the strength answer and the 6-week state is the recent-trend answer — say which window you are quoting. Returns median_pct (median % gain across qualifying — progressing — lifts over the 8-week window) with median_n (how many lifts that median is over: for a rotating exercise pool this is often small, sometimes 1, so a high median_pct with median_n=1 is a single-lift result, not "typical across lifts"), climbing_count / holding_count / stalling_count / deloading_count / building_count (a partition of total_count), leader_name (top mover), median_series (the climb line), and constituents (per-lift name + indexed_pct + state + series). Prefer this over the deprecated composite training_score. If empty, the user has no qualifying progressing lifts yet — fall back to get_exercise_progress per lift.
get_training_insightsCAUTION: training_score / score_breakdown / score_drivers / rolling_score are DEPRECATED — do not use them; lead with strength_climb + training_context + muscle_volume. muscle_volume/volume_zone are CALENDAR-WEEK-TO-DATE, so mid-week most groups read below_mev — check partial_week / days_into_week before calling a group under MEV. Get AI-generated training insights and latest weekly review. Insights include: post-workout observations, guardrail alerts (junk volume, neglected muscles, overreach), volume flags. Weekly review includes: strength_climb (the 8-week strength-progress signal — see get_strength_climb; its all_lifts[].state is classified over window_weeks 8), training_context (score_basis, volume_completion, sessions adherence, fatigue, trained_muscle_count — the honest productivity signals), muscle_volume (per-group weekly_hard_sets + volume_zone + MEV/MAV/MRV, reproducing "Muscles · this week"), fatigue status (ACWR), muscle balance, exercise trends, periodization assessment, and top_primary_movers (each mover's state is the 6-week e1rm_trends one, dated by its window_weeks — it can differ from the same lift's 8-week climb state; quote the window with the state). Lead with strength_climb + training_context + muscle_volume. muscle_volume/volume_zone are CALENDAR-WEEK-TO-DATE — mid-week they read low (below_mev) for most groups; check the top-level partial_week / days_into_week flags and do not call a group below MEV on a partial week. NOTE: training_score / score_breakdown / score_drivers / rolling_score are DEPRECATED (being removed) — do not build on them. Use for retrospective questions (the latest review may be the current in-progress week). For muscle-specific questions, use get_muscle_state. For recommendations, use get_recommendations.
get_muscle_stateCAUTION: MEV/MAV/MRV landmarks are defined ONLY against weekly_hard_sets — weekly_effective_volume is a SECONDARY fractional metric, NOT set-based; never compare it to mev/mav/mrv_target or call it "sets". Trust the precomputed volume_zone; do not reconstruct it. Get TIE's synthesized assessment for a muscle group: weekly_hard_sets (the set count shown on the Intelligence tab, and the ONLY number the MEV/MAV/MRV landmarks are defined in), weekly_effective_volume (a SECONDARY metric that includes fractional synergist contribution — NOT set-based; never compare it to mev/mav/mrv_target or call it "sets"), volume_zone (below_mev/mev/mav/mrv/above_mrv) with the user's mev/mav/mrv_target set counts, fatigue status (ACWR) and acwr_trend, plateau detection (plateau_weeks), e1RM trends (e1rm_trends: per-lift state over the window in its window_weeks, 6), current periodization phase, exercise rotation status, strength_climb (per-muscle indexed strength progress over window_weeks 8: median_pct, constituents, all_lifts — its per-lift state can differ from e1rm_trends for the same lift because the windows differ; quote the window with the state), and AI reasoning. Use volume_zone (precomputed against weekly_hard_sets — trust it, don't reconstruct) to say whether a muscle is below MEV / optimal / past MRV, and strength_climb to say whether the muscle's lifts are getting stronger. Use for muscle-specific questions. For exercise-specific trends, use get_exercise_progress.
get_recommendationsGet pending training recommendations from TIE. Returns actionable suggestions with rationale and confidence. Use review_recommendation to accept or reject.
review_recommendationAccept, reject, or revert a training recommendation. Always confirm with the user before calling — template mutations are immediate.
get_muscle_group_progressGet weekly progress series for a muscle group. Each weekly point carries sets and hard_sets (primary-mover sets only; hard = RIR≤3), volume_primary (tonnage of those primary sets), volume (tonnage of EVERY set that involves the group, unweighted — a row counts at full weight under chest here), effective_volume (contribution-weighted tonnage) and e1rm_max (best primary-mover e1RM that week); counting_basis on the payload names each basis, and top_exercises rows say role: primary | synergist. Quote volume_primary or effective_volume as "how much the athlete trained this muscle", never volume. flags.plateau is the 4-week e1rm_max rule stated in flags.basis; state.plateau_status is the analyst's judgement and wins when they disagree. For TIE's interpreted assessment (fatigue, plateau, effective volume), use get_muscle_state instead. This tool returns raw time-series data useful for charting and external analysis.
get_exercise_progressGet 8-week progress for a specific exercise: weekly e1RM trend, personal records, plateau detection, last session details, and strength_state — the trend STATE (progressing / holding / stalling / deloading / insufficient_data) classified over the 6-week window stated in its window_weeks, the same signal shown on the iOS lift detail page. Prefer strength_state over raw weekly points when judging whether a lift is improving. For the per-lift % gain ("+59%") and the 8-week state, use get_strength_climb — its constituents carry indexed_pct and their own window_weeks; the two states can differ for one lift because the windows differ, so quote the window with the state. Use when the user asks about a specific lift (e.g., "am I getting stronger on bench press?" or "have I plateaued on squats?"). Pass EITHER exercise_id (exact — from search_exercises or a prior resolution.candidates) OR exercise (a name, fuzzy-matched against the user's history). Prefer exercise_id when you have it: a fuzzy NAME can match several variants the user trains (e.g. "Incline Bench Press" → dumbbell vs machine), and the response's `resolution` block reports which id was chosen, whether it was `ambiguous`, and the `candidates` — if ambiguous, re-query with the exact exercise_id you meant. For muscle-group-level interpreted analysis (fatigue, plateau, effective volume), use get_muscle_state. For raw time-series data, use get_muscle_group_progress.
query_setsQuery raw set-level training data with flexible filters: by exercise name (fuzzy), muscle group, specific muscle, or exercise IDs. Returns individual set records with weight, reps, RIR, date, and exercise info. Use for custom analysis, data export, or when you need granular training data that the higher-level tools don't cover. Max 200 results PER PAGE — when the response has truncated=true, pass its next_cursor back as `cursor` (keeping every other argument identical, including sort) to read the next page. PROVENANCE: filtering by muscle_group or muscle matches ANY involvement (primary mover OR synergist), not just direct work — the response declares meta.counting_basis and annotates each row with contribution (0-1), plus is_primary on the muscle_group path; for a landmark-comparable count keep is_primary=true rows. Filtering by exercise_name returns meta.resolution naming the exercise_id(s) actually read, whether the name was ambiguous, and the runner-up candidates — check it before trusting a name-filtered result, and re-query by exercise_ids for an exact lift.
list_trained_exercisesEnumerate the exercises the user actually trains, from their logged set history — the fastest way to orient before per-lift analysis (saves the 10+ sequential get_exercise_progress calls it used to take to survey the user). For each exercise returns: the exact exercise_id (pass it to get_exercise_progress to avoid name-match ambiguity), session_count, weeks_of_data, set_count, last_performed + days_since_last, is_stale, typical_reps, e1rm_coverage, strength_state (the trend state — progressing / holding / stalling / deloading / insufficient_data — classified over the window in strength_state_window_weeks (6), read from the SAME source as get_exercise_progress, so it never contradicts that tool; get_strength_climb classifies over 8 weeks and may differ), and can_trend (strength_state != insufficient_data) with trend_blockers explaining WHY a lift can't trend yet: insufficient_weeks (<3 distinct weeks), no_e1rm, or no_trend_state (enough raw data but no computed trend — usually variant fragmentation or e1RM coverage; see fragmented_variants). Staleness is a separate axis (is_stale / days_since_last: a hard-trained but old lift can still trend, its trend is just stale). Also returns a data_quality block: overall e1rm_coverage (fraction of working sets with a computed e1RM — typically ~1.0 post-update, so it flags coverage gaps like bodyweight sets, NOT e1RM confidence), fragmented_variants (one movement split across near-duplicate catalog ids, e.g. bicep curl as barbell + cable + dumbbell — the reason a well-trained movement can still read insufficient_data per variant), exercises_cannot_trend_yet (with weeks_of_data + blockers), and stale_trends. USE THIS FIRST to discover exact ids and which lifts have enough data to trend, then call get_exercise_progress(exercise_id) for the specific lifts. The window block reports the scan bound: scan_capped=true means older history exists beyond the scan window, so a lift trained only earlier than window.oldest_set_date may not ap
get_training_statusGet training status overview in one lightweight call: weekly adherence (completed sessions vs goal for each week), next scheduled workout (template name and position in routine), last workout date, days since last workout, and whether the user has an active routine. Use for "what should I do today?", "am I being consistent?", and "when did I last train?" — much lighter than get_training_snapshot.
create_routineCreate a new routine from existing template IDs. A routine defines which workout templates to cycle through and how many times per week to train. Use search_exercises and create_template first if the user needs new templates. The first routine created becomes the active routine automatically.
update_routineUpdate an existing routine: change its name, reorder template IDs, or adjust frequency. Pass only the fields to change. To add/remove templates, pass the full updated template_ids array. Use get_routine first to see current state.
delete_routinePermanently delete a routine. If it was the active routine, the active routine is cleared. This cannot be undone. Templates referenced by the routine are NOT deleted.
set_active_routineSet which routine is the active routine. The active routine determines which workout the user should do next. Use list_routines to see available routines and their IDs.
create_templateCreate a new workout template with exercises and set prescriptions. Each exercise needs an exercise_id (from search_exercises), position (0-based order), and sets with type, reps, weight (kg, null for bodyweight), and RIR. Each exercise also takes an optional coach_note — the per-exercise reasoning or cue, which belongs there rather than crammed into the template description. Omit exercise and set ids on create; the server mints them. After creating, add the template to a routine with create_routine or update_routine.
update_templateUpdate an existing template: change its name, description, or replace its exercise list. When updating exercises, pass the complete exercises array (it replaces the existing list) — including each exercise's coach_note, which is cleared for any exercise that omits it, and each exercise's and set's id from get_template so the element keeps its identity (an element sent without an id is treated as NEW and gets a fresh id). Use get_template first to see the current state.
delete_templatePermanently delete a workout template. Also removes it from any routines that reference it. This cannot be undone.
list_memoriesList the user's memories filtered by category and status. By default lists all memories that currently gate training — both active AND monitoring — so an injury the pipeline is still suppressing on (monitoring = possibly resolved, awaiting user confirmation) is never hidden. Pass an explicit status to narrow (e.g. status='resolved'). Use category='injury' to filter to injury memories specifically.
get_memoryGet full details on a single memory: status_history, suppression_count, last_referenced_at, body_area, severity. Use to inspect a specific memory before calling update_memory_status.
get_recent_suppressionsList recent recommendations that were suppressed because of injury memories. Use to answer 'why didn't my bench press progress?' or to understand which memories are actively gating training. Returns exercise names plus full memory summaries (body_area, severity, status).
update_memory_statusUpdate an injury memory's lifecycle status. Use 'resolved' when the user confirms an injury is fully gone. Use 'monitoring' for ambiguous cases (typically the pipeline auto-transitions). Use 'active' to revert if pain returns. Tagged with source='external_mcp' in the audit trail.
save_injury_memoryReport a new injury or pain. Call this when the user describes physical discomfort that should affect training. body_area must be from the controlled vocabulary (left_shoulder, right_shoulder, lower_back, upper_back, left_knee, right_knee, left_elbow, right_elbow, left_wrist, right_wrist, left_hip, right_hip, chest, neck, calves, abs, plus their bilateral variants). Aliases like 'shoulder_left' are accepted. severity is 'mild' (note only), 'moderate' (suppress progression), or 'severe' (suppress + safety disclaimer).
get_periodization_planGet your current periodization plan: auto-generated or authored (Claude-authored policy). Returns plan structure, phases, policy, and status. Verify with this after set_periodization_plan (confirm source=="authored").
set_periodization_planAuthor a periodization POLICY that steers your EXISTING routine — it sets the progression rule, phase schedule, and deload cadence applied to the exercises/sets already in your routine. It CANNOT define exercises, sets, or weights; use update_template for those. The plan activates immediately (current_week resets to 1) and supersedes the auto-engine until paused. Editing an already-active authored plan requires confirmed:true. Valid muscle groups for per_muscle_overrides: chest, back, shoulders, biceps, triceps, quads, hamstrings, glutes, calves, abs. DELOAD PRECEDENCE: a week is a deload when EITHER the current phase is named "deload" OR the deload_schedule cadence lands on that week — they do not compound; deload magnitude is volume_cut_pct. REP RANGES / INTENSITY come from your existing routine templates, not the policy — the policy steers progression/deload over those. Verify with get_periodization_plan (see next_session) or dry-run first with preview_periodization_plan. Example: {"goal":"hypertrophy","planned_weeks":6,"policy":{"phase_schedule":[{"name":"accumulation","weeks":5},{"name":"deload","weeks":1}],"progression_rule":"double_progression","deload_schedule":{"every_n_weeks":4,"volume_cut_pct":40,"hold_intensity":true}}}.
preview_periodization_planDry-run a plan WITHOUT saving it: validates the policy and — only if valid — returns a preview. If invalid, returns ok:false with errors. Nothing is written.
pause_periodization_planPause an active authored plan and hand control back to the automatic engine. Lossless — your policy is retained for resume; any pending authored recommendations are cleared. The auto-engine rebuilds its own plan next cycle. No-op if no authored plan is active.
resume_periodization_planRe-activate a previously paused authored policy (no need to re-author it). No-op if there is no retained policy.