Suunto MCP

Push strength guide to watch

push_strength_guide

Destructive

Push a resistance-training guide to a Suunto account, creating per-set and rest steps for gym workouts that sync to the watch after the next app sync.

Instructions

Pushes a resistance-training guide to the user's Suunto account via the SuuntoPlus Guide Cloud API — the tool to use for gym sessions. Per exercise: a prep step (self-paced stopwatch showing the plate breakdown if given, otherwise the weight/sets detail, plus the exercise name and live HR; a lap press starts the exercise), then with lapGranularity 'perSet' (default) each set is its own step ended by a lap press, and each rest between sets is its own step showing 'Next: set k/S'. restMode 'countdown' (default) counts down restSec and auto-advances into the next set with a vibration; 'stopwatch' counts up and waits for a lap press. lapGranularity 'perExercise' gives one step per exercise after its prep, with no between-set rests and no per-set laps. Every prep, set and rest is its own lap and the guide ends with one extra 'Session complete' step, so a perSet session records 2 × (total sets) + 1 laps. Read them back after the workout with get_workout_laps — its labels are the step texts. Requires SUUNTO_APP_NAME to exactly match the app name registered on apizone.suunto.com. Without guideId a new guide is created on every call (see list_guides / delete_guide to tidy up); with guideId that guide is overwritten. There is no live push to the watch: it appears after the phone's next normal Suunto app sync. Returns Suunto's response (including the guide id) plus nextStep and check: { verified, note? }: after the push the guide is looked up in the guide list (by id), and verified:false with a note means the push went through but the guide was not found there — say so to the user instead of reporting success. Pushes are queued one at a time with a short pause, so several calls at once are safe. Write operation.

Input Schema

Name	Required	Description	Default
`date`	Yes	Session date YYYY-MM-DD.
`title`	Yes	Short session name shown in the Suunto app, e.g. 'Push A'.
`guideId`	No	If provided, updates this existing guide instead of creating a new one.
`restMode`	No	Rest between sets. 'countdown' (default): counts down from restSec and auto-advances into the next set. 'stopwatch': counts up and waits for a lap press — the user paces it. Has no effect with lapGranularity 'perExercise' (no between-set rests). Before/between exercises is always a self-paced stopwatch.	countdown
`exercises`	Yes
`lapGranularity`	No	'perSet' (default, recommended): one step per set plus one per rest, so laps bound every set/rest individually — needed to read per-set HR and duration from the synced workout. 'perExercise': one step per whole exercise instead, like push_workout_guide — shorter Guide list, coarser data.	perSet

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.15.1Sep 30, 2026

changedInput schema / properties / exercises / items / properties / detail / description

Previous value: -"Display string shown on the exercise's set steps and on the prep screen before it — include weight and sets, e.g. '60kg 3x10'."New value: +"Display string shown on the exercise's set steps, and on the prep screen before it unless 'plates' is given — include weight and sets, e.g. '60kg 3x10'."

addedInput schema / properties / exercises / items / properties / plates

Added value: +{
+  "description": "Per-side plate breakdown for barbell exercises, e.g. '2x20+1x5/side' — shown on the prep screen instead of detail, since that's when the bar actually gets loaded. Omit for non-barbell exercises (dumbbell, machine, bodyweight, cable); compute the math yourself before calling this tool, it isn't done here.",
+  "type": "string"
+}

Addedv0.15.0Sep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare a destructive, non-idempotent, open-world write; the description earns its keep by adding the non-obvious consequences: a new guide is created on every call without guideId, existing guides are overwritten with guideId, there is no live push (appears after next phone sync), and pushes are queued serially so concurrent calls are safe. The verified/note return contract for a failed lookup is exactly the kind of post-condition annotations can't express, and nothing contradicts the destructiveHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and warnings are front-loaded, but the body is one dense paragraph of long run-on sentences covering lap math, rest modes, and sync timing with no structure. Nearly all content is useful, yet the lap-counting narrative is restated in several clauses and would be far cheaper to read as a short list.

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 6-parameter destructive write with no output schema, the description covers prerequisites (SUUNTO_APP_NAME must match the registered app), persistence semantics, sync delay, concurrency, and the shape and interpretation of the response including the verified/note failure case. An agent has everything needed to call it and report results honestly.

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 83%, so the baseline is 3, but the description goes beyond the schema by explaining the operational consequence of each mode choice (perSet laps bound every set/rest so per-set HR is readable; perExercise has no between-set rests) and gives the lap-count formula 2 × total sets + 1. It does not spell out plates formatting beyond the schema, so it is not a full 5.

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 ('Pushes a resistance-training guide to the user's Suunto account') and immediately differentiates from siblings by scoping it to 'gym sessions' and contrasting perExercise mode with push_workout_guide. An agent can pick this over push_interval_guide or push_workout_guide 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?

Explicitly states when to use it (gym sessions), when a variant is preferable (perExercise 'shorter Guide list, coarser data'), the alternative for reading results back ('get_workout_laps'), and the cleanup path ('list_guides / delete_guide'). It also gives the guideId create-vs-overwrite decision rule, leaving no inference required.

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

Push strength guide to watch

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools