coros-training-mcp

Overview Schema Source Related Servers Discussions Admin

Move Scheduled Workout

move_scheduled_workout

Move a scheduled workout to a new day by rescheduling the existing plan entry on a target date, then removing the original so the session is never lost.

Instructions

Move a scheduled workout to a new day.

The source-of-truth is the existing scheduled entry identified by (plan_id, id_in_plan). Its embedded program is used to re-schedule on happen_day, which supports both library workouts AND plan-embedded programs from subscribed training plans (which have no library entry).

Order of operations is schedule-new → remove-old, so a failure leaves a duplicate rather than losing the workout. A pre-flight lookup verifies the scheduled entry exists before anything destructive runs.

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": {
      "plan_id": "<plan_id>",
      "id_in_plan": "<id_in_plan>",
      "happen_day": "<happen_day>"
    },
    "name": "move_scheduled_workout"
  }
}

Input Schema

Name	Required	Description
`plan_id`	Yes	Top-level schedule plan ID from list_scheduled_workouts.
`sort_no`	No	Order within the new day if multiple workouts exist.
`happen_day`	Yes	New target date in YYYYMMDD format.
`id_in_plan`	Yes	Scheduled entity ID from list_scheduled_workouts.
`workout_id`	No	Library workout ID. Optional — used only as a fallback if the scheduled entry lookup doesn't return an embedded program.
`plan_program_id`	No	Fallback program ID when the scheduled entry lookup doesn't provide one.
`source_happen_day`	No	Optional hint for the current day of the scheduled entry (YYYYMMDD). Narrows the search window; default search spans ~6 months around today.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Oct 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does a good job: it discloses the operation order (schedule-new → remove-old), the resulting failure mode (a duplicate rather than a lost workout), and the pre-flight existence check before anything destructive runs. It omits auth/permission requirements and any conflict behavior with sort_no.

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 action in the first sentence, then supporting detail in two short paragraphs; nothing is padding. Minor deduction for reStructuredText double-backtick markup (``happen_day``) that adds visual noise without 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 mutation tool with no annotations, the description covers ordering, failure semantics, and source-of-truth resolution, and an output schema exists so return values need no explanation. Remaining gaps are edge-case behavior (past dates, duplicate resolution, sort_no collisions) rather than core operational knowledge.

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 coverage is 100%, so the schema already documents all seven parameters and the baseline is 3. The description adds some genuine value by framing plan_id/id_in_plan as the source of truth and workout_id/plan_program_id as fallbacks, but it does not explain sort_no or how source_happen_day interacts with the default ~6-month search window.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Move a scheduled workout to a new day') and explains that the existing (plan_id, id_in_plan) entry is the source of truth for the re-schedule. It never names the obvious alternatives (schedule_workout, replace_scheduled_workout, remove_scheduled_workout), so an agent must infer the boundary from the verb alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'move ... to a new day' and the description clarifies which inputs act as primary vs. fallback, but there is no explicit when-to-use-this-instead-of statement against the three closely related scheduling siblings. No prerequisites or exclusions (e.g. moving to a past date) are given.

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