Copy scheduled workouts from a date range to new dates shifted by a fixed number of days, adding them as new library workouts. Preview first or apply directly.
Preview or copy all scheduled workouts from one date range to dates shifted by a fixed number of days. Copies are new library workouts.
| Name | Required | Description | Default |
|---|---|---|---|
| days | Yes | ||
| apply | No | ||
| endDate | Yes | ||
| startDate | Yes | ||
| nameSuffix | No |
Changes observed during successful MCP inspections.
v2.2.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavior beyond the annotations: preview mode is hinted by 'Preview or copy', and 'Copies are new library workouts' explains the positive outcome and implies the original scheduled workouts are not altered. This especially helps since readOnlyHint=false but destructiveHint=false.
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?
Two focused sentences, no filler, with the core action front-loaded and a clarifying statement about copies as new library workouts. It is appropriately concise for the level of information provided.
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?
The definition is too sparse for a 5-parameter tool with no output schema. It omits how apply controls preview vs. actual copy, what nameSuffix does, expected date formats, and how conflicts or shifted dates are handled. An agent would need to guess or inspect other sources to invoke it correctly.
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?
Schema description coverage is 0%, so the description must compensate, but it only explains 'date range' and 'days shifted'. It does not explain the format or purpose of startDate, endDate, apply, or nameSuffix, leaving most parameters underspecified.
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?
The description states a specific operation—copy scheduled workouts from one date range to shifted dates—and clarifies that copies become new library workouts. This clearly differentiates it from sibling tools like shift_calendar_range or move_scheduled_workout.
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 context is clear enough to infer it should be used when duplicating workouts across dates, but it does not explicitly state when to choose this tool over alternatives like shift_calendar_range, duplicate_workout, or move_scheduled_workout. There are no explicit exclusions or alternative-routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.