GarminMCP

get_activity_details

Analyze a specific Garmin activity for a post-workout debrief covering interval execution, lap pacing, HR and power zones, cardiac drift, and weather conditions.

Instructions

Perform a granular post-workout debrief for a specific Garmin activity ID.

Coaching Purpose: Deep-dives into a single completed workout to evaluate interval execution, lap-by-lap pacing stability, time spent in Heart Rate and Power/Pace zones, elevation gain/loss, running/cycling cadence, first-half vs. second-half cardiac drift percentage, and environmental weather stress.

Args: activity_id: Numeric or string Garmin Connect activity ID (obtainable via list_recent_activities). response_format: Output representation: "markdown", "json", or "hybrid" (default).

Returns: Formatted deep-dive workout analysis including lap/split breakdowns, HR zone distribution, power/pace zone distribution, cardiac drift %, pacing assessment, and weather conditions.

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": {
      "activity_id": "<activity_id>"
    },
    "name": "get_activity_details"
  }
}

Input Schema

Name	Required	Description	Default
`activity_id`	Yes
`response_format`	No		hybrid

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are supplied, so the description must carry the behavioral burden. It does disclose the analytical scope and the shape of the output, but leaves unstated whether the call is strictly read-only, what happens with an invalid or non-workout activity ID, whether the data must already be synced, and whether there are throttling limits on Garmin Connect.

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, then Args and Returns are cleanly separated, which makes scanning fast. There is mild waste: the Returns block largely restates what the existing output schema already defines, and the Coaching Purpose sentence is a long comma-list rather than a tighter summary.

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 two-parameter read/analysis tool with an output schema, the definition covers what is needed to select and invoke it: purpose, ID provenance, and output format choice. Remaining gaps are failure modes and error/precondition behavior, which are secondary given the tool's simple, non-destructive shape.

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 description coverage is 0%, so this section is the only source of parameter meaning. It usefully clarifies that `activity_id` accepts numeric or string forms and where to get it, and explains that `response_format` selects markdown/json/hybrid output with hybrid as default — meaning the bare schema enums do not convey.

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 opens with a specific verb+resource+scope: a granular post-workout debrief for a single Garmin activity ID. It enumerates exactly what is analyzed (lap pacing, HR/power zone time, cardiac drift, cadence, weather), which clearly separates it from aggregate siblings like get_health_trends or get_training_status_and_load.

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?

Usage context is clear: this is the tool for deep-diving one completed workout, and it explicitly routes the agent to `list_recent_activities` to obtain the required ID. It stops short of stating exclusions (e.g., use a different tool for multi-activity summaries or for planned/future workouts), so the when-not guidance is implicit.

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

Deploy Server