compare_workouts

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

No annotations are provided, so the description carries the full burden. It discloses the comparison logic (same type, similar distance/duration) and reports metrics, and mentions defaulting to most recent activity. However, it does not explicitly state whether the operation is read-only (though 'reports' implies it) or describe any side effects, safety requirements, or limitations. Given the absence of annotations, this is a moderate gap.

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 three sentences, compact and well-structured. The main purpose is front-loaded, followed by output metrics, default behavior, and usage guidance. No redundant phrasing or filler; every sentence adds value.

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 has no output schema, so the description should describe return values. It does list the metrics reported, which helps. However, it fails to explain the 'limit' parameter, does not specify the output format (e.g., a comparison object), and omits potential error conditions or edge cases. Given the tool's moderate complexity and lack of parameter documentation, the description is incomplete but not severely lacking.

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 schema has zero description coverage, and the description only indirectly addresses activity_id by saying 'Defaults to the most recent activity.' The 'limit' parameter is never mentioned or explained. With 0% schema coverage, the description must compensate for both parameters, but it only partially explains one. This is a significant shortfall.

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 tool compares one workout to earlier ones of the same type and similar distance/duration, listing metrics (duration, pace, HR, elevation, calories) and defaulting to the most recent activity. It distinguishes itself from reading a single activity summary, though it doesn't name a specific sibling like get_latest_activity. Overall purpose is clear and 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?

Explicitly states 'Use this when asked how a session went compared with usual, rather than reading a single activity summary.' This provides a clear condition for when to use this tool versus alternatives, though it doesn't mention other siblings like get_activities_range. The guidance is direct and actionable.

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