garmin-connect-api

Edit activity sets

edit_activity_sets

Destructive

Correct a strength activity's sets by changing exercise, reps, or weight, or deleting sets; returns the sets as Garmin now holds them.

Instructions

Correct a strength activity's sets: exercise, reps or weight, or delete sets.

Address sets by the set_number get_activity_sets shows; within one call, every number means the set as numbered before it. Deleting renumbers the sets after it, so repeating a delete removes a different set: use the numbers this returns for any further edit. Name exercises with Garmin's category and exercise_name; find_exercise looks them up. To rename the activity or change its description, use update_activity.

Returns the sets as Garmin now holds them.

Input Schema

TableJSON Schema

Name	Required	Description
`delete`	No	Working set numbers to remove.
`changes`	No	Edits, each applied to the working sets it lists.
`activity_id`	Yes	Garmin's activity id, from list_activities.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	Set when something about this answer needs saying.
`sets`	No
`activity_id`	Yes
`total_volume_kg`	Yes	Sum of reps times weight over the working sets. The usual definition of training volume. Sets with no weight recorded (bodyweight work) contribute nothing, which is the conventional treatment rather than a claim that they were easy.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description explains the underlying mechanic the annotation only implies: deleting renumbers subsequent sets, so repeating a delete hits a different set. It also discloses the batch numbering semantics ('within one call, every number means the set as numbered before it') and the return contract. This is materially more than the annotations provide.

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 core action and the set-number addressing model are front-loaded, and each remaining sentence carries a distinct rule. It is dense and slightly long for a three-parameter tool, but no sentence is filler.

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 non-idempotent batch mutation with an output schema, the description covers the hazards (renumbering, batch-relative numbering), the naming convention, and the sibling escape hatch. Nothing an agent needs to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond field docs: how set numbers are interpreted within a single batched call, that unspecified fields stay unchanged, and that the exercise must be the category/exercise_name pair. It stops short of documenting individual fields, which the schema already does.

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 ('Correct a strength activity's sets: exercise, reps or weight, or delete sets') and explicitly separates itself from update_activity, which handles renames and descriptions. An agent can distinguish it from sibling mutators without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing instructions: name exercises via find_exercise's category/exercise_name, read set numbers from get_activity_sets, use update_activity for renames/descriptions. The 'use the numbers this returns for any further edit' rule is actionable when-to guidance.

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