Lists Garmin Connect workouts with names, IDs, sport, and duration, with pagination controls so AI clients can preview workouts and select IDs for reading or updates.
List workout names, IDs, sport and duration. Other workouts can be read but only [AI] workouts can be changed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| start | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds a genuinely useful caveat about workout mutability ("only [AI] workouts can be changed"), though it sits oddly on a list tool and doesn't explain pagination behavior or coverage across the account.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the returned-fields summary front-loaded; nothing is padded. The second sentence is slightly tangential to a listing operation but is short enough to earn its place as context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values needn't be explained, and the annotations cover safety. However, the pagination contract (defaults, max page size, how to page through) is absent from both the description and the schema, leaving a real gap for an agent listing potentially many workouts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the two parameters (limit, start), so the description carries the burden of explaining paging — and it says nothing about limit, offset, or defaults. An agent must infer from parameter names alone that this is a paginated endpoint capped at 50 items.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ("List workout names, IDs, sport and duration") and it enumerates the returned fields, so an agent knows exactly what comes back. It does not explicitly contrast with siblings like list_activities or list_scheduled_workouts, so differentiation relies on the word "workouts" alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No statement of when to call this versus list_activities, list_scheduled_workouts, or preview_workout, and no prerequisites. The second sentence about which workouts can be changed hints at a downstream workflow but never says to use this tool for that purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.