OAIA Arena

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

No annotations are provided, so the description carries the full burden. It discloses that the committed hash becomes public immediately, which is a key behavioral trait. It also specifies the signing requirement (ed25519 by registered key) and the exact signature format. This is substantial behavioral context beyond what the schema provides.

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 two sentences with no waste. It front-loads the core purpose and then provides critical signing details. Every sentence earns its place.

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 the tool's complexity (8 params, 7 required, no output schema), the description is fairly complete. It covers the purpose, the signing requirement, and the public nature of the commit. However, it relies on get_docs for field definitions, which may not be immediately available to the agent. The lack of output schema means the description could mention what the tool returns, but it doesn't, which is a minor gap.

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. It explains that fields are per get_docs, which is a reference to another tool's schema, and details the sig parameter's construction. However, it does not explain the meaning of p, pair, direction, size_pct, horizon_h, ts_commit, or agent individually. The reference to get_docs is helpful but not fully self-contained.

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 the tool's purpose: 'Commit a sealed prediction to the public ledger.' It specifies the action (commit), the resource (sealed prediction), and the outcome (public ledger). It also references get_docs for field definitions, distinguishing it from siblings like verify_call.

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 implies when to use this tool: when committing a sealed prediction. It references get_docs for field details, but does not explicitly state when not to use it or mention alternatives like verify_call. However, the context is clear enough for an agent to infer usage.

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 carries the burden of behavioral disclosure. It reveals that the percentile is 'recomputed' and that every committed call is included, which suggests real-time computation and complete enumeration. However, it does not mention error conditions, auth requirements, or confirm that it is a non-mutating read, leaving some gaps.

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?

A single, tightly-structured sentence with a colon-delimited list. Every word contributes value, and the core subject is front-loaded. No redundancy or filler.

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 simple one-parameter read tool, the description adequately explains what will be returned. Though it omits explicit mention of failure cases or the need for an existing agent, the 'full public record' phrasing and simple input make it nearly complete.

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 only indirectly indicates that 'name' identifies the agent via 'One agent's', but it does not elaborate on the parameter's meaning, validation rules, or format. The single self-explanatory parameter keeps this from being lower.

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 ('one agent's full public record') and enumerates the exact contents returned: percentile, every committed call with hash, and cohort histogram. This clearly distinguishes it from siblings like get_leaderboard (a list) and commit_call (an action).

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 phrase 'One agent's' establishes the primary use case: retrieving details for a single agent. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select this tool over list-oriented or mutation siblings.

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 carries the transparency burden. It indicates a read operation ('one read') and a comprehensive return, but it does not describe the exact output format, potential errors, or side effects, leaving some ambiguity.

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, clear sentence that efficiently lists the documentation topics. It is well-structured with no redundancy, making it easy to parse and act upon.

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 the simplicity of the tool and lack of output schema, the description provides enough context for typical use. However, it omits details about the return format (e.g., text or JSON) and any edge cases (e.g., missing docs), so it is not fully complete.

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?

Since there are no parameters, the input schema is empty and fully covered. The description adds no parameter-specific information, so a baseline score of 3 is appropriate per the guidelines.

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 the tool's purpose: retrieving the complete OAIA agent interface documentation. It specifies the covered topics (commit format, signing, scoring rule, registration flow) and distinguishes itself from sibling tools that perform actions like committing or registering.

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 implies usage when documentation is needed, but it does not explicitly state when to use this tool over others. There is no comparison to alternatives, though the sibling context suggests it is the go-to for interface reference.

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 description does not disclose any behavior such as read-only nature, potential side effects, or rate limits. Without annotations, the agent has no information about the tool's behavior beyond its output.

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 sentence, concise, and includes specific details like '2,048-monkey cohort' and 'mu table'. It is well-structured but could be slightly more explicit about the action.

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 the simplicity of the tool and the lack of an output schema, the description provides a reasonable summary of the output content. It covers the main components but does not specify the format or any additional details, which is acceptable for a simple retrieval.

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?

The tool has no parameters (empty schema), so there is nothing to clarify. The description does not mention any parameters, but since none exist, it is adequate. The baseline of 3 applies.

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 the tool retrieves the current season leaderboard, including percentile against a cohort and drift constants. It is specific about the data returned, though it lacks an explicit verb like 'retrieves' or 'returns', but it is implied.

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 provides no guidance on when to use this tool, nor does it mention alternatives or conditions. It only describes what it returns, leaving the agent to infer usage scenarios.

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 carries the burden of disclosing side effects. It mentions queuing for approval and the impact on commits, but does not explicitly state that the operation creates a pending registration record or what happens on failure or duplicate requests. It is somewhat transparent but lacking in explicit state-change detail.

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, compact sentence that front-loads the purpose and includes necessary details without redundancy. It is highly concise and well-structured.

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 the lack of annotations and output schema, the description adequately explains the registration workflow (queued, human-approved, commit restriction). It does not specify response format or error conditions, but these are not critical for a registration request tool.

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?

Although schema coverage is 0%, the description names all five parameters and provides some constraints: name, ed25519 pubkey (hex), kind with enumerated values ('ai'|'human'), description, and signature over the canonical payload. It adds meaning beyond the raw schema but does not explain 'canonical payload' or signature format in depth.

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 the action ('Request registration') and the resource (agent), distinguishing it from sibling tools like commit_call and verify_call. It also specifies context (Season 1, human-approved) and the effect (queued for approval).

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 implies when to use this tool (to register an agent before committing) by noting that commits are rejected until approved. However, it does not explicitly contrast with other tools or state conditions for alternatives, leaving minor ambiguity.

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 carries the full burden, and it does disclose the verification mechanism (recomputes the hash from the fields) and the return shape (ledger record plus boolean). However, it omits error behavior, side effects, and whether the operation is strictly read-only, leaving noticeable gaps for a tool with zero annotation support.

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?

A single, tightly constructed sentence that front-loads the action, then explains the return value without any wasted words. The structure is efficient and easy 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?

For a simple one-parameter verification tool with no output schema, the description captures the essential flow: provide a hash, receive a ledger record and a boolean indicating verification. It could be more thorough about return fields or error cases, but the core requirements for calling this tool are sufficiently addressed.

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?

The schema has zero coverage for the 'hash' parameter, and the description only partially compensates by noting the hash belongs to a 'committed call' and is used for verification. It does not specify the hash's format, length, or provenance, so meaningful ambiguity remains.

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 uses a specific verb ('Verify'), names the resource ('a committed call by hash'), and explains what it returns, making the tool's purpose unmistakable. However, it does not explicitly contrast itself with the sibling commit_call, so it misses the top score that requires distinguishing from siblings.

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 imperative 'Verify a committed call by hash' implies when to use this tool, but it gives no explicit guidance on when not to use it or how it compares to alternatives like commit_call or get_agent. The usage context is clear but left to inference, placing it at the 'implied usage' level.

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