get_activity_commentsRetrieve all comments posted on a specific Garmin activity using its unique ID. Access discussion feedback for any tracked workout or event.
Get all comments on an activity.
| Name | Required | Description | Default |
|---|---|---|---|
| activityId | Yes | The unique activity identifier (required) |
Changes observed during successful MCP inspections.
v4.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating a safe read operation with possibly unpredictable results. Description adds minimal context beyond that, just stating 'Get all comments'. It does not disclose any potential side effects, auth requirements, or that the list might be empty with openWorldHint. Credit is given because annotations cover the safety profile, but the description provides little extra behavioral detail.
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 with no filler. All words are necessary. Front-loaded with the action and resource.
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?
Given low complexity (1 param), rich annotations (readOnlyHint, openWorldHint), and no output schema, the description is adequate but minimal. It tells the agent what it does, but lacks details on return format or potential edge cases. For a simple read tool, it's sufficient but not comprehensive.
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 100% for the single parameter 'activityId', with a clear description. The tool description does not add semantic meaning beyond what schema provides; it just mentions the activity. Baseline 3 is appropriate as schema does the heavy lifting.
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?
Description clearly states the tool gets all comments on an activity, with a specific verb 'get' and resource 'comments on an activity'. However, it does not distinguish from sibling tools like 'get_all_day_events' or 'get_activity_details', but the resource is specific enough. It is clear but lacks differentiation from other comment-related tools (if any).
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing an activity ID that corresponds to an existing activity, or whether comments are available for all activity types. It does not specify situations where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.