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.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | An authored periodization plan. Exercises and sets are NOT defined here — the policy steers your existing routine. |
Changes observed during successful MCP inspections.
Input schema / properties / plan / properties / policy / properties / per_muscle_overrides / additionalProperties / properties / progression_rule / descriptionPrevious value: -"Override the global progression_rule for this muscle only."New value: +"Kept for compatibility; every rule runs as double progression."Input schema / properties / plan / properties / policy / properties / progression_params / descriptionPrevious 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."Input schema / properties / plan / properties / policy / properties / progression_params / properties / increment_kg / descriptionPrevious 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)."Input schema / properties / plan / properties / policy / properties / progression_rule / descriptionPrevious 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."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark it readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes further and discloses the validity-gated behavior: a preview is returned only if valid, otherwise ok:false with errors, and nothing is persisted. It does not describe what the preview contains, but the behavioral contract is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact clauses, front-loaded with the core action (dry-run without saving) and the outcome branches. No filler; every sentence carries signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-shape burden and does so partially (ok:false with errors, preview only when valid). The deep nested policy semantics are fully documented in the schema, so this is adequate for a validation tool, though the preview payload shape is not described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single nested 'plan' parameter with 100% schema description coverage, so the schema already documents goal, policy, phases, and deload rules. The description adds no additional parameter meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Dry-run a plan') plus the exact scope ('WITHOUT saving it', validates, returns a preview). This distinguishes it cleanly from the save-side sibling set_periodization_plan without needing to name it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Dry-run ... WITHOUT saving it' framing tells the agent this is the pre-flight/validation step rather than committing a plan. There are no explicit exclusions or a named alternative, but the context for use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.