Skip to main content
Glama
googlarz

Suunto MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_workout_fit

Retrieves a workout's FIT file from Suunto and parses it into JSON. Use default mode for workout summaries and analysis, or request full mode for complete record-level data.

Instructions

Downloads the workout's binary FIT file from Suunto and returns it parsed to JSON. Default (full=false): compact summary { sport, total_distance_km, avg_heart_rate, training_effect, laps, records_sample: { first, middle, last (one record each), count } }. Set full=true to receive every parsed FIT record — responses are often >100 KB for long workouts. Use the default for analysis and summaries; full=true only when raw record-level data is required. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNofalse (default): return compact summary. true: return all parsed FIT records.
workoutKeyYesOpaque server-assigned string returned by list_workouts. Not guessable or constructable — always discover via list_workouts first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.2
    • changedInput schema / properties / workoutKey / description
      Previous value: -"Unique workout identifier from list_workouts."New value: +"Opaque server-assigned string returned by list_workouts. Not guessable or constructable — always discover via list_workouts first."
  2. Changed3 schema fields changedv0.9.0
    • changedInput schema / properties / full / description
      Previous value: -"If true, returns ALL parsed records (large). Default false returns a summary + sampled records."New value: +"false (default): return compact summary. true: return all parsed FIT records."
    • addedInput schema / properties / workoutKey / description
      Added value: +"Unique workout identifier from list_workouts."
    • addedInput schema / properties / workoutKey / minLength
      Added value: +1
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden, and it does well: it states read-only behavior, describes the compact vs full response modes, and warns that responses can exceed 100 KB. It doesn't cover failure modes or authentication, but the key behavioral traits are disclosed.

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 front-loaded with the core action, then efficiently explains both modes and gives a clear recommendation. Every sentence earns its place with no filler.

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?

Since there is no output schema, the description appropriately explains the default return shape and characterizes full mode as raw record-level data with a size caveat. It could detail the full-mode record schema more, but it provides enough for correct selection and invocation.

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 value beyond the schema by spelling out the compact summary fields and quantifying the full-mode response size, which helps the agent choose correctly.

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 description names a specific verb and resource: it downloads the workout's binary FIT file from Suunto and parses it to JSON. This clearly distinguishes it from nearby siblings like get_workout, get_workout_samples, and export_workout_gpx.

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?

It gives explicit guidance on when to use full=false versus full=true and warns about large responses in full mode. It stops short of explicitly contrasting with sibling tools, so it doesn't earn a 5.

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