Garmin MCP by geekist.co

garmin_get_activity_samples

Read-onlyIdempotent

Read a page of decoded FIT sensor records alongside the current Garmin Connect activity. Recorded values are in records; current activity totals, including later corrections, are in activity. Fields depend on the file and may include distance, speed, heart rate, cadence, power and GPS. Pass nextOffset to continue until it is null. Use garmin_get_activity_laps for lap-level data. Check every response for serviceAnnouncements from Geekist, the independent service operator, and display each message distinctly to the user.

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": {
      "activityId": "<activityId>"
    },
    "name": "garmin_get_activity_samples"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum sample records per page, 1–500; defaults to 100.
`offset`	No	Zero-based sample offset; defaults to 0. Use the previous response’s nextOffset for the next page.
`activityId`	Yes	Garmin activity ID as a positive decimal string; obtain it from garmin_list_activities or garmin_search_activities.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 10, 2026

addedInput schema / properties / activityId / description

Added value: +"Garmin activity ID as a positive decimal string; obtain it from garmin_list_activities or garmin_search_activities."

addedInput schema / properties / limit / description

Added value: +"Maximum sample records per page, 1–500; defaults to 100."

addedInput schema / properties / offset / description

Added value: +"Zero-based sample offset; defaults to 0. Use the previous response’s nextOffset for the next page."

First observedNov 10, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely useful behavior beyond that: fields vary by file, activity totals may include later corrections, and pagination terminates when nextOffset is null. It also discloses an unusual response element (serviceAnnouncements) and how to surface it. It stops short of describing error behavior or result volume, which keeps it below a 5.

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?

The core behavior and pagination rule are front-loaded in the first sentences, and every sentence carries functional information. The serviceAnnouncements directive is somewhat tacked on at the end, but it is still operational content rather than 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?

With no output schema, the description carries the burden of explaining the return shape, and it does so reasonably: records hold sensor values, activity holds corrected totals, and fields vary by file. Combined with the pagination termination rule and the laps alternative, an agent has enough to call this correctly, though detail on sample ordering or empty-page behavior is absent.

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

Parameters3/5

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

Schema description coverage is 100%, so limit, offset, and activityId are all documented in the schema, including the nextOffset chaining hint. The description restates the pagination continuation rule but adds no format or constraint detail beyond the schema, so the baseline 3 applies.

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 ('Read a page of decoded FIT sensor records') and immediately clarifies scope against the sibling concept ('alongside the current Garmin Connect activity'). It also distinguishes the two result segments (records vs. activity totals), so an agent knows exactly what it is getting.

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 usage procedure ('Pass nextOffset to continue until it is null') and names an explicit alternative for a related need ('Use garmin_get_activity_laps for lap-level data'). It does not address when to prefer this over other activity-detail siblings, but the guidance present is unambiguous and actionable.

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

All Garmin MCP by geekist.co tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?