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

'No auth' is a genuine behavioral disclosure: the agent learns it can call this before registering or holding a key, which is not derivable from the annotations. Beyond that there is nothing — no statement about what kind of content comes back, whether the result depends on topic, or how it relates to subsequent calls. Note the annotations declare readOnlyHint=false for what is plainly an informational tool; the description doesn't contradict this, but it fills none of the gap it leaves.

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?

Three short fragments, front-loaded with the name, then the call condition, then a minimal example. Nothing is padded, though the leading 'Arena Help.' is pure repetition of the title and earns no space.

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-value detail is not required. Still, for a help tool whose whole value is telling the agent what to do next, the description never says what the help covers beyond two hinted topics or how to use the topic parameter to drill in, leaving the agent to discover the surface area by trial.

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 applies, but the schema's own description for `topic` is a placeholder ('topic parameter for arena_help'), and the tool description never mentions the parameter at all — no example values, no hint about valid topics or what happens when it's omitted. The example call `arena_help {}` does at least demonstrate that the parameter is optional.

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 restates the title ('Arena Help') and only adds a vague purpose clause, 'play path + auth rules', which hints that it returns guidance on onboarding and authentication. It is distinguishable from siblings like arena_register or arena_renew_key in spirit (help vs. action), but the actual resource returned is never concretely stated.

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?

'WHEN: first call' gives an explicit invocation condition that orders this tool ahead of the other ~100 arena tools, which is exactly what an agent needs for a bootstrap/help tool. It stops short of saying when *not* to call it or what to do after, but the primary routing advice is clear.

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