Skip to main content
Glama

Blocks

by zone.blocks
OverviewDiscussionsAdmin

copy_week

Copy a whole training week onto other weeks, weekday by weekday — Monday's work lands on Monday. from and each entry in to may be ANY date inside the week you mean; the week is taken from it. Day notes travel too, but only onto days that have none. This is the tool for «повтори прошлую неделю», for repeating a base week before it steps up, and for laying the same block out three times — it is one call instead of a dozen plan_workouts items, and it reproduces the week exactly. It ADDS to the target weeks: days that already hold work keep it, so a week you mean to REPLACE has to be emptied first with remove_from_plan, day by day, which the athlete will see you do.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesany date inside each week to copy TO
whyNoONE line, in the athlete's language: WHY this change — the reason from the conversation ("travel Thu-Fri, long ride moved to Sat", "deload after 3 build weeks"). The athlete's other assistant surface reads it later; without it, it sees only that the plan changed. No health details beyond what the plan needs.
fromYesany date inside the week to copy FROM
withDayNotesNocarry the source week's day notes as well (default true; they only land on days that have no note)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / why
      Added value: +{
+  "description": "ONE line, in the athlete's language: WHY this change — the reason from the conversation (\"travel Thu-Fri, long ride moved to Sat\", \"deload after 3 build weeks\"). The athlete's other assistant surface reads it later; without it, it sees only that the plan changed. No health details beyond what the plan needs.",
+  "maxLength": 200,
+  "type": "string"
+}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only say it is not read-only and not destructive; the description adds the crucial trait that it ADDS rather than replaces (days with existing work keep it), that day notes travel only onto empty days, and that replacing requires an explicit prior removal the athlete will see. This is significant behavioral context beyond structured fields.

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-loads the core action in the first sentence, then layers usage and the add-not-replace caveat in a deliberate order. Slightly long, but every sentence carries information an agent needs; nothing is redundant.

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 4-parameter mutation tool with no output schema, the description supplies the safety-critical caveats (additive behavior, note-transfer rules, replace requires emptying first) that an agent needs to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters, including the date-in-week and withDayNotes semantics. The description reinforces the 'any date inside the week' behavior and weekday mapping but does not cover the `why` parameter or add much beyond the schema. Baseline 3 is appropriate.

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 — copy a whole training week onto other weeks — and immediately names the mapping semantics (weekday by weekday). It clearly distinguishes itself from siblings like plan_workouts and copy_workouts by positioning itself as the atomic one-call alternative.

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 gives when-to-use scenarios in the athlete's own language, and — critically — states when NOT to use it for replacement, naming remove_from_plan as the required alternative. This is textbook when/when-not/alternative guidance.

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

All Blocks 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