Garmin MCP

Search activities

search_activities

Read-onlyIdempotent

List recorded activities and return activity IDs for detailed analysis; filter by date, sport, race, distance, duration, elevation, name, or location. Use for individual lookups, not aggregate totals.

Instructions

List individual recorded activities (runs, rides, swims, strength, etc.) with the activity_id needed for get_activity and get_activity_analysis. Filter by date, type, race, distance, duration, elevation gain, name text or a lat/long box. For totals, averages or trends over weeks/months, use summarize_activities instead: it is far smaller. Default detail='compact' returns key stats only (distance m, duration/movingDuration s, averageSpeed/maxSpeed m/s, HR, elevation, calories, cadence, power, training effect). Use detail='full' only when a field you need is missing, and with a small limit. Sport-specific extras such as golf scorecards, shot data or dive logs are NOT available.

Input Schema

Name	Required	Description	Default
`area`	No	Only activities that started inside this latitude/longitude box (decimal degrees).
`limit`	No	Max results (1-100).
`start`	No	Offset for paging.
`detail`	No		compact
`period`	No	Named period resolved in the user's time zone (weeks start Monday). Use instead of start_date/end_date.
`sort_by`	No	Sort field. Use distance or averageSpeed to find longest or fastest.	startLocal
`end_date`	No	Only activities on/before this date.
`event_type`	No	Only activities tagged with this event type, e.g. race.
`sort_order`	No		desc
`start_date`	No	Only activities on/after this date.
`activity_type`	No	Parent type key, e.g. running, cycling, swimming, strength_training, walking, hiking.
`name_contains`	No	Text the activity name contains (case-insensitive), e.g. 'parkrun' or 'tempo'.
`max_distance_m`	No	Maximum distance in metres.
`min_distance_m`	No	Minimum distance in metres.
`activity_subtype`	No	Subtype key within activity_type, e.g. trail_running, treadmill_running, road_cycling.
`exclude_children`	No	Hide the legs of multisport activities (e.g. a triathlon's swim/bike/run), keeping the parent.
`max_duration_min`	No	Maximum duration in minutes.
`min_duration_min`	No	Minimum duration in minutes.
`max_elevation_gain_m`	No	Maximum elevation gain in metres.
`min_elevation_gain_m`	No	Minimum elevation gain in metres.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedNov 9, 2026

addedInput schema / properties / area

Added value: +{
+  "description": "Only activities that started inside this latitude/longitude box (decimal degrees).",
+  "properties": {
+    "east": {
+      "maximum": 180,
+      "minimum": -180,
+      "type": "number"
+    },
+    "north": {
+      "maximum": 90,
+      "minimum": -90,
+      "type": "number"
+    },
+    "south": {
+      "maximum": 90,
+      "minimum": -90,
+      "type": "number"
+    },
+    "west": {
+      "maximum": 180,
+      "minimum": -180,
+      "type": "number"
+    }
+  },
+  "required": [
+    "north",
+    "south",
+    "west",
+    "east"
+  ],
+  "type": "object"
+}

addedInput schema / properties / exclude_children

Added value: +{
+  "description": "Hide the legs of multisport activities (e.g. a triathlon's swim/bike/run), keeping the parent.",
+  "type": "boolean"
+}

addedInput schema / properties / max_duration_min

Added value: +{
+  "description": "Maximum duration in minutes.",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / max_elevation_gain_m

Added value: +{
+  "description": "Maximum elevation gain in metres.",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / min_duration_min

Added value: +{
+  "description": "Minimum duration in minutes.",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / min_elevation_gain_m

Added value: +{
+  "description": "Minimum elevation gain in metres.",
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / name_contains

Added value: +{
+  "description": "Text the activity name contains (case-insensitive), e.g. 'parkrun' or 'tempo'.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}

First observedv1.1.0Nov 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds what those cannot: the default response shape, that 'full' is expensive so limit should be small, and that sport-specific extras are absent. It does not cover paging behaviour or what happens at limit boundaries, but that is minor given the annotation coverage.

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?

Front-loaded with purpose and the sibling routing, then implementation detail, then exclusions — a sensible order with no filler sentences. The compact-field enumeration is long but each field name is the actual answer to 'is my data here?', so it earns its space.

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 a 20-parameter tool with no output schema, the description does the important work: it explains the return shape, warns about size, and points at the cheaper alternative for aggregation. What remains unspecified is largely covered by the rich schema descriptions.

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 90%, so most parameters are self-documenting. The description still carries the undocumented 'detail' parameter, enumerating exactly which fields compact returns and when to escalate to 'full', which is meaning the schema does not provide. Filters themselves are only listed by category rather than explained.

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 opening sentence gives a specific verb and resource ('List individual recorded activities') plus the concrete downstream value (activity_id for get_activity / get_activity_analysis) and the filter families available. It explicitly distinguishes itself from summarize_activities, so an agent can choose between the two without opening either schema.

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?

It states when NOT to use it ('for totals, averages or trends over weeks/months, use summarize_activities instead'), gives a graduated rule for detail='full' ('only when a field you need is missing, and with a small limit'), and closes off unsupported data (golf scorecards, shot data, dive logs). This is explicit routing guidance with alternatives named.

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

Search activities

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools