Blocks

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 «повтори прошлую неделю» and for repeating a base week next week — one call instead of a dozen plan_workouts items, and it reproduces the week exactly. Sessions are written two weeks out; weeks beyond hold their block's target, not a copy. 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

Name	Required	Description
`to`	Yes	any date inside each week to copy TO
`why`	No	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.
`from`	Yes	any date inside the week to copy FROM
`withDayNotes`	No	carry 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.

Changed1 schema field changedSep 29, 2026

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"
+}

First observedSep 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare non-read-only, non-destructive, closed-world; the description adds the substantive traits: it ADDS rather than replaces, day notes land only on days that have none, sessions are written two weeks out and beyond that the block target holds instead of a copy. Those are exactly the behaviors an agent would otherwise get wrong, and they are consistent with 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.

Conciseness4/5

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

Front-loaded with the core action, then constraints, then the replacement caveat — a sensible order and no filler sentences. A few clauses are denser than needed ("and it reproduces the week exactly" restates the weekday-mapping point), but every sentence still carries usable information.

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 4-parameter mutation tool with no output schema, it covers source/target semantics, additive behavior, note handling, horizon limits, and the cleanup prerequisite. The only gap is that it never says what the call returns or how the agent can verify the copy (how many sessions landed where).

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 the baseline is 3, and the description still earns credit by clarifying that `from` and every `to` entry can be ANY date inside the target week and the week is derived from it, plus the note-carry semantics that the schema only partly states. The `why` parameter is left entirely to the schema, so it is not a full 5.

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, weekday by weekday") and immediately disambiguates scope with the Monday-to-Monday rule. It also distinguishes itself from the nearest siblings by naming plan_workouts and remove_from_plan and describing the different outcomes.

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 says when to use it («повтори прошлую неделю», repeating a base week) versus when to use alternatives — "one call instead of a dozen plan_workouts items" — and gives the precise when-not-plus-remediation case: to replace a week, empty it first with remove_from_plan, day by day.

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

All Blocks tools Inspect

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

Need Help?