garmin-connect-mcp

Overview Schema Source Related Servers Discussions Admin

get_last_activity

Retrieve complete details for the last recorded activity, including all metrics and data points from your workout or fitness session.

Instructions

Full detail for the most recently recorded activity.

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

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 18, 2026

TDQS

A3.6/5.0

Behavior3/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. It states 'full detail' which hints at a rich response but does not disclose traits like return format (e.g., list vs. object) or whether it requires authentication. It's adequate but not detailed.

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?

The description is concise: one sentence with no extra words. It front-loads the key promise ('Full detail') and specifies the scope ('most recently recorded'). Could be improved by slightly restructuring for even quicker scanning.

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?

Given there are zero parameters, an output schema exists (though not detailed here), and no annotations, the description is fairly complete. It tells the agent exactly what it will get: full details for the most recent activity. It doesn't explain what 'activity' encompasses vs. siblings, but the scope is narrow enough.

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?

There are zero parameters, and schema description coverage is 100% (no params to document). The description adds value by promising 'Full detail' which implies the no-parameter call returns a comprehensive object. This is clear and useful.

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 clearly states the tool returns 'Full detail for the most recently recorded activity.' The verb 'get' is implied and the resource is 'activity'. However, it doesn't explicitly distinguish what 'activity' means compared to siblings like 'get_daily_summary' or 'get_activity_details', but the focus on 'most recently recorded' separates it from listing or detail-by-ID tools.

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 when to use this tool: to get the latest activity with full detail. However, there is no guidance on when not to use it or alternatives (e.g., for a specific date, use get_activity_details; for a range, use list_activities). The sibling tools are numerous and related, making explicit guidance valuable.

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