garmin_activitiesRetrieve your recent Garmin activities from Garmin Connect, newest first, with optional type filters for running, cycling, and more.
Most recent activities, newest first. activity_type filters e.g. running, cycling.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| activity_type | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation, so the description does not need to restate that. It does add useful ordering context ('newest first') and filter behavior, but it does not mention pagination handling or what happens when no activities are found, so the added transparency is moderate.
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?
The description is very short, front-loads the main purpose, and contains no filler words. It could be slightly more structured by starting with an explicit verb, but every included phrase earns its place.
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?
The tool is simple, has an output schema, and all parameters are optional, so the description does not need to explain return values. However, it omits any differentiation from sibling activity tools and provides no indication of default pagination or how to combine filters, leaving noticeable gaps for an agent trying to choose the right call.
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%, so the description carries the burden of explaining parameters. It only explains activity_type with examples ('running, cycling'); limit and offset are left entirely to their names and defaults. This is only partial compensation for the missing schema descriptions.
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 clearly states the resource ('activities') and the scope ('most recent, newest first'), so an agent can tell it is a listing operation. It lacks an explicit verb like 'list' or 'get', and it does not distinguish itself from sibling tools such as garmin_last_activity or garmin_activities_by_date, so it misses the top score.
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 about when to use this tool versus closely related siblings like garmin_activity, garmin_last_activity, or garmin_activities_by_date. The description only tells what the tool does; it does not provide exclusions, prerequisites, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.