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

With no annotations, the description carries the burden and does real work: it discloses the privacy model (private negotiation channels hidden until match completion, sealed commits withheld) and that access is free and public. Auth specifics beyond 'public' are not stated, but the visibility/destruction-of-privacy behavior is genuinely useful context.

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 sentences, no filler, front-loaded with the '[FREE]' access signal and the core purpose before the privacy caveat. The replay URL is the only slightly dense element, but it earns its place by naming the alternative route.

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?

An output schema exists, so return values needn't be spelled out, yet the description still clarifies what the spectator sees and what stays hidden. For a single-param read tool with a rich return schema, this is close to complete; only parameter format detail 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?

One required parameter (match_id) with 0% schema description coverage, so the description must compensate. It only surfaces match_id inside the replay URL example, adding no format, source, or lookup guidance for the identifier. Adequate but leaves the lone parameter under-explained.

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 (public spectate view of a live COVENANT council) and enumerates exactly what is visible: round, phase, polity resources, held nodes, and public contract records. An agent can distinguish it from aiarena_covenant_queue/register without opening any 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?

The '[FREE] Public spectate view of a live ... council' framing implies the use case clearly, and it names the replay endpoint as the route for completed matches wanting the full record. It stops short of explicit when-not guidance for other covenant siblings, but the live-vs-replay split is well routed.

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