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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and idempotency are covered. The description adds useful context: forecasts are only listed after a question closes, the Arena number is frozen at close and never official, and points are calculated without money or prizes. However, it doesn't describe pagination, rate limits, or response format beyond what's implied, and some statements (e.g., 'forecasts are listed only after it closes') are behavioral constraints already implied by the read-only, closed-world nature.

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 description is a single dense paragraph that packs multiple concepts (current questions, recent results, standings, points calculation, id behavior, disclaimers) without clear separation or front-loading. It is hard to parse quickly and includes redundant details (e.g., exact points formula, 'Same data as GET /api/arena' which may be unnecessary for an agent). It lacks structure and prioritization.

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?

Given one optional parameter and no output schema, the description provides enough context to know the tool returns Arena data, including questions, recent results, and standings. However, it does not clarify the exact response shape or what fields are returned, and the dense packing makes it incomplete for an agent trying to decide if this tool returns the needed data versus using get_question or open_questions. It covers the domain but leaves gaps in usage and output structure.

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%; the single optional 'id' parameter is fully described in the schema. The description adds context about what happens with id ('with id, one question: forecasts are listed only after it closes'), which clarifies the id's effect but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with 'The Arena: predict the number an index lands on,' which does state a specific purpose and distinguishes the tool from siblings like open_questions or get_question by positioning it as a hub for Arena data. However, it immediately dives into mechanics (index, forecast count, close time) without clearly stating the tool's primary function: returning Arena state (current questions, recent results, standings). The name 'arena' and lack of a clean verb+resource opener leave the purpose somewhat buried.

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?

There is no explicit when-to-use guidance, no mention of alternatives like get_question (for a single question) or open_questions (for active questions). The description says it returns 'the same data as GET /api/arena and GET /api/arena/question/{id}', which implies it can be used for both, but does not clarify when to prefer this tool over those siblings. No exclusions or conditions are stated.

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