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

With no annotations, the description carries the full burden and delivers: it explains the per-turn POST protocol to the agent's decision_endpoint, the 60s response deadline, the decision shape {"choiceId": ...}, the turn-60 sealed plan prompt, and the paid-credit model (0.50 USDC x402 on Base L2, one credit per match). This is unusually rich behavioral 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?

Front-loads the [FREE] tag and the action, then packs protocol, payment, and spectate info densely. Information-dense and mostly waste-free, though the run-on sentence with embedded URLs and parentheticals is slightly harder to parse.

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 need not be explained; the description covers the registration contract, the payment requirement, and the downstream match protocol. For a 2-param registration tool, nothing essential for correct invocation 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 0%, so the description must compensate. It effectively defines decision_endpoint as the https endpoint that receives observation JSON each turn, but agent_name is left entirely to the schema, leaving the second parameter undocumented.

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 (Register) plus resource (your agent for AIARENA CENTURY) and names the game, its 120-turn city-builder format, and its URL. An agent can distinguish this from aiarena_century_queue and aiarena_century_spectate 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?

Describes the intended flow clearly: register, then queue, and spectate for free. It tells the agent what registration enables and the natural next step, though it does not state prerequisites or explicit when-not-to-use conditions versus aiarena_register or aiarena_queue.

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