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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral value: it enumerates the returned fields, explicitly rules out stream keys, and discloses the auth requirement (Cotlet API key with access to this app). Pagination behaviour is not mentioned, keeping it short of a 5.

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-loaded and short, but the field list is stated twice in consecutive sentences ('with start time, streaming method and status' then 'with its start time, streaming method...'), which is wasted repetition in a three-sentence description.

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's field enumeration plus the explicit 'never returns a stream key' caveat covers most of what an agent needs. The auth requirement is stated. The only real gap is pagination/list-scope behaviour for a paginated list tool.

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 limit, cursor and search are already documented in the schema, and the description adds nothing about filtering, paging or cursor reuse. Baseline 3 applies when the schema carries the parameter burden.

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 names the resource (live events) and enumerates exactly what each item carries (start time, streaming method, publication status, preregistration flag), which distinguishes it from write siblings like uscreen_create_live_event. It never states the verb outright (the 'list' comes only from the tool name), but the read-and-enumerate framing makes the purpose unambiguous.

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 one routing cue is 'It never returns a stream key; create_live_event does that once', which sends the agent to the right sibling for a different need. There is no positive guidance on when to call this listing (e.g. to audit upcoming broadcasts, to find an event id) and no exclusions against the other uscreen list tools.

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