Retrieve recent Garmin Connect activities as trimmed summaries, with an optional limit and raw JSON output for detailed review.
The most recent activities.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return Garmin's full JSON instead of a summary | |
| limit | 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 and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no ordering guarantee (newest-first?), no mention that limit caps results at 50 or defaults to 10, and no hint that the raw flag switches to unstructured Garmin JSON.
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?
One short sentence means no verbosity, but it is under-specified rather than concise; there is no front-loaded purpose, scope, or call guidance an agent could act on.
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 and annotations cover safety, so return format need not be explained. However, for a tool sitting alongside list_activities, get_activity, and a dozen other read tools, the description leaves the essential disambiguation and limit semantics unaddressed.
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 only 50% – the limit parameter has no schema description at all beyond min/max/default – and the description compensates for none of it. It does not explain what the count refers to or how ordering interacts with limit, adding zero value over the schema it accompanies.
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?
The description is a near-restatement of the tool name ('The most recent activities'), adding only the vague qualifier 'most recent'. It does not specify a verb, data source, or how it differs from the sibling list_activities or get_activity, which an agent must distinguish to select correctly.
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?
There is no guidance on when to use this tool instead of list_activities or get_activity, despite those siblings being obvious alternatives. The word 'recent' weakly implies recency filtering but no threshold or selection condition is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.