listActivities

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden and does well on output behavior: it discloses ordering, that many fields are conditional ('when Garmin has them'), date format, and the raw JSON alternative. It omits anything about auth requirements, rate limits, or cost of large limits, which keeps it from a 5.

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 lead is well front-loaded with verb, resource, and ordering. However, the return-field enumeration runs long and reads as an exhaustive dump (SWOLF, strokes, best efforts, run/walk segments) rather than information that helps an agent decide or call correctly.

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?

There is no output schema, so enumerating the returned fields is genuinely necessary and mostly done. Filter semantics and the relationship to getActivity remain underspecified, but an agent can call this correctly with defaults from what is written.

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%, so names, dates, activityType, limit, and raw are already documented. The description only repeats 'Dates are yyyy-MM-dd' and the raw=true behavior and adds no new filter semantics (e.g., how startDate/endDate and names interact). Baseline 3 applies.

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?

A specific verb and resource ('List the user's Garmin activities') plus ordering (most recent first) and a scope hint ('compact summary'). It implicitly contrasts with the detail-oriented sibling getActivity but never names it, so the agent must infer the boundary.

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?

Usage is only implied: 'compact summary' plus the raw=true escape hatch suggests this is the lightweight listing path versus a full single-activity fetch. There is no explicit statement of when to choose this over getActivity, nor guidance on combining date range, names, and activityType filters.

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