Skip to main content
Glama
googlarz

Suunto MCP

by googlarz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Import GPX route

upload_route

Import a GPX file into your Suunto account as a private route, ready to sync to your watch for navigation. Each route and track element becomes its own route.

Instructions

Imports a GPX file as a route in the user's Suunto account (it appears in the Suunto app's route library as PRIVATE and can then be synced to the watch for navigation). Provide the absolute path to a .gpx file. Every or element in the file becomes its own route; the route name comes from its (or ), and waypoints are created from elements at the same coordinates as route points and from route points that have a name or type. The route's activities come from the activities argument, NOT from the GPX content (default [1] = running). Returns { count, routes: [{ id, name, activities, segments }], check: { verified, watchEnabled, distanceM, pointsInFile, pointsInRoute, note? } }. Imports are queued one at a time with a short pause and each route is read back from Suunto (point count against the file), so many calls at once are safe; expect roughly 3 s per route. verified:false with a note means the import went through but the read-back did not match — say so to the user instead of reporting success. A route cannot be deleted through this server — remove it in the Suunto app. Requires the Route API on the Suunto subscription (list_routes shows existing routes). Write operation.

Input Schema

NameRequiredDescriptionDefault
filePathYesAbsolute path to the .gpx file on disk.
activitiesNoSuunto activity IDs the route is suitable for (1 = running; the other IDs are in Suunto's Activities.pdf on apizone). Shown in the app's route details. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.19.1

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), it discloses serial queuing with a ~3s per-route cost, read-back verification behavior, the meaning of verified:false with a note, and that routes cannot be deleted via this server. ".gpx" write-operation framing is consistent with readOnlyHint=false; creating without destroying is consistent with destructiveHint=false.

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?

Dense but front-loaded: the import action and scope come first, then file/format mapping, then return shape and operational caveats. Nearly every sentence carries non-obvious information, though the parenthetical return-shape enumeration is heavy in a block of prose.

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?

No output schema exists, yet the description inlines the return shape ({count, routes, check} with field meanings) and the failure semantics of check.verified. An agent has everything needed to call it, interpret the result, and warn the user about unverified imports.

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 already 100%, so the baseline is 3, but the description adds real meaning: activities override rather than derive from GPX content, default [1] = running, and how each <rte>/<trk>, <name>/<desc>, and <wpt> maps to output. It also clarifies filePath must be absolute.

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 opens with a specific verb+resource: "Imports a GPX file as a route in the user's Suunto account." It clearly separates this from siblings like list_routes (read), export_route (reverse direction), and upload_workout (workouts not routes), and even states the resulting visibility (PRIVATE route library).

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 concrete operating context: provide an absolute .gpx path, activities come from the argument not the file, list_routes shows existing routes, and the Route API subscription is required. It stops short of explicitly naming when to prefer this over export_route or other import paths, but the surrounding conditions are clear.

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