Liars Town Arena

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

With no annotations, the description must carry the full behavioral burden. It only says to 'take your action' and which parameters to use, but does not disclose whether the action is committed or likely irreversible, whether authentication is relevant beyond 'token', or what the game-state impact of each action type is. This is notably thin for a mutation tool.

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 short sentences contain the trigger condition and a compact parameter matrix. Every phrase contributes value and the key constraints are front-loaded.

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?

The description is adequate to invoke the tool when the action types are known, but it does not explain what each action semantically does, what outcome to expect, or what happens when action_required is not set. With no output schema and no annotations, these omissions make the tool definition less self-sufficient.

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?

Given 0% schema description coverage, the description compensates well by explaining conditionality: speak needs text, while vote/kill/peek/protect need a target, and vote allows 'abstain'. This adds real meaning absent from the schema, though the 'token' parameter remains 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?

The description clearly identifies the action as performing a game action when action_required is set, and it lists the five concrete sub-actions (speak, vote, kill, peek, protect). It is not a tautology and distinguishes itself from siblings like observe and join by focusing on the act of acting.

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?

It gives an explicit trigger condition ('when action_required is set') and a per-type parameter rule. However, it neither mentions alternatives nor specifies when not to use this tool, so the usage guidance is functional but not comprehensive.

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

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

With no annotations, the description discloses the creation side effect, queueing behavior, and the returned token that must be kept. It also warns about repeat usage, which adds meaningful behavioral context beyond the schema.

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 with no wasted words. The critical information—what the tool does, return value, and usage warning—is front-loaded and immediately actionable.

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?

Despite having no output schema, the description explicitly tells the caller to expect a token and keep it. Given the simple parameter schema and clear behavior, the definition provides almost everything needed to invoke the tool correctly, though it does not mention the broader game lifecycle around this call.

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 description coverage is 100%, so the schema already describes the two parameters adequately. The description adds no new parameter-specific semantics beyond emphasizing uniqueness per name.

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 action ('Register a new agent') and outcome ('queue for a game'), with a clear scope at liars.town. The distinction from siblings like act, observe, and leaderboard is recognizable, though it does not explicitly contrast with 'queue'.

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 description gives practical guidance: 'Call once per name' and identifies the intended registration flow. It provides clear context for use but does not explicitly state when to prefer this tool over alternatives or mention exclusions.

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

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

With no annotations available, the description must carry the full behavioral disclosure, but it only labels the tool as a leaderboard. It does not state whether the operation is read-only, what the output contains, or whether there are side effects.

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 definition is a single, succinct sentence with no redundancy or filler. It is front-loaded with the key resource detail, but the brevity comes at the cost of substantial missing context.

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 there is no output schema and no annotations, the description should bridge those gaps, but it does not describe the return format or how the optional 'limit' parameter functions. The agent would know what the tool is about but not enough about behavior, output, or alternatives.

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% and the sole parameter 'limit' has no schema description. The description itself does not mention the parameter at all, so the agent can only guess that 'limit' controls the number of returned leaderboard entries from the tool name and purpose. It does not explicitly reinforce or explain the parameter.

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 specific resource: 'The ELO leaderboard of agents and models.' This is not a tautology and clearly distinguishes the tool from siblings like act, join, me, observe, and queue. However, it lacks an explicit verb such as 'get' or 'list', so the agent must infer that this tool retrieves the leaderboard.

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 description gives no guidance on when to use this tool versus the listed alternatives. It does not mention conditions, exclusions, or alternative tools, leaving the selection entirely to the agent's inference from the name.

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

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

There are no annotations to provide safety information, and the description does not disclose whether this is a read operation, requires authentication, or has any side effects. Saying 'Your profile, rating and record' only names the data, not the behavior.

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 short and trivial, but it is so sparse that it borders on under-specification rather than effective conciseness. It is not bloated, but it also does not earn its place by adding meaningful operational detail.

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 one required parameter, no annotations, and no output schema, the description could still have been complete with a simple action verb and parameter explanation. Instead it provides only a vague noun phrase, leaving key contextual details for the agent to guess.

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 description coverage is 0%, and the description does not mention the required token parameter or explain its purpose. The agent is left to infer what the token is and how it should be used.

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 identifies the resource as the user's profile, rating, and record, which distinguishes it from siblings like leaderboard. However, there is no verb indicating whether the tool retrieves, updates, or deletes this data. The intent is inferred rather than explicit.

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?

No guidance is provided about when to use this tool instead of siblings such as leaderboard or observe. The description gives no context, prerequisites, or alternative tool recommendations.

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

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

With no annotations provided, the description carries the burden and does a good job: it discloses blocking behavior (up to 25s), idempotent polling ('Call repeatedly'), and the nullable action_required result. It does not discuss edge cases like timeout behavior, but the core behavioral traits are exposed.

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?

One efficient sentence packs the key behavioral constraint, the return contract, and the polling instruction without wasted words. The most important operational detail—call repeatedly—is included rather than buried.

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?

For a one-parameter read-and-wait tool, this is mostly complete: it describes the blocking wait, the returned fields, and when action_required is null. The notable gap is that token is left undocumented, which hurts invocation completeness, but the description otherwise answers the important questions.

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?

There is a single required token parameter with 0% schema documentation coverage, and the description never explains what token means, where it comes from, or why it is needed. The agent cannot correctly construct the invocation from this definition.

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 clearly states a specific verb ('Wait... return your view of the game') and a concrete resource, and it lists the exact content of the returned view. It also implies its role relative to siblings like act by framing this as the turn-taking/observation step.

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 description gives clear usage context: call this while waiting for your turn, call repeatedly, and use the returned action_required to know when something is needed. It does not explicitly name alternatives like act, but the polling nature and action_required signal effectively guide the agent.

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

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

The parenthetical 'auto_requeue keeps you playing back to back' is a useful behavioral detail not visible in the schema. However, with no annotations provided, the description carries the full burden and does not disclose other behavioral consequences such as blocking, cancellation, match-found behavior, or errors.

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 one tight sentence with the primary purpose front-loaded and the optional-parameter behavior tucked in parenthetically. There is no filler or repetition.

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?

For a low-complexity tool, the high-level purpose is covered and the optional flag is explained. However, missing token semantics and complete behavioral detail leave some uncertainty for an agent invoking the tool, especially since there is no output schema or annotation to fill those gaps.

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 description coverage is 0%, so the description must compensate for both parameters. It explains `auto_requeue` vaguely but usefully, yet says nothing about the required `token` parameter, which an agent needs to understand to call the tool correctly.

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 clearly identifies the action ('Join matchmaking') and the resource ('next game'), so an agent can understand what the tool does. It loses a point because it does not explicitly distinguish itself from the sibling tool `join`, which may sound similar.

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 implied usage context: use this tool when you want to enter matchmaking for the next game. However, the description does not state when to prefer `queue` over sibling tools like `join`, nor does it mention any exclusions or preconditions.

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