Skip to main content
Glama
jonas-theobald

garmin-mcp-bridge

by jonas-theobald
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

create_planned_workout

Create structured workouts on Intervals.icu to sync planned sessions to Garmin Connect and your watch.

Instructions

Create a structured planned workout on the Intervals.icu calendar.

Intervals.icu syncs planned workouts to a connected Garmin Connect account, so this is the path for getting a session onto the watch. See the README caveat: confirm the first workout actually reaches Garmin before relying on this in a training block.

Args: start_date: Local date YYYY-MM-DD. Time is forced to 00:00:00, which the API requires for calendar events. name: Short session title, e.g. "3x8min Schwelle". description: Workout in Intervals.icu syntax (see below). activity_type: "Run", "Ride", "Hike", "WeightTraining", "Swim". moving_time: Total duration in seconds. Optional; Intervals.icu derives it from the parsed description. target: "HR", "PACE" or "POWER". Use "HR" for trail and hiking work where pace is meaningless on steep terrain. training_load: Optional manual load override. external_id: Stable id of your own. Reusing it with the same date makes the call idempotent, so a re-planned week updates instead of duplicating.

Workout syntax — one step per line, prefixed "- ":

- 15m Z2 Warmup
3x
- 8m Z4
- 3m Z1
- 10m Z1 Cooldown

A bare "Nx" line on its own starts a repeated block; the following steps until the next blank line are repeated. Durations use m/s/h. Targets can be zones ("Z2"), ranges of threshold ("75-82%"), or free text for steps with no measurable target. Blank lines separate blocks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
targetNoHR
start_dateYes
descriptionYes
external_idNo
moving_timeNo
activity_typeNoRun
training_loadNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations present, the description carries the full behavioral burden and does so thoroughly: it discloses the Garmin side-effect, idempotent behavior when external_id is reused, forced 00:00:00 start time, and optional moving_time derivation. This goes well beyond the bare schema and helps the agent anticipate real-world consequences.

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 long but tightly organized into a purpose paragraph, a compact Args list, and a syntax example with rules. Every section adds operational knowledge an agent needs, so the length is justified rather than bloated.

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?

For a parameter-heavy creation tool with no output schema and no annotations, this is essentially complete: it covers all inputs, the domain-specific syntax, idempotency, and a real-world caveat. The only omission is a description of the return payload, but that is not required 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 description coverage is 0%, yet the Args section explains all eight parameters with formats, defaults, and reasoning, and the workout-syntax block gives essential semantics for the free-form description parameter. The description fully compensates for the schema's lack of parameter documentation.

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 opening line names the exact action ('create'), the resource ('structured planned workout'), and the target system ('Intervals.icu calendar'), and the Garmin sync clause separates it from the read/list/delete siblings. This is a specific verb+resource statement, not a tautology or vague paraphrase.

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 first paragraph explicitly frames the tool as the path for getting a session onto a Garmin watch and warns to verify the first sync before relying on it in a training block. It gives clear situational context and even a target-selection rule ('Use HR for trail and hiking work'), though it does not name alternative tools or state an explicit when-not-to-use condition.

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