Skip to main content
Glama

write_rotation

Destructive

Set a workout plan in rotation mode so routines run in turn (A → B → C → A) instead of on fixed weekdays. Optionally adopt a running planner queue as your own.

Instructions

Set the rotation: the routines trained in turn (A → B → C → A …), not tied to weekdays; the next session is the first one of the round not done yet, on whatever day is trained next. Switches the plan to rotation mode. Editing a running rotation keeps the round's progress (done is by routine since the round began), clears date pins of routines taken out, and starts the next round when the edit leaves the current one complete. When a round completes, logging its last workout starts the next round the day after. Weekday routines stay and count on top of the loop. A planner's queue (written by write_session_queue or another app) shows as "Externally managed" in the app: the app does not refill it, and the user can adopt it as their own rotation. adopt: true takes such a queue over as the user's own rotation. openGym merges settings and the plan one setting and one day at a time: only a device that changes the same setting or day later, before it syncs, keeps its own value.

Input Schema

NameRequiredDescriptionDefault
adoptNoTake over a planner's queue that is running now (default false: refused)
routineIdsYesThe routines in order, each once

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, yet the description still adds substantial behavior: edits preserve round progress, clear date pins of removed routines, and may start the next round; a completed round starts the day after the last workout; weekday routines count on top of the loop; externally managed queues are not refilled; adopt:true overrides a queue; and openGym merges settings one at a time.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, but the body is a run-on wall of clauses, and the final openGym sync-conflict sentence is tangential to invoking this tool. For an agent selecting a tool, this is heavier than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation with two parameters and no output schema, the description covers most of what an agent needs: edit semantics, round lifecycle, queue handling, and adoption. It stops short of stating permissions or confirming return behavior, but nothing essential to correct invocation is obviously 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 both parameters are already documented inline. The description goes further by explaining why adopt exists (taking over a planner's running queue and the "Externally managed" state) and that routineIds are ordered and each used once, adding meaning beyond the raw schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a specific verb and resource: "Set the rotation: the routines trained in turn (A → B → C → A …), not tied to weekdays." It also implicitly separates this from weekday/schedule-mode tools. However, the core purpose is quickly buried under a dense block of behavioral semantics, and the closest sibling write_rotation_round is never named.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: "Switches the plan to rotation mode" and the write_session_queue / adopt remarks hint at context, but there is no explicit "use this when X, not Y" guidance or stated prerequisites. An agent must infer when rotation mode is the right choice versus write_week_plan or write_schedule_mode.

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