Skip to main content
Glama
Sign In
garminconnect-js

garminconnect-js

by DynamicsNinja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

update_workout

DestructiveIdempotent

Replace an existing Garmin workout with a new specification, overwriting the whole workout. Confirm first, ideally after previewing.

Instructions

Replace an existing workout with a new spec. This OVERWRITES the whole workout; confirm with the user first, ideally after preview_workout. Paces are minutes as decimals (4:30 = 4.5), distances metres, times seconds.

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": {
      "workoutId": "<workoutId>",
      "spec": "<spec>"
    },
    "name": "update_workout"
  }
}

Input Schema

NameRequiredDescriptionDefault
specYesA Garmin workout. Give `steps` for one sport, or `legs` (each with its own sport) for a multi-sport workout, not both. Distances are metres, times seconds.
workoutIdYesFrom get_workouts or create_workout

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is partly covered. The description still adds real value by specifying what gets destroyed ('OVERWRITES the whole workout') and the human-confirmation expectation, which annotations cannot express.

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?

Three short sentences, front-loaded with the destructive headline, then the confirmation workflow, then units. No filler; every sentence carries information.

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?

For a deeply nested, no-output-schema mutation tool, the description covers scope, risk, and prerequisite checking, and the schema carries the structural detail. It could say more about what state the workout is left in (e.g., schedule implications), which is the only real gap.

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 100%, so both top-level parameters and the nested spec units are already documented in the schema (including the pace 4:30 = 4.5 convention and metre/second units). The description's unit sentence largely restates that, so baseline 3 applies.

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 specific verb and resource ('Replace an existing workout with a new spec') and clarifies scope: full replacement, not a partial edit. It also names preview_workout as the related sibling, so an agent can place it without opening the 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?

Gives an explicit prerequisite workflow ('confirm with the user first, ideally after preview_workout'), which is actionable context for a destructive tool. It does not, however, contrast against create_workout or delete_workout, so the agent must infer why to update rather than recreate.

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