Skip to main content
Glama
Sign In
garmin-connect-mcp

garmin-connect-mcp

by Samiu1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Call a Garmin Endpoint Directly

garmin_get_raw
Read-onlyIdempotent

Send an authenticated GET to any Garmin Personal API path to query endpoints or parameters not covered by dedicated tools, including custom activity filters and future Garmin additions.

Instructions

Perform an authenticated GET against any Garmin Personal API path, for endpoints and parameters the other tools do not expose.

The request goes to the configured Garmin host with the bearer token applied; only the path and query are yours to set.

Use it for:

  • Activity search filters the dedicated tool omits: upperLatitude/leftLongitude/lowerLatitude/rightLongitude bounding boxes, lowerMaxDepth/upperMaxDepth and decoDive for diving, minBottomTime/maxBottomTime, minElapsedDuration/maxElapsedDuration, excludedActivitySubType, requiredField

  • Any endpoint Garmin adds after this server was written

Example: path="/activitylist-service/activities/search/activities", query={"activityType":"diving","lowerMaxDepth":"1800","limit":"5"}

Prefer the dedicated tools when one covers the request: they format results and report metric availability.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>"
    },
    "name": "garmin_get_raw"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesEndpoint path beginning with '/', e.g. '/userprofile-service/userprofile/settings'
queryNoQuery parameters as string key/value pairs. Repeatable parameters take a comma-separated value.
response_formatNo'markdown' for readable text, 'json' for the exact Garmin field names and valuesmarkdown
include_empty_fieldsNoKeep fields Garmin returned as null or empty. Off by default, since unsupported sensors on the user's device produce large runs of nulls. Turn on only to inspect raw shape.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds context the annotations cannot: the host is preconfigured and the bearer token is applied automatically, leaving only path and query under caller control, plus the trade-off that raw calls forgo the formatting and metric-availability reporting of dedicated tools. It stops short of describing error or rate-limit behavior for arbitrary endpoints.

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?

Front-loaded with the one-sentence purpose, then the auth/host constraint, then a scannable use-case list, then an example, then the alternative-tool caveat. The long filter enumeration is the tool's actual value proposition rather than filler, and no sentence is redundant.

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?

For an open-world passthrough with no output schema, the description covers what an agent needs to call it correctly: what is caller-controlled, what the server handles, the string-typed query convention, and why to prefer dedicated tools. It leaves the raw response shape uncharacterized beyond the response_format option, which the schema documents.

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 baseline is 3, but the worked example adds real meaning: it shows the query object must be string-valued ("lowerMaxDepth":"1800", "limit":"5") and pairs a concrete path with its query, which clarifies the path/query split that the schema only implies. It does not explain response_format or include_empty_fields in prose, relying on the schema for those.

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: an authenticated GET against any Garmin Personal API path, framed explicitly as an escape hatch for endpoints and parameters the other tools don't expose. This distinguishes it cleanly from every sibling, which are all resource-specific getters/searchers.

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?

Gives an explicit when-to-use list (bounding-box activity filters, dive depth/deco params, duration filters, excludedActivitySubType, requiredField, future endpoints) and an explicit preference rule: use the dedicated tools when one covers the request, because they format results and report metric availability. Both the positive and negative cases are stated.

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