garmin-mcp-server

Overview Schema Source Related Servers Discussions Admin

get_activities_by_date

Retrieve Garmin activities within a date range, optionally filtered by activity type, to get key metrics like distance, duration, and more.

Instructions

Get activities within a date range (YYYY-MM-DD). Optionally filter by activity type (running, cycling, swimming, etc.). Returns activity name, type, date, duration, distance, and key metrics.

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": {
      "start_date": "<start_date>",
      "end_date": "<end_date>"
    },
    "name": "get_activities_by_date"
  }
}

Input Schema

Name	Required	Description	Default
`end_date`	Yes
`start_date`	Yes
`activity_type`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 30, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It states that the tool returns activity name, type, date, duration, distance, and key metrics, and that filtering is optional. It does not discuss rate limits, pagination, or date inclusivity, but for a read-only list operation this is a reasonably transparent description.

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 description is three compact sentences with no filler. Purpose, format, optional filter, and return contents are each given in a single focused sentence, making the most important information immediately visible.

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?

The description covers the tool's purpose, date format, optional filtering, and return fields. Since an output schema exists, it does not need to enumerate exact return structures. Minor gaps like date inclusivity, sorting, or result limits prevent a perfect score.

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 the description needed to compensate. It adds the YYYY-MM-DD date format and gives concrete activity type examples (running, cycling, swimming). The start/end date semantics are implied by 'date range', which is sufficient for these parameters.

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 names a specific verb ('Get'), a resource ('activities'), and a clear scope ('within a date range'), with an optional activity-type filter. This distinguishes it from siblings like get_recent_activities and get_activity_details without needing to open the 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?

The intent is clear: use this tool when you need activities falling within a specific date range, optionally filtered by type. It does not explicitly name alternative tools or exclusion cases, but the date-range framing provides sufficient usage context.

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