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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the trailing 'Read-only.' adds no new information. The genuinely additive content is the scoping rule (own events vs host events) and the field list returned, but nothing is said about pagination behavior, total counts, or whether the result is scoped by any other account boundary.

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?

Two dense sentences, front-loaded with the resource and payload shape before the scoping rule. The only wasted text is the redundant 'Read-only.' clause, which duplicates the annotations.

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, listing the returned fields compensates well, and all five parameters are documented in the schema. What remains unaddressed for a paginated list tool is whether results include a total or next-page indicator and what ordering to expect.

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; the description earns an increment by explaining the hostId parameter's origin (ids come from universe_get_viewer) and the default no-hostId behavior, which the schema only says as 'Omit for your own events.' limit/offset/search/states add nothing beyond the schema, but they are already fully documented there.

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 and resource plus the returned field set (id, title, url, state, first date, venue, tickets sold), which is far more than a restatement of the name. It partially differentiates itself by pointing at universe_get_viewer for host ids, but does not distinguish itself from universe_get_event (single-event fetch) or the other list_* 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 an explicit conditional: omit hostId to list your own events, supply hostId to list that host account's events. It also names the upstream call that produces hostId. It stops short of stating when to use this versus universe_get_event or why a caller would need the state filter.

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