garmin-mcp-bridge

list_activities

List completed Garmin activities with training load, HR, and elevation. Filter by date range or activity type.

Instructions

List completed activities with training load, HR and elevation.

Args: oldest: Start date YYYY-MM-DD. Defaults to days_back before today. newest: End date YYYY-MM-DD (inclusive). Defaults to today. days_back: Used only when explicit dates are omitted. activity_type: Optional filter, e.g. "Run", "Ride", "Hike", "WeightTraining". Matched case-insensitively.

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

Input Schema

Name	Required	Description	Default
`newest`	No
`oldest`	No
`days_back`	No
`activity_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 21, 2026

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state that only completed activities are listed and what metrics are included, but it omits read-only safety, pagination, ordering, and behavior when no activities match. For a list operation with zero annotation coverage, this is a significant gap.

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?

The first sentence front-loads the tool's purpose, and the Args block is compact with each line adding necessary semantics. There is no filler or repetition, and the structure makes parameters easy to scan.

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 tool with four optional parameters and no output schema, the description covers all inputs and states what data will be returned (training load, HR, elevation). It omits ordering and pagination details, but these are minor for an agent deciding whether and how to invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description fully compensates: it defines the date format (YYYY-MM-DD), the inclusive semantics of newest, the default of oldest relative to days_back, the condition for days_back being used, and activity_type as a case-insensitive filter with examples. Every parameter is given meaningful documentation.

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?

The description opens with 'List completed activities with training load, HR and elevation', which states a specific verb and resource. The word 'completed' distinguishes it from list_planned_workouts, and the enumerated metrics clarify what the tool returns. It does not explicitly name siblings, so it stops short of full differentiation.

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?

The description implies usage for fetching historical activity data and documents defaults and filters, but it never explicitly states when to prefer this tool over get_activity or list_planned_workouts. No alternatives or exclusion conditions are named.

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

Deploy Server