garmin-connect-api

Log strength session

log_strength_session

Record a completed strength workout to Garmin Connect, preserving every exercise, set, rep, and weight as a Strength Training activity.

Instructions

Log a completed strength session to Garmin Connect as an activity.

Takes the session as it happened, exercise by exercise with the reps and weight of every set, encodes it as a FIT activity file and uploads it. It appears in Garmin Connect as a Strength Training activity with the sets intact, named after the session, with its notes as the description.

If the account shares to Strava or another app, the activity may be posted there too, publicly, and deleting it from Garmin does not delete it there.

Name exercises with Garmin's category and exercise_name pair, which find_exercise gives. Logging the identical session again is reported as a duplicate and changes nothing; logging it with any set changed creates a second activity, so correct one with edit_activity_sets.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	The activity's title in Garmin Connect.	Strength Training
`notes`	No	Saved as the activity's description.
`exercises`	Yes	The exercises in the order done, each with its sets.
`start_time`	Yes	When the session started. Without an offset, it is taken as local time in the Garmin account's own timezone.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the thin annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false) by disclosing the Strava/third-party public post risk and that deleting from Garmin does not remove it there, plus the duplicate-detection behavior (identical session is a no-op; any changed set creates a second activity). This is exactly the pre-call context an agent needs for a write tool.

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?

Purpose is front-loaded and the four paragraphs each carry distinct payloads (destination/encoding, external-sharing risk, naming convention, duplicate/correction behavior). It is dense but not padded; a small amount of repetition around 'appears in Garmin Connect' could be trimmed.

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 write tool with a nested input schema and an output schema present, the description covers the missing pieces an agent cannot infer: external sharing side effects, duplicate semantics, exercise naming source, and the correct remediation tool. Nothing needed to call it correctly is absent.

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 real value by telling the agent how the exercise fields must be populated (Garmin's category + exercise_name pair, sourced from find_exercise) and that the session is taken 'as it happened, exercise by exercise with the reps and weight of every set', which the schema alone does not convey.

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?

Opens with a specific verb+resource+destination: 'Log a completed strength session to Garmin Connect as an activity.' The phrase 'completed strength session' implicitly distinguishes it from the sibling create_strength_workout (which builds a plan), and the non-obvious encodings (FIT file, Strength Training activity with sets intact, name/notes mapping) make the outcome unambiguous.

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 concrete routing: name exercises via find_exercise's category/exercise_name pair, and correct a logged session with edit_activity_sets rather than re-logging. It does not explicitly contrast itself with create_strength_workout or create_workout_from_dto, but the 'completed session' framing covers the main alternative.

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