Garmin MCP for macOS

Overview Schema Source Related Servers Discussions Admin

garmin_api_activity_search

Read-only

Search Garmin Connect activities by date, type, distance, duration, elevation, power, location, and dive metrics, with pagination and filter options for precise activity queries.

Instructions

Search activities with every documented filter. Distances and elevations are meters, durations are seconds, dive depth is centimeters, and power is watts. Array filters become repeated query parameters. Supply all four coordinates for a bounding box. Follow pagination with start and limit. Raw JSON fields are not normalized. Date ranges default to 7 days and allow at most 31 days (activity search uses pagination).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "garmin_api_activity_search"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`start`	No
`search`	No
`sort_by`	No
`end_date`	No
`favorite`	No
`deco_dive`	No
`event_type`	No
`sort_order`	No
`start_date`	No
`max_distance`	No
`max_duration`	No
`min_distance`	No
`min_duration`	No
`activity_type`	No
`max_elevation`	No
`min_avg_power`	No
`min_elevation`	No
`left_longitude`	No
`lower_latitude`	No
`required_field`	No
`upper_latitude`	No
`lower_max_depth`	No
`max_bottom_time`	No
`min_bottom_time`	No
`right_longitude`	No
`upper_max_depth`	No
`exclude_children`	No
`activity_sub_type`	No
`max_elapsed_duration`	No
`min_elapsed_duration`	No
`excluded_activity_sub_type`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Oct 26, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish read-only, non-destructive, open-world behavior, and the description adds real operational context beyond them: unit conventions (meters, seconds, centimeters, watts), array filters becoming repeated query parameters, required bounding-box completeness, and the 7-day default / 31-day cap. The one weak spot is the opaque note that 'Raw JSON fields are not normalized,' which signals something but doesn't say what to expect.

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?

Purpose is front-loaded in the first clause, followed by compact unit and constraint rules. Given 32 parameters and several non-obvious conventions, the length is justified, though a couple of sentences (e.g., the raw-JSON note) are cryptic rather than efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values needn't be explained, and annotations cover safety. But for a 32-parameter tool with zero schema descriptions, the description leaves too many filter names uninterpreted to be fully self-sufficient, even though it handles units, pagination, bounding box, and date-range limits well.

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 0% across 32 parameters, so the description must carry the load. It usefully disambiguates the highest-risk ambiguities — units per measurement family, array-to-repeated-param behavior, the four-coordinate bounding box, and start/limit pagination — but many parameters (required_field, favorite, exclude_children, event_type, bottom_time/min-max depth semantics) remain undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Search activities') with the scope claim 'with every documented filter,' which distinguishes it from single-activity siblings like garmin_api_activity. It never names an alternative tool explicitly, so the differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Adds operational guidance on how to invoke it (pagination via start/limit, supply all four coords for a bounding box, date ranges default to 7 days and cap at 31), which is useful. However, it gives no explicit when-to-use/when-not guidance relative to the many sibling list tools (garmin_activities, garmin_api_wellness_activities, etc.), leaving tool selection to inference.

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