Skip to main content
Glama
Garmin Dynamic MCP

Garmin Dynamic MCP

Read Garmin data

get
Read-onlyIdempotent

Fetches data from one read-only Garmin Personal API endpoint and returns compact JSON. Use path, parameters, and optional fields to request activities, sleep, heart rate, or Garmin Connect data.

Instructions

Call one Garmin Personal API endpoint (GET only) and return compact JSON.

path: an endpoint path exactly as listed by list_endpoints (with the {placeholders}). params: values for that endpoint's path and query parameters, e.g. {"startDate": "2026-11-01", "endDate": "2026-11-09"}. For the activity search endpoint, limit is the total number of activities wanted (pages are fetched automatically, up to 1000) and startDate/endDate filter by date. fields: optional dotted paths to keep, e.g. ["startTimeLocal", "distance", "averageRunningCadenceInStepsPerMinute"]. Activities come with a useful default set when fields is omitted. Returns {"data": ..., "partial": bool, "notes": [...], "key_warning": str|null}. If partial is true, read notes: the result was cut and says how to narrow the request. Responses are capped at about 40,000 characters (roughly 150 activities in the default view): for long periods pass a short fields list. If key_warning is not null, tell the user. If update_available is present, tell the user once (version and how to update).

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": "get"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
fieldsNo
paramsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnly, idempotent, openWorld) by disclosing a ~40,000 character response cap, automatic pagination up to 1000 activities for the search endpoint, the partial/notes truncation contract, and the requirement to surface key_warning and update_available to the user.

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-loads the one-line purpose, then treats each parameter in turn and closes with the return contract. Every sentence carries actionable information; nothing is filler despite the length.

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 generic pass-through endpoint caller with three undocumented parameters and an output schema, the description covers invocation, narrowing strategy, truncation recovery, and user-facing warnings. The only loose thread is update_available, which is referenced but not listed in the stated return shape.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full load and does: it defines path format with placeholders, explains that params holds path and query values with a concrete example, clarifies limit semantics for activity search, and explains fields as dotted paths with a default set when omitted.

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 scope: call one Garmin Personal API endpoint, GET only, returning compact JSON. It also pins the source of the path to the sibling tool list_endpoints, so an agent can tell immediately how this differs from that sibling.

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 clear operational routing: path must come exactly from list_endpoints including placeholders, use a short fields list for long date ranges, and read notes when partial is true. It lacks explicit when-not guidance or naming of any alternative beyond the endpoint lister.

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