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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description goes well beyond them: it discloses partial-result behavior (uploading tracks listed without links), availability caveats (Mac-app-only high-quality screen share), an exclusion (edited tracks), and an auth requirement (Cotlet API key with access to this app). That is exactly the extra behavioral context an agent needs.

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?

Purpose is front-loaded in the first sentence, followed by the file-type note and then the caveats and auth note. Most sentences earn their place, though the enumeration of file types duplicates the schema enum and adds slight redundancy.

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 the description carries the return-value burden and does so: it states one download link per participant for the selected file type and explains the case where a track has no link. Combined with the caveats and permission note, nothing an agent needs to call or interpret this tool correctly is missing.

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 file_type, participants, and recording_id are already documented in the input schema, including the enum values. The description repeats the file_type options rather than adding format/syntax detail, so the baseline 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?

Specific verb+resource: it returns download links for the separate track of each participant in a recording, one per participant. It is clearly distinguishable from sibling reads like riverside_get_recording or riverside_get_transcript, since those fetch metadata/content rather than per-participant media links.

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 gives useful preconditions and exclusions (tracks still uploading have no link, edited tracks must come from an edit export, high-quality screen share requires a Mac-app recording), which imply when this tool will and will not yield results. However, it never names an alternative tool or states an explicit 'use this instead of X' rule, so routing is left to inference.

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