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

Annotations only declare the generic write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description carries real added weight: it discloses the hidden one-hour default if duration is omitted, plan-tier constraints on 1080p/4K formats, and the hard 8-hour cap for Facebook-only streams. These are non-obvious operational limits an agent could not infer from structured fields.

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 and next steps are front-loaded, and the dense guidance sentences all carry distinct information. It is on the long side and restates the one-hour default that already appears in the duration schema, which is minor redundancy rather than padding.

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?

For an 8-parameter creation tool with no output schema, the description covers intent, sequencing, and the major limits well. The one gap is that it never indicates what is returned (presumably a project id needed for the chained calls), leaving the agent to discover the handle for subsequent tools on its own.

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 coverage is 100%, so the baseline is 3, but the description adds decision-level meaning: it explains which duration shape to send for each streaming scenario and that autoSynch should be paired with the manual 24/7 case. It also reiterates that destinationIds come from livereacting_list_destinations and cannot be created here, reinforcing the cross-tool constraint.

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 opens with a specific verb+resource ('Create an empty LiveReacting project') and immediately frames it as 'the first step of building a stream' with 'no scenes and no content', which cleanly separates it from sibling tools like livereacting_create_scene_with_playlist or livereacting_update_project.

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?

It explicitly sequences the workflow: 'call livereacting_create_scene_with_playlist next... then livereacting_start_stream or livereacting_schedule_stream'. It also branches on intent, telling the agent exactly what to pass for a 24/7 looping channel versus a self-terminating stream, and notes what cannot be done here (privacy settings, advanced YouTube options, destination creation).

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