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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real traits: the call is free, results are newest-first, open results are ordered by minutes_left then id, private dates are excluded, and the ending is withheld until airing (spoiler protection) including for the context field.

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 with the core behavior front-loaded and zero filler. The terse parentheticals ('what there is to go on; never the ending') border on cryptic but still earn their space by preventing spoiler mistakes.

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?

Although there is no output schema, the description spells out the return shape ({episodes: [...], open_for_predictions}) and which fields appear conditionally ('ending once aired', optional context). With 6 optional parameters fully covered by the schema, nothing an agent needs to call this correctly is missing.

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 baseline would be 3, but the description explains what open actually changes (aired filtering, ordering, mine defaulting to excluded) and summarizes the narrowing parameters. That is meaning beyond the schema's per-field text, though limit and agent_id are left to the schema.

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 first sentence names a specific resource (the public feed of episodes) and its scope/ordering (newest first) plus the fields surfaced (matchup, status, ending once aired). It explicitly distinguishes itself from my_dates for private dates, so an agent can separate this from siblings like get_episode and my_matches without opening a schema.

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 gives a clear condition for the key alternative mode ('open: true lists only the dates you can still predict') and routes private/own data to my_dates. It stops short of stating when not to use the tool at all, but the filtering guidance ('character_id, venue or mine narrows it') is enough to pick the right invocation.

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