Skip to main content
Glama

create_run_workout

Create a continuous run workout with warmup and cooldown, targeting a heart rate zone or custom bpm range, and upload it to Garmin Connect.

Instructions

Create a continuous run workout and upload it to Garmin Connect.

Builds a single uninterrupted run interval with warmup and cooldown walks.

Targets a named Garmin heart-rate zone by default. Named zones (Z1-Z5) don't line up with every real training target -- e.g. a 136-148 bpm Zone 2 goal straddles Garmin's Z2 (118-137) and Z3 (138-157). Pass hr_min and hr_max together to target that exact bpm range instead; the watch will then show "in range" only for the range you actually want, not a whole zone that over- or under-shoots it.

Args: name: Workout name (e.g. "Step 8 - 30min continuous") run_seconds: Duration of the run in seconds warmup_min: Warmup walk duration in minutes cooldown_min: Cooldown walk duration in minutes hr_zone: Target heart-rate zone (Z1-Z5, default Z3). Ignored if hr_min/hr_max are given. hr_min: Optional custom target heart rate range, minimum bpm (must be given with hr_max) hr_max: Optional custom target heart rate range, maximum bpm (must be given with hr_min)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
hr_maxNo
hr_minNo
hr_zoneNoZ3
warmup_minYes
run_secondsYes
cooldown_minYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/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 of transparency. It discloses the primary side effect (uploading to Garmin Connect) and the behavior of heart rate targeting with both named zones and custom ranges. It does not mention failure modes or reversibility, but for a creation operation this level of transparency is reasonably complete.

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?

The description is well-structured with a headline, an explanatory paragraph, and a parameter list. The heart rate zone example is detailed and valuable but adds a bit of length; overall, it is concise and every sentence serves a purpose without fluff.

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 the tool's complexity and the existing output schema (though not displayed), the description adequately covers the input semantics and the primary action. It does not discuss return values, but since an output schema is indicated, that is acceptable. No prerequisites or error conditions are mentioned, but they are not essential for this creation operation.

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?

The description explicitly explains every parameter in a bulleted list, including the nuanced behavior of hr_min and hr_max (must be given together, overrides hr_zone) and the default value of hr_zone. This adds substantial meaning beyond the raw schema, which only lists types and defaults, ensuring the agent understands exactly how to supply each argument.

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?

The description clearly states the tool creates a continuous run workout and uploads it to Garmin Connect, with a detailed explanation of a single uninterrupted run interval. It does not explicitly contrast with sibling workout creation tools like create_walk_run_workout or create_strength_workout, but the 'continuous run' phrasing and the example parameter values make the purpose unambiguous.

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?

The description provides clear guidance on when to use hr_zone versus hr_min/hr_max, explaining the pitfall of named zones and the requirement to pass both min and max together. However, it does not explicitly state when to choose this tool over alternative workout creation sibling tools, leaving some ambiguity about the broader selection criteria.

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

Deploy Server

Other Tools