Skip to main content
Glama

Propose a workout adjustment

propose_workout_adjustment
Idempotent

Propose a change to one scheduled workout's load (lighter, rest, an easy rebuild) for review. For changes across several workouts or weeks, propose_plan_revision fits. Propose-only: it records a review_pending adjustment and changes no plan until a reviewer approves it in NexRex. A coach's proposal goes to that coach's review queue; an athlete's proposal for themself goes to their assigned coach, or, with no coach, to the athlete's own pending adjustments. plan_instance_id must be one of the athlete's own plans. A strength workout with a structured session takes its duration from that session, so its target_duration_in_seconds is not adjustable. A repeated proposal for the same workout returns status deduped. Workout reads return content_blocks as rows whose columns content_block_fields names (an interval's blocks column holds its nested steps as rows in the same columns), and a session shared by several rows as session_ref into session_definitions. As arguments, content_blocks is a list of block objects and session a session object.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "athlete_id": "<athlete_id>",
      "plan_instance_id": "<plan_instance_id>",
      "workout_id": "<workout_id>",
      "recommendation_kind": "<recommendation_kind>",
      "changes": "<changes>",
      "reason": "<reason>",
      "weekly_objective": "<weekly_objective>",
      "minimum_change_rationale": "<minimum_change_rationale>",
      "goal_impact": "<goal_impact>"
    },
    "name": "propose_workout_adjustment"
  }
}

Input Schema

NameRequiredDescriptionDefault
reasonYesWhy the workout should change.
changesYesNew values for allowlisted workout fields.
athlete_idYesThe athlete's user id: get_current_user's athlete_id for the connected account, or an id from get_coach_athletes or find_athlete.
workout_idYesThe scheduled workout's id from get_week_workouts.
goal_impactYesHow the change affects the athlete's goal or race.
plan_instance_idYesThe athlete's plan_instance_id from get_week_workouts.
weekly_objectiveYesWhat this week of training is meant to achieve.
recommendation_kindYesreduce: lighter, with a positive smaller target; rest: skip it, no numeric target; easy_rebuild: a small positive easy target after missed sessions; keep: record that the workout stays as planned, no changes.
minimum_change_rationaleYesWhy this is the smallest change that serves the athlete.

Output Schema

NameRequiredDescriptionDefault
errorNo
reasonNo
statusNo
messageNo
privacyNoPresent when the athlete's settings withhold data.
coach_idNo
proposalNo
warningsNo
changesetNo
next_stepNoWhat can be done next, for example after a failure.
retryableNo
athlete_idNo
workout_idNo
next_cursorNoReads the next page; null on the last page.
proposal_idNo
reason_codeNo
total_weeksNo
safety_classNo
user_contentNoFields in this result that people wrote.
adjustment_idNo
weeks_returnedNo
applied_changesNo
review_requiredNo
plan_instance_idNo
superseded_countNo
truncated_fieldsNoLists cut to fit one response: rows returned and total.
generated_contentNoFields in this result that NexRex's AI wrote.
session_definitionsNoSessions that several rows of this result share by session_ref.
content_block_fieldsNoColumn names of every content_blocks row, nested blocks rows included.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / $defs / Activity / properties / content_blocks / anyOf
      Previous value: -[
      -  {
      -    "items": {
      -      "items": {
      -        "anyOf": [
      -          {
      -            "type": "string"
      -          },
      -          {
      -            "type": "integer"
      -          },
      -          {
      -            "type": "number"
      -          },
      -          {
      -            "type": "boolean"
      -          },
      -          {
      -            "items": {
      -              "anyOf": [
      -                {
      -                  "type": "string"
      -                },
      -                {
      -                  "type": "integer"
      -                },
      -                {
      -                  "type": "number"
      -                },
      -                {
      -                  "type": "boolean"
      -                },
      -                {
      -                  "type": "null"
      -                }
      -              ]
      -            },
      -            "type": "array"
      -          },
      -          {
      -            "$ref": "#/$defs/LocalizedText"
      -          },
      -          {
      -            "type": "null"
      -          }
      -        ]
      -      },
      -      "type": "array"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "items": {
      +      "items": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "type": "integer"
      +          },
      +          {
      +            "type": "number"
      +          },
      +          {
      +            "type": "boolean"
      +          },
      +          {
      +            "items": {
      +              "anyOf": [
      +                {
      +                  "type": "string"
      +                },
      +                {
      +                  "type": "integer"
      +                },
      +                {
      +                  "type": "number"
      +                },
      +                {
      +                  "type": "boolean"
      +                },
      +                {
      +                  "type": "null"
      +                }
      +              ]
      +            },
      +            "type": "array"
      +          },
      +          {
      +            "$ref": "#/$defs/LocalizedText"
      +          },
      +          {
      +            "items": {
      +              "type": "array"
      +            },
      +            "type": "array"
      +          },
      +          {
      +            "type": "null"
      +          }
      +        ]
      +      },
      +      "type": "array"
      +    },
      +    "type": "array"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
    • changedOutput schema / $defs / Activity / properties / content_blocks / description
      Previous value: -"Interval rows; each row's values follow content_block_fields."New value: +"Workout steps as rows whose values follow content_block_fields; an interval's blocks value is its nested steps as rows in the same columns."
    • changedOutput schema / properties / content_block_fields / description
      Previous value: -"Column names of every content_blocks row."New value: +"Column names of every content_blocks row, nested blocks rows included."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: propose-only semantics (records a review_pending adjustment, changes no plan until approved), review-queue routing rules, dedupe behavior returning status 'deduped', and the exception that structured strength sessions fix duration. This gives the agent the full write/approval lifecycle that readOnlyHint=false and idempotentHint=true only hint at.

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 purpose, then alternative, then propose-only semantics, then constraints — a sensible order. The closing sentences on content_blocks/session row-vs-object representation are dense and slightly tangential, but they resolve a real ambiguity the nested schema leaves open.

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 9-required-parameter mutation tool with nested objects and an output schema, the description covers the essential unknowns: approval gating, review routing, ownership constraint, dedupe outcome, and the one field that cannot be changed. Nothing needed to call it correctly is 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 the baseline is 3; the description earns above that by adding constraints the schema cannot express — plan_instance_id ownership, target_duration_in_seconds being non-adjustable for structured strength sessions, and the write-form shape of content_blocks (list of block objects) and session (object) versus their read-form column/row rendering.

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, resource, and scope: 'Propose a change to one scheduled workout's load' with enumerated kinds (lighter, rest, easy rebuild). It immediately distinguishes itself from propose_plan_revision by naming the multi-workout/multi-week case as the sibling's job.

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 routing guidance: single-workout changes here vs propose_plan_revision for several workouts or weeks. It also states who reviews the proposal (coach's own queue, athlete's assigned coach, or self-pending when unassigned) and the constraint that plan_instance_id must belong to the athlete.

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