TrainRec

Plan a workout to follow

trainrec_plan_workout

Plans a workout for the person to do: saves it in TrainRec, where their phone and watch walk them through it one set at a time, with each set's target (weight and reps, time or distance) and the rest after it. Every set starts as not yet done. Given an id and version, it changes an existing plan, even during the workout: sets already done are kept, and the phone and watch show the change within seconds. A workout that already happened is recorded with save_workout.

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": {
      "name": "<name>",
      "exercises": "<exercises>"
    },
    "name": "trainrec_plan_workout"
  }
}

Input Schema

Name	Required	Description
`id`	No	Omit to create.
`day`	No	YYYY-MM-DD. Default today.
`name`	Yes	e.g. "Easy 5K and core", "Upper body A".
`unit`	No	Unit for every weight in this call. Defaults to the person's own unit.
`fresh`	No	true puts a workout started by mistake back to a plan: no set done, no start time. Send the whole plan.
`notes`	No	Shown at the top while they follow it: the goal of the session, cues.
`summary`	No
`version`	No	Required when id is given.
`exercises`	Yes	In the order performed, by exercise id (built-in or custom).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: every set starts as not yet done, edits during a live workout preserve already-completed sets, and devices reflect changes within seconds — a useful disclosure for a mutation tool whose annotations only say readOnly=false and destructive=false. However it says nothing about what happens on a stale or missing version during an update, which is the main failure mode for this concurrency scheme.

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?

Front-loaded with the core action, then update semantics, then the sibling disambiguation in a single closing sentence. Dense but every clause carries information an agent needs; no filler or restated title.

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?

Given 9 parameters, a nested exercises array and no output schema, the description covers the state model and the create-vs-update split well. It is incomplete on conflict handling for version and on what the call returns (the id/version the agent would need for a subsequent edit), which matters because no output schema documents the response.

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 89%, so the schema already explains id, day, unit, fresh, version, supersetId and the per-set fields. The description restates the set target shape (weight/reps, time or distance, rest after) and confirms the id+version pairing, but adds little beyond that and never clarifies fresh or superset grouping in prose.

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 concrete verb and resource ('Plans a workout... saves it in TrainRec') plus the artifact it produces: a set-by-set guided session with per-set targets and rest. The final sentence explicitly separates it from save_workout, so an agent can distinguish planning from recording without opening either schema.

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

Usage Guidelines4/5

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

Clearly routes the two main cases: create when id is absent, edit an existing plan when id and version are given, and the alternative for completed sessions is named (save_workout). It does not mention other related siblings such as delete_workout or save_routine, but the key confusion is resolved explicitly.

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

All TrainRec 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?