afl_broadcast_events

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds value by disclosing 'Auth: none needed' and documenting the exact return shape, including lazy fields like pageInfo and the nested channels/contentReference arrays — useful context the annotations don't provide.

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?

Compact and well-structured: a one-line purpose, a precise return-type sketch, and an auth note. The main intent is front-loaded and every sentence earns its place. Slightly trimmed from a 5 only because the return shape could be one line tighter.

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 correctly carries return-type documentation, and it covers auth. But it does not explain the semantics of the contentReference object or the relationship to sibling broadcast tools, which an agent needs to fully interpret results or choose this tool. Adequate but with clear gaps.

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% with all five parameters individually documented in the input schema (round, toDate, fromDate, pageSize, compseason with defaults and ISO 8601 notes). The description adds no parameter-level meaning beyond that, 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?

The description states a clear verb+resource ('Broadcast schedule') and adds a distinguishing detail ('one entry per match per channel') that explains the data granularity. However, it does not explicitly differentiate itself from closely-named siblings like afl_broadcast_match_events or afl_broadcast_event_get, which remain ambiguous in scope.

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?

No guidance on when to use this tool versus the sibling broadcast tools: afl_broadcast_match_events, afl_broadcast_event_get, afl_broadcast_channels, or afl_broadcast_regions. The description provides no exclusions or selection context (e.g., 'use this for schedule-level queries, use X for match-level details'), leaving an agent to guess which sibling fits.

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