get_logged_in_athlete_activities

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

With no annotations provided, the description carries the full burden. It discloses read-only nature and scope requirements, which is useful. It also hints at visibility filtering ('Only Me activities will be filtered out unless requested by a token with activity:read_all'), but this is confusingly worded and does not clearly explain behavior. It does not mention pagination or response structure, leaving some gaps.

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 organized with an endpoint header, a brief description, and scope/read-only notes. It is concise and front-loaded with the main purpose. It avoids fluff, though the phrase 'for a specific identifier' is unnecessary and adds ambiguity.

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 a list operation with optional parameters and no output schema. The description omits key context: it does not clarify that the athlete is the logged-in user, nor does it explain the filtering behavior clearly. It also lacks details on pagination results or default ordering. For a simple read operation, more clarity on what the response contains would be expected.

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 has 100% parameter description coverage, so the schema already documents page, after, before, and per_page. The description adds no additional parameter semantics, so the baseline score of 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?

The description states the tool lists athlete activities and provides the endpoint. However, it says 'for a specific identifier' without clarifying that the identifier is the logged-in athlete, which is only implied by the tool name. It is reasonably distinct from siblings like get_activity_by_id, which fetches a single activity.

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 description mentions required scopes (activity:read or activity:read_all) but gives no guidance on when to use this tool vs alternatives like get_activity_by_id or get_efforts_by_segment_id. It does not state to use this for a list of activities vs a single one. There is no explicit when-not or alternative mention.

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