Skip to main content
Glama

set_training_blocks

Destructive

Lay out the season in TRAINING BLOCKS — the coloured bars over the weeks in the calendar's Season view. A CARD: nothing is written until the athlete applies it. Each block is whole weeks (start a Monday, end a Sunday, at most 16 weeks) with ONE purpose: name in the athlete's language says what it is for («МПК: поднять потолок», «Подводка к Jais»), kind is its phase, stimulus the zone it is built on (it colours the block: vo2, threshold, tempo, endurance, recovery), lever the thesis in one sentence, goal how you will know it worked: 2–4 short lines, one metric each, in words a person says aloud — what we want by the block's end and where it stands now («Порог на вело: 2×20′ на 245 Вт с RPE до 7 — сейчас 36′ в работе»; a race block by its RPE, a taper by the race-morning check-in); no dates for every step and no scales in brackets — the steps live in the week targets. The block card shows it; your reviews add progress under it (add_block_progress). Give the weeks beyond the next two a TARGET instead of sessions: weeks: [{ monday, hours: [low, high], keys: [each key session's purpose and step — the block's ladder] }]. The card replaces every block of theirs that overlaps its span, so send the whole chain you mean for those dates. Build from the A race backwards; a taper before it, a recovery or transition after. With an A race, send its PREPARATION BRIEF in the same card — prep; the blocks follow from it. To change only the brief, send prep without blocks. Call get_season first.

Input Schema

NameRequiredDescriptionDefault
prepNothe preparation brief on the A race, plain text in the athlete's language, no markdown
blocksNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / blocks / items / properties / weeks / items / properties / hours / description
      Added value: +"[low, high] hours"
    • changedInput schema / properties / blocks / items / properties / weeks / items / properties / hours / items
      Previous value: -[
      -  {
      -    "maximum": 40,
      -    "minimum": 0,
      -    "type": "number"
      -  },
      -  {
      -    "maximum": 40,
      -    "minimum": 0,
      -    "type": "number"
      -  }
      -]New value: +{
      +  "maximum": 40,
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / blocks / items / properties / weeks / items / properties / hours / maxItems
      Added value: +2
    • addedInput schema / properties / blocks / items / properties / weeks / items / properties / hours / minItems
      Added value: +2
  2. Changed2 schema fields changed
    • addedInput schema / properties / prep / properties / build / items / properties / metric
      Added value: +{
      +  "description": "when this quality IS a profile number: the app shows it from the profile, leave now out",
      +  "enum": [
      +    "ftp",
      +    "wkg",
      +    "thr_pace",
      +    "css",
      +    "weight"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / prep / properties / build / items / properties / now / description
      Previous value: -"their number with its date, ≤70; left out when unmeasured"New value: +"any other number, with its date, ≤70; left out when unmeasured"
  3. Changed12 schema fields changed
    • removedInput schema / properties / blocks / minItems
      Removed value: -1
    • changedInput schema / properties / prep / description
      Previous value: -"the preparation brief on the A race: demands, develop, resources, strategy required, constraints if any"New value: +"the preparation brief on the A race, plain text in the athlete's language, no markdown"
    • addedInput schema / properties / prep / properties / approach
      Added value: +{
      +  "description": "decisions that shape the plan, ≤280: never a copy of the profile, no fuelling or pacing",
      +  "type": "string"
      +}
    • addedInput schema / properties / prep / properties / build
      Added value: +{
      +  "description": "1–3 qualities, the most important first",
      +  "items": {
      +    "properties": {
      +      "goal": {
      +        "description": "what the race needs, ≤80",
      +        "type": "string"
      +      },
      +      "name": {
      +        "description": "the quality, ≤32",
      +        "type": "string"
      +      },
      +      "now": {
      +        "description": "their number with its date, ≤70; left out when unmeasured",
      +        "type": "string"
      +      },
      +      "why": {
      +        "description": "why it ranks here, or the test that gives the missing number, ≤140",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "goal"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / prep / properties / constraints
      Removed value: -{
      -  "description": "constraints: 1–3 short lines, the athlete's language",
      -  "maxLength": 700,
      -  "type": "string"
      -}
    • removedInput schema / properties / prep / properties / demands
      Removed value: -{
      -  "description": "the race: 1–3 short lines, the athlete's language",
      -  "maxLength": 700,
      -  "type": "string"
      -}
    • removedInput schema / properties / prep / properties / develop
      Removed value: -{
      -  "description": "to develop: 1–3 short lines, the athlete's language",
      -  "maxLength": 700,
      -  "type": "string"
      -}
    • addedInput schema / properties / prep / properties / race
      Added value: +{
      +  "description": "its length, terrain and what decides it, ≤240",
      +  "type": "string"
      +}
    • removedInput schema / properties / prep / properties / resources
      Removed value: -{
      -  "description": "resources: 1–3 short lines, the athlete's language",
      -  "maxLength": 700,
      -  "type": "string"
      -}
    • removedInput schema / properties / prep / properties / strategy
      Removed value: -{
      -  "description": "strategy: 1–3 short lines, the athlete's language",
      -  "maxLength": 700,
      -  "type": "string"
      -}
    • changedInput schema / properties / prep / required
      Previous value: -[
      -  "eventId"
      -]New value: +[
      +  "eventId",
      +  "race",
      +  "build"
      +]
    • removedInput schema / required
      Removed value: -[
      -  "blocks"
      -]
  4. Changed2 schema fields changed
    • changedInput schema / properties / blocks / items / properties / goal / description
      Previous value: -"how we will know: the block's metrics, from → target, the athlete's language; omitted on a block re-laid on the same Monday = its goal is kept"New value: +"how we will know: 2–4 short lines (a line break between), one metric each, plain words, the athlete's language; omitted on a block re-laid on the same Monday = its goal is kept"
    • addedInput schema / properties / prep
      Added value: +{
      +  "description": "the preparation brief on the A race: demands, develop, resources, strategy required, constraints if any",
      +  "properties": {
      +    "constraints": {
      +      "description": "constraints: 1–3 short lines, the athlete's language",
      +      "maxLength": 700,
      +      "type": "string"
      +    },
      +    "demands": {
      +      "description": "the race: 1–3 short lines, the athlete's language",
      +      "maxLength": 700,
      +      "type": "string"
      +    },
      +    "develop": {
      +      "description": "to develop: 1–3 short lines, the athlete's language",
      +      "maxLength": 700,
      +      "type": "string"
      +    },
      +    "eventId": {
      +      "description": "the A race's id (list_events / next_events)",
      +      "type": "string"
      +    },
      +    "resources": {
      +      "description": "resources: 1–3 short lines, the athlete's language",
      +      "maxLength": 700,
      +      "type": "string"
      +    },
      +    "strategy": {
      +      "description": "strategy: 1–3 short lines, the athlete's language",
      +      "maxLength": 700,
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "eventId"
      +  ],
      +  "type": "object"
      +}
  5. Changed2 schema fields changed
    • addedInput schema / properties / blocks / items / properties / goal
      Added value: +{
      +  "description": "how we will know: the block's metrics, from → target, the athlete's language; omitted on a block re-laid on the same Monday = its goal is kept",
      +  "maxLength": 400,
      +  "type": "string"
      +}
    • changedInput schema / properties / blocks / items / properties / lever / description
      Previous value: -"the thesis in one sentence: what this block moves and how we will know"New value: +"the thesis in one sentence: what this block moves and why"
  6. Changed1 schema field changed
    • changedInput schema / properties / blocks / items / properties / weeks / items / properties / keys / description
      Previous value: -"what each key session of that week is for"New value: +"each key session's purpose and its step that week («Порог: 2×20′ @245»)"
  7. Added

TDQS

A4.6/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known; however the description adds valuable non-obvious behavior: the card writes nothing until applied, and it replaces every overlapping block of the athlete's, requiring the whole chain to be resent. These are meaningful disclosures beyond the annotations, though return/confirmation behavior and the 12-block cap are not covered.

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

Conciseness5/5

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

Dense but front-loaded: the card metaphor and the core concept come first, then field semantics, then sequencing rules. Every sentence conveys a constraint or format rule; the long parenthetical goal examples earn their place by teaching the required output style.

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 two-parameter but heavily nested mutation tool with no output schema, the description provides the mental model (card applied later), replacement semantics, temporal scoping (whole weeks, 16-week max), and the prep-brief coupling. An agent has enough to construct a valid card without guessing.

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

Parameters5/5

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

With only 50% schema description coverage and deeply nested objects, the description carries the load well: it explains `name`, `kind`, `stimulus` (and that stimulus colours the block via enumerated zones), `lever`, and the `goal` format with concrete examples. It also explains the `weeks` target structure (monday, hours range, keys as ladder steps) and when to use targets versus sessions.

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: laying out the season in training blocks represented as coloured bars in Season view. It clearly distinguishes the tool from session-planning siblings by naming what a block is (whole weeks, one purpose) versus week targets and sessions.

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?

Explicit sequencing: 'Call get_season first', build from the A race backwards, add a taper before and recovery/transition after. It also gives mode selection rules — send `prep` with `blocks` for a full card, or `prep` alone to change only the brief — which is exactly the when/when-not guidance an agent needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources