LiftTrack

schedule_run

Put a run on one date of the user's calendar. Nothing is saved for reuse: to put a run on another date, call again with its date. It shows on that date in the LiftTrack app and, when the user's Garmin account is linked, reaches their Garmin calendar and watch within 7 days of the date (runs further ahead wait until then). To change a scheduled run, remove it and schedule the new version.

date: YYYY-MM-DD, from today through 120 days ahead. Each step: type "step", phase, exactly one of minutes, seconds, distance, until_lap_press, plus optional effort, optional heart_rate_zone or heart_rate (at most one), and optional note. Each repeat: type "repeat", times (2 or more), and steps; repeats do not nest. Every distance reads in the run's distance_unit. effort is what the step should feel like and is shown on the watch. Only heart_rate_zone or heart_rate make the watch alert. The usual zone for each effort when guiding by heart rate: walk 1, recovery 1, easy 2, steady 3, tempo 3-4, threshold 4, hard 5, sprint 5. Pace is not a target; a pace cue belongs in note as words. Returns the entry's schedule_id (for tool calls only; never show ids to the user), a one line summary of the run, and totals: timed minutes and total distance are separate, and open_steps counts steps that last until a lap press.

Example: {"date":"2026-11-12","name":"6 x 800","distance_unit":"km","steps":[{"type":"step","phase":"warmup","minutes":15,"effort":"easy"},{"type":"repeat","times":6,"steps":[{"type":"step","phase":"work","distance":0.8,"effort":"hard","heart_rate_zone":5},{"type":"step","phase":"recovery","distance":0.4,"effort":"recovery"}]},{"type":"step","phase":"cooldown","minutes":10,"effort":"easy"}]}

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": {
      "date": "<date>",
      "name": "<name>",
      "distance_unit": "<distance_unit>",
      "steps": "<steps>"
    },
    "name": "schedule_run"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	Calendar date as YYYY-MM-DD
`name`	Yes	Workout name shown in the app, Garmin Connect and on the watch
`steps`	Yes	The workout in order: steps and repeats
`description`	No	What the session is for, shown in Garmin Connect
`distance_unit`	Yes	The unit every distance in this workout is written in

Output Schema

Name	Required	Description	Default
`date`	Yes
`name`	Yes
`totals`	Yes
`summary`	Yes
`schedule_id`	Yes
`garmin_linked`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (non-readonly, non-destructive, non-idempotent), the description discloses genuinely useful behavior: the entry appears in the LiftTrack app and, when Garmin is linked, propagates to the Garmin calendar and watch within 7 days of the date, with further-ahead runs waiting. It also warns that ids are returned for tool use only and must never be shown to the user, which annotations cannot convey.

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?

Long but dense and well ordered: behavior first, then date bounds, then step/repeat grammar, then semantics of effort and note, then return values, closing with a full example. A few lines restate schema facts ('Every distance reads in the run's distance_unit'), and the effort/zone table is bulky, but almost every sentence carries decision-relevant information.

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?

This is a complex tool with a nested step/repeat grammar, yet the description covers the date window, step composition, repeat limits, effort semantics, unit propagation, and the non-obvious Garmin sync lag. An output schema exists, and the description still summarizes the returned schedule_id, summary, and totals, leaving no material gap for correct invocation.

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?

Schema coverage is already 100%, but the description adds substantial meaning: the date window of today through 120 days ahead, the rule that each step carries exactly one of minutes/seconds/distance/until_lap_press, that repeats do not nest, the effort-to-heart-rate-zone mapping, and the constraint that pace is not a valid target and belongs in note. These are constraints the schema cannot express.

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?

Opens with a specific verb and resource ('Put a run on one date of the user's calendar') and immediately states the key distinction that 'Nothing is saved for reuse', which separates it from the workout-creation siblings. It never names schedule_workout or create_workout directly, so the differentiation is inferred rather than explicit.

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?

Gives clear operational guidance: call again with a different date to schedule another instance, and to change a scheduled run 'remove it and schedule the new version' rather than updating in place. It does not name the sibling tools that perform removal or saved-workout scheduling, so the agent must map those instructions itself.

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

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