Skip to main content
Glama

Povver — Strength Training

by ai.povver
OverviewDiscussionsAdmin

Set Periodization Plan

set_periodization_plan
Idempotent

Author 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. PROGRESSION is double progression whatever progression_rule says: reps climb each session you hit your target, the weight moves at the top of the rep range. REP RANGES come from the plan goal and the exercise type (a template prescribing fewer reps lowers its floor); set prescriptions and INTENSITY come from your existing routine templates. 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}}}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
planYesAn authored periodization plan. Exercises and sets are NOT defined here — the policy steers your existing routine.
confirmedNoSet true only after the user confirmed an edit to an already-active plan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / plan / properties / policy / properties / per_muscle_overrides / additionalProperties / properties / progression_rule / description
      Previous value: -"Override the global progression_rule for this muscle only."New value: +"Kept for compatibility; every rule runs as double progression."
    • changedInput schema / properties / plan / properties / policy / properties / progression_params / description
      Previous value: -"Optional progression-rule-specific parameters. The policy steers progression rules; rep ranges and set prescriptions stay in your templates."New value: +"Optional progression parameters. Set prescriptions stay in your templates; the rep range comes from the plan goal and the exercise type."
    • changedInput schema / properties / plan / properties / policy / properties / progression_params / properties / increment_kg / description
      Previous value: -"For double_progression/linear_load: kg to add when reps max out (default 2.5, max 5). Rep ranges come from your routine templates, not the policy."New value: +"Caps the extra increments one progression may add, in kg (max 5); the first increment on the lift’s own load grid is always allowed. Unset: the engine sizes the step from the reps you had left, extra increments up to 10% of the load (5% on isolation lifts)."
    • changedInput schema / properties / plan / properties / policy / properties / progression_rule / description
      Previous value: -"How load progresses week-to-week: double_progression (reps then weight), linear_load (add kg per week), rir_autoreg (autoreg by RIR)."New value: +"Kept for compatibility: since 2026-09-27 every value runs as double progression. Reps climb each session you hit your target at the target RIR; the weight moves the session you reach the top of the rep range with reps to spare, by a step sized from those spare reps."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds substantial behavioral context beyond them: immediate activation (current_week resets to 1), supersession of the auto-engine until paused, the confirmed:true gate for active-plan edits, deload precedence semantics, and that progression_rule values all collapse to double progression. This is unusually rich disclosure.

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?

Front-loaded with purpose before the exclusions and behavioral rules, and every sentence is relevant rather than boilerplate. It is long and dense, but the length is carrying real semantic load (deload precedence, progression fallback, muscle group list) rather than padding.

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?

For a deeply nested authoring tool with no output schema, the description covers activation side effects, the confirmation requirement, deload conflict resolution, progression fallback behavior, and how to verify the result. Nothing needed to invoke it correctly appears missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds value the schema lacks: the enumerated valid muscle groups for per_muscle_overrides (chest, back, shoulders, ...), progression/deload semantics, and a worked example JSON. It also clarifies that rep ranges derive from goal and exercise type rather than being set here.

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?

States a specific verb and resource ('author a periodization POLICY that steers your EXISTING routine') and immediately bounds what it does not do ('CANNOT define exercises, sets, or weights'). An agent can distinguish it from update_template, create_template, and get_periodization_plan purely from the text.

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 routes the agent: use update_template to define exercises/sets/weights, get_periodization_plan to verify, preview_periodization_plan to dry-run, and confirmed:true only when editing an already-active authored plan. When-to-use and when-not-to-use are both present.

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

All Povver — Strength Training toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources