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

Annotations cover the safety profile (idempotent, non-destructive), and the description adds substantial context beyond them: the observable outcome (file appears in the media library and is returned), a named error code and recovery loop, and the post-upload encoding requirement for video. That is exactly the behavioral detail structured fields don't carry.

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?

Front-loads the core action, then the success outcome, then the error recovery, then the video caveat. Every sentence carries information, though the sentences are dense and the encoding sentence packs several clauses, slightly reducing readability.

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?

With no output schema, the description compensates by explaining what is returned (the media file) and what the error response looks like (UPLOAD_INCOMPLETE naming parts, issues.errors). An agent has everything needed to call it correctly and handle both outcomes.

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?

Only one parameter with 100% schema description coverage, so the schema already documents uploadToken fully. The description adds marginal value by noting the token is reused on retry ('same token'), but no format or syntax beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb (finish) and resource (upload), and explicitly ties itself to the lifecycle step 'started with livereacting_upload_file, after every part has been sent'. This distinguishes it immediately from livereacting_upload_file and the other media siblings.

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?

Gives the when ('after every part has been sent'), the failure path (missing/wrong-size part returns UPLOAD_INCOMPLETE and names the parts, re-send then call again with the same token), and routes to an alternative (livereacting_encode_media or a running encode) when issues.errors is non-empty.

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