Garmin MCP

Summarize activities

summarize_activities

Read-onlyIdempotent

Aggregate Garmin activities by date range or named period to calculate totals and trends for distance, time, elevation, pace, heart rate, and training load.

Instructions

Best tool for activity totals and trends (e.g. 'how far did I run each month', 'has my pace improved'). Fetches every matching activity in the range and returns only aggregates per period and type: count, distance (km and mi), moving time, elevation, longest, average speed and pace (distance-weighted), fastest average pace, average HR, training load, and time in HR zones 1-5 (minutes and %, for zone 2 / 80-20 questions). Range up to 366 days.

Input Schema

Name	Required	Description	Default
`area`	No	Only activities that started inside this latitude/longitude box (decimal degrees).
`period`	No	Named period resolved in the user's time zone (weeks start Monday). Use instead of start_date/end_date.
`end_date`	No	Last day, YYYY-MM-DD, inclusive. Defaults to today.
`group_by`	No		month
`event_type`	No	Only activities tagged with this event type, e.g. race.
`start_date`	No	First day, YYYY-MM-DD, inclusive. Required unless period is given.
`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.2/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 openWorld, so the safety profile is covered; the description adds real operational context by disclosing that it fetches every matching activity and returns only aggregates, plus a hard 366-day range limit. It doesn't mention cost/latency of the full scan or what happens with zero matches, which would have pushed it higher.

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?

Two sentences, front-loaded with the qualifying purpose and then the return payload; the parenthetical examples and zone 2/80-20 hint all carry routing value. The dense metric enumeration is long but each item answers 'will this tool give me X', so little is wasted.

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?

With 16 parameters and no output schema, the description compensates by enumerating the returned aggregate fields (count, distance in km and mi, moving time, elevation, weighted pace, HR zones), which is exactly the missing information. Combined with the 366-day bound and grouping semantics, an agent has enough to call and interpret it correctly.

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 coverage is 94%, so the schema already explains nearly every parameter and the baseline applies. The description only implicitly clarifies that results are grouped per period and type, without touching the group_by enum values (week/month/weekday/total) or defaults, so it adds little beyond structured fields.

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 ("activity totals and trends") and anchors it with concrete example questions ('how far did I run each month', 'has my pace improved'), which separates it from list-style siblings like search_activities. The explicit output enumeration (aggregates per period and type) makes the aggregation purpose unmistakable.

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?

The example questions give strong routing signals for when to pick this over raw-list tools, and "Best tool for..." frames the preferred choice for trend questions. It never explicitly names an alternative (e.g. search_activities or get_activity) or states when NOT to use it, so it falls short of full when/when-not guidance.

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

Summarize activities

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools