srgssr_audio_get_episodes

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that episodes are in descending chronological order. No further behavioral traits (e.g., pagination, rate limits) are disclosed.

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 concise with one main sentence plus structured tags for use case, important notes, and an example. It is efficiently front-loaded with the core action, though slightly more detail in the example could improve clarity.

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 output schema exists but is not shown; the description covers the core purpose and ordering. However, pagination behavior, error handling, and return format are not addressed, making it moderate for a tool with required parameters and pagination.

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 low (only business_unit has a description in schema). The description provides a usage example but does not explain page_size or page parameters, which are left to the schema. More details on parameters would be beneficial.

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 retrieves the latest episodes of a radio show ('Ruft die neuesten Episoden einer Radiosendung ab') and provides a use case ('Auffinden konkreter Radiobeiträge oder Podcast-Folgen'). It distinguishes from sibling tools like srgssr_audio_get_shows and srgssr_video_get_episodes.

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 includes a use case tag and notes chronological ordering, but does not explicitly state when to use this tool over alternatives (e.g., srgssr_audio_get_shows or srgssr_video_get_episodes). No 'when not to use' guidance is provided.

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