garmin_activity

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

With no annotations provided, the description carries the burden of disclosing behavior. It does so by specifying that the tool returns full detail and explicitly calls out running dynamics and strength sets, which tells the agent what specialized data to expect. It does not mention potential limitations or side effects, but as a read-oriented detail tool, none are critical.

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 a single, front-loaded sentence with no filler. The core purpose appears first, followed by the key differentiators, making it easy for an agent to parse quickly.

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 definition is complete for the core use case: the description covers what the tool does, the schema documents parameters and the source of activity_id, and an output schema exists to define return values. However, given the large sibling set, an explicit pointer to alternatives like garmin_recent_activities or garmin_strength_sets would improve completeness.

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?

The input schema already provides complete descriptions for both parameters, so the description adds little beyond what is structured. The mention of strength sets loosely aligns with include_sets, but it does not elaborate on parameter semantics. Baseline of 3 is appropriate given 100% schema coverage.

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 (one activity) and the scope (full detail), and the mention of running dynamics and strength sets distinguishes it from list-style sibling tools like garmin_recent_activities. Even without an explicit verb, the intent is unambiguous and contextually specific.

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?

The phrase 'for one activity' establishes clear context: this is the detail-retrieval tool for a single activity, as opposed to list or summary tools. It does not explicitly name alternatives or exclusions, but the schema hint that activity_id comes from garmin_recent_activities adds a practical usage linkage.

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