garmin-connect-mcp

Overview Schema Source Related Servers Discussions Admin

Get Activity Detail

garmin_get_activity

Read-onlyIdempotent

Retrieve a Garmin Connect activity by ID with summary or full detail, and optionally include structured workout steps. Use it after searching activity IDs to inspect a specific workout.

Instructions

Get one activity in detail by its ID, optionally with its structured workout steps.

detail_level="summary" (the default) returns the ~22 fields that apply to any sport. detail_level="full" returns all available fields, which for a single activity can exceed 200 properties covering dive, golf, and other sport-specific sensors.

Use garmin_search_activities to find activity IDs.

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": "garmin_get_activity"
  }
}

Input Schema

Name	Required	Description	Default
`activity_id`	Yes	Garmin activity ID, e.g. 123456789
`detail_level`	No	'summary' for sport-agnostic key fields, 'full' for every field Garmin returns	summary
`response_format`	No	'markdown' for readable text, 'json' for the exact Garmin field names and values	markdown
`include_workouts`	No	Also fetch the activity's structured workout steps, when it followed a workout
`include_empty_fields`	No	Keep fields Garmin returned as null or empty. Off by default, since unsupported sensors on the user's device produce large runs of nulls. Turn on only to inspect raw shape.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description contributes real behavioral information beyond that: default returns ~22 sport-agnostic fields while full can exceed 200 properties across dive/golf/sport-specific sensors, and empty/null fields are trimmed by default because unsupported sensors produce long null runs. It does not mention payload cost, latency, or rate limits for the 'full' path.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short paragraphs, front-loaded with purpose, then the detail_level distinction, then the sibling pointer. Every sentence carries information an agent would otherwise have to guess.

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 five-parameter read tool with no output schema, the definition covers purpose, the primary verbosity tradeoff, the null-trimming rationale, and ID discovery. The remaining gap is what the response looks like when include_workouts=true or response_format=json, which the agent must infer from schema text alone.

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 100%, so baseline is 3; the description earns above baseline by quantifying what detail_level actually yields (~22 fields vs >200 properties and which sports the extra fields cover), which the terse enum description does not convey. It adds little for response_format or include_workouts beyond what the schema already documents.

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 ('Get one activity in detail by its ID') plus an optional extension ('structured workout steps'). This clearly separates it from garmin_search_activities, garmin_download_activity_file, and the health/wellness siblings without needing to open any schema.

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?

Explicitly routes the agent to garmin_search_activities when it lacks an activity ID, and explains the summary-vs-full tradeoff so the agent can choose a detail level. It stops short of stating when-not to use this tool (e.g., when a file download or trend view is actually wanted).

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

Deploy Server