garmin-mcp

Overview Schema Source Related Servers Discussions Admin

create_workout

Create a structured workout in Garmin Connect with steps, targets, and sport type. Builds a new workout without altering existing ones, ready to schedule for syncing to your watch.

Instructions

Create a structured workout in Garmin Connect.

Adds a new workout; it never edits or replaces an existing one. Use schedule_workout afterwards to put it on a date so it syncs to the watch.

Args: name: Name shown in Garmin Connect and on the watch. steps: Ordered list of steps. Each step is an object: - "type": warmup, interval, recovery, rest, cooldown, or repeat - exactly one of "duration_seconds" or "distance_meters" - optional target, either "pace" ("4:05", or ["4:00","4:10"] for a range, minutes per km) or "hr" ([150, 165] in bpm) A repeat looks like {"type": "repeat", "times": 5, "steps": [...]} and cannot contain another repeat. Example — 15 min warmup, 5x1km at 4:05 with 90s recoveries, 10 min cooldown: [{"type": "warmup", "duration_seconds": 900}, {"type": "repeat", "times": 5, "steps": [ {"type": "interval", "distance_meters": 1000, "pace": "4:05"}, {"type": "recovery", "duration_seconds": 90}]}, {"type": "cooldown", "duration_seconds": 600}] sport: running, cycling, swimming, walking or hiking. Defaults to running. description: Optional note stored with the workout.

Input Schema

TableJSON Schema

Name	Required	Default
`name`	Yes
`sport`	No	running
`steps`	Yes
`description`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool only creates new workouts, that repeat steps cannot nest repeats, and that the workout will not sync to the watch until scheduled. It stops short of describing failure responses or auth requirements, but the behavioral context is substantial.

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?

The description is front-loaded with purpose and mutation semantics, then proceeds through step specifications and a concrete example. Every sentence adds substantive value, and the example is long but necessary to fully explain an otherwise under-specified schema.

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?

The description covers a complex nested-steps protocol: step types, duration/distance mutual exclusivity, target formats, repeat nesting constraint, sport defaults, and the required scheduling step. An output schema exists to document return values, so nothing essential for invoking the tool correctly is missing.

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 description coverage is 0% and the steps parameter is merely an array of objects with additionalProperties:true. The description fully compensates: it defines step types, duration/distance exclusivity, target pace/HR formats with examples, repeat structure, nesting limits, sport options, and defaults.

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?

The description opens with a specific verb and resource: 'Create a structured workout in Garmin Connect.' It further distinguishes itself by clarifying 'it never edits or replaces an existing one' and by naming schedule_workout for the follow-up step, so an agent can readily separate creation from scheduling.

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?

The description gives clear workflow guidance: use schedule_workout afterwards to put the workout on a date and sync it to the watch. It also states the tool is strictly additive, ruling out editing/replacing existing workouts. It does not explicitly enumerate alternatives for list/edit operations, but the context is strong enough for correct selection.

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

Deploy Server