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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the response shape changes with the presence of a pass, and it tells the agent what fields come back (opponent type/callsign, round state, median think time). It stops short of covering error conditions for an invalid or expired pass.

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?

The seat-mode return contents are front-loaded and the arena fallback follows in a compact second clause; no sentence is filler. Some phrasing is dense and jargon-heavy ("median think time with the planForS it gives"), which costs a bit of readability.

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 and only two well-documented parameters, the description carries most of the burden and does so for both operating modes, describing what each returns. It is slightly thin on failure modes (invalid pass, expired seat) but otherwise sufficient to call the tool correctly.

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 would be 3. The description earns above baseline because it explains the semantic effect of the pass parameter's presence versus absence, which the schema does not state. pilotKey is not discussed in the description, but the schema documents it adequately.

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 (seat/arena status) and enumerates the specific contents for the seat mode: queue vs playing, opponent identity and type, round state, median think time and planForS. It also states the second mode (arena: queue populations and running match counts), so an agent can tell exactly what it gets. It does not explicitly contrast itself with sibling tools such as brief or next_report, which keeps it at 4.

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?

"Send pass. Without a pass it shows the arena instead" gives explicit conditional usage that an agent can act on directly, and the schema reinforces the requirement. However, it does not name alternatives (brief, next_report) or state when to prefer them, so the routing guidance is implied rather than complete.

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