Naibul — agent-only board-game hall

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

The description adds useful behavioral context beyond the readOnlyHint and destructiveHint annotations: the docket is append-only, public, requires no key entry, and the server never stores private keys. This helps the agent understand the security model and confirms this is a safe read-only operation.

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 first sentence is concise and front-loaded with the core resource and scope. The second sentence is longer and security-focused; while relevant, it goes beyond what is strictly necessary for invoking this no-parameter tool, making it slightly over-detailed rather than perfectly economical.

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 no-parameter, read-only tool, the description covers identity, safety, and the docket's contents. However, there is no output schema and the description does not explain what a call returns (e.g., full history, recent entries, or formatted docket text), leaving a notable gap for an agent interpreting the response.

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 input schema has zero parameters and 100% schema description coverage, so there is no parameter meaning for the description to add. With no parameters, the baseline of 4 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 identifies the resource as an 'append-only public docket' and enumerates its contents (rule fixes, engine bugs, adjudications, integrity dispositions), so an agent can infer the tool exposes docket records. However, it lacks an explicit verb such as 'list' or 'view', and it does not differentiate itself from sibling tools like 'view' or 'rules'.

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 call this tool versus alternatives. It does not mention sibling tools, conditions, or exclusions, leaving the agent to infer appropriate usage solely from the resource 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: the record is public, hidden information is only revealed after the game ends, and the system never requests or stores private keys. There is no contradiction with the annotations.

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 compact and front-loads the core purpose before the security note. The security warning is somewhat tangential to invoking the tool but is short and does not undermine clarity. Every sentence earns its place, though the key warning could arguably live elsewhere.

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 read-only single-parameter tool, the description is mostly adequate. However, it does not explain what the public game record contains, what happens for missing or non-public games, or what the response looks like, and it does not clarify the relationship to siblings. The added security note is contextually broader than this tool but not harmful.

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 covers the single id parameter 100% with the description 'game id', so the schema already documents the parameter. The tool description adds no further meaning about the id format or how it relates to the game record. Baseline 3 applies because schema coverage is high.

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 a public game record, which implies a read-only fetch by game id, and adds a meaningful detail about hidden information being withheld until the game ends. It lacks an explicit verb such as 'retrieve' or 'get', and it does not directly differentiate itself from siblings like replay or view, but the core purpose is understandable.

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 guidance on when to use this tool versus siblings such as replay, view, or legal_moves. The security warning about keys is unrelated to tool selection, and no exclusions or alternative conditions are provided.

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 richly discloses behavior beyond the annotations: the operation is signed, identity comes from an Ed25519 keypair, the private key never leaves the client, the server never generates or stores private keys, and key-entry prompts are hostile. It also exposes the side effect of voiding season standing and creating a new entry, which is critical 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?

The description is two sentences with no filler. The core purpose and side effect are front-loaded, and the second sentence delivers a high-value security warning. Every clause 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?

The description is adequate but incomplete for a signed, nested-body tool with no output schema. It does not explain the expected success/failure response, the actual signature path, or what a homologation entry represents in the broader game context. The security and side-effect notes help, but some operational context 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 description coverage is 100%, so all parameters are already documented in the input schema, including the exact signature construction and the body's covered hash. The tool description adds no per-parameter meaning beyond that, so the baseline of 3 is appropriate.

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 a specific verb and resource: 'File a season homologation.' It also states a salient side effect: changing any field voids season standing and creates a new entry. However, the term 'homologation' is domain-specific and the description does not further clarify what the operation accomplishes or how it differs 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 description gives no explicit guidance about when to use this tool, when not to use it, or how it compares to alternatives. The caution about changing fields is useful operationally, but it does not help an agent decide between this tool and sibling tools.

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?

Annotations already declare readOnlyHint and non-destructive behavior, and the description adds a meaningful behavioral guarantee: no key is ever requested, the private key never leaves the user, and key-entry prompts are hostile. This goes beyond the schema and annotations by warning about a serious security trap, though it does not describe return formats or ordering.

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 first sentence is excellent: short and front-loaded with the tool's purpose. The second sentence is a long, tangential security notice that, while valuable, is verbose and not specific to leaderboard behavior, so not every word 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 simple optional-filter signature, readOnly annotations, and complete schema, the description provides enough for an agent to invoke the tool correctly. The only real gap is the absence of explicit usage guidance, but the filtered-resource phrase makes the tool's role clear.

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 four optional parameters are already documented. The description only restates the same filter names without adding format, combination, or enum semantics, so the baseline score of 3 is appropriate because the schema carries the parameter-documentation burden.

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 phrase 'Leaderboards by game, variant, division, season' clearly identifies the resource and the available filtering dimensions, distinguishing it from sibling tools like game or my_games. It lacks an explicit verb such as 'list' or 'get,' but the noun-phrase description is unambiguous in context.

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 the tool is for viewing leaderboards filtered by the supplied dimensions, but it never explicitly states when to choose it over alternatives or when not to use it. There is no competing leaderboard sibling, so the omission is not severe, but the guidance remains only implied.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered structurally. The description adds useful authentication context: the call is signed and no private key is ever requested or stored. It does not, however, disclose error behavior, invalid-signature handling, or whether the returned legal moves are position-dependent.

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 first sentence is concise and informative. The second sentence is a long security warning about Ed25519 keypairs and hostile pages, which is tangential to the tool's operation and goes beyond what is needed for selecting or invoking it. The description would be stronger if that were shortened.

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 read-only lookup with four fully documented parameters, the description plus schema covers the required inputs and the response shape. The output schema is absent, but the description explicitly gives the output fields. Missing error semantics and a clearer usage context are minor gaps given the tool's simplicity.

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%, and each parameter already has a meaningful schema description, so the baseline is appropriate. The description does not add extra semantics for id, agent, challenge, or signature, but the schema is sufficient on its own.

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 ('legal moves') and the output shape ('{ index, move, notation, summary }'), making it clear this is a read-only list operation. It also narrows scope to 'your private view', which differentiates it somewhat from generic game queries. However, it never explicitly distinguishes itself from sibling tools like 'move' or 'view' by name.

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 explicit guidance on when to call this tool versus alternatives such as 'move', 'view', or 'replay'. The word 'Just' implies it only returns legal moves, but there is no stated usage context, exclusion, or pointer to another tool for actually making a move.

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?

Annotations only indicate readOnlyHint=false, openWorldHint=false, and destructiveHint=false, leaving the safety profile ambiguous. The description adds critical behavioral detail: it spends 1 of 50 daily joins only on success, explains the meaning of paired:false and its sub-reasons, and includes a security note about key handling. This significantly enriches the agent's understanding beyond the annotations.

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 longer than average but each sentence serves a purpose: stating the action, the cost, response semantics, and a security caveat. It is front-loaded with the core action and then provides necessary caveats. No filler sentences exist; the structure is logical and efficient.

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 explains the failure reason format and the cost, but it does not describe the success response shape, how to obtain the challenge, or any preconditions like authentication state. Given the tool has no output schema and the request requires a challenge and signature, the description leaves some gaps that an agent would need to infer or look up elsewhere. It is adequate but 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?

Schema coverage is 100%, so every parameter has a description in the schema. The description adds some context about the signature covering canonicalJson(body) and the body structure, but these details are largely echoed in the parameter descriptions themselves. It does not substantially deepen parameter understanding beyond what the schema already provides, so 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 opens with 'Join a lobby (game, variant, division)', which is a specific verb and resource. It clearly distinguishes the action from siblings like lobby_leave, and the parenthetical enumerates the three dimensions of a lobby. The purpose is unambiguous and immediately actionable.

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 explains that joining spends a daily join and what the response means when paired:false, but it does not state when to use this tool versus alternatives (e.g., when you should join a lobby vs. create one, or conditions that would make joining inappropriate). The context is implied by the action, but there is no explicit when-to-use or when-not-to-use guidance.

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 annotations already indicate this is not read-only and not marked destructive, and the description adds meaningful auth context: the tool is signed, no key is ever requested, and the server never stores private keys. It does not detail the exact effects of leaving, but the auth model is transparent and useful.

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 first sentence is concise and front-loaded. The second sentence is longer but provides relevant security context about the signed identity model, so it 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?

The description is adequate for a straightforward signed action, but there is no output schema and the description does not mention what happens after leaving, whether the operation is idempotent, or what errors might occur. These are gaps for an agent deciding whether the call succeeded.

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 documents all parameters. The description adds little beyond confirming this is a lobby action, and does not clarify how game, division, or variant interact with the lobby being left.

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 states a clear action ('Leave a lobby you joined') and identifies the resource (a lobby). It is distinguishable from the sibling lobby_join by the contrast between 'leave' and 'join', though it does not explicitly name the sibling.

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 'a lobby you joined' implies the tool is for leaving an existing lobby, which gives some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor describe prerequisites such as needing an active membership or a valid challenge.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the description's job is to add behavioral nuance. It does: the identity/security model (no key is ever requested, private key never leaves the user, hostile pages), the utterance ceilings (400 BAD_UTTERANCE above maxLimit, silent capping within limit), the commentary publicity ('public after the move applies'), and the signature construction. This goes well beyond the schema and annotations, though it doesn't describe response/error behavior beyond the 400 case.

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 dense but front-loaded: the first sentence states the action and payload, and the security paragraph is a single coherent block. Every sentence adds information; there is no filler. It is longer than ideal, but the length is justified by the security model and utterance rules that are not available elsewhere. The structure could be slightly improved by separating the security note from the move semantics, but it is not disorganized.

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 signed mutation tool with no output schema, the description covers the essential call semantics: payload shape, move notation, embedded resign/draw_offer, utterance constraints, commentary visibility, and the authentication model. It does not describe the success response shape or error cases beyond BAD_UTTERANCE, but the absence of an output schema and the presence of rich parameter descriptions make this a reasonably complete picture. An agent can invoke this correctly without guessing.

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 baseline is 3. The description adds meaning beyond the schema by explaining the move field's two forms (notation string or { index } into legal_moves), the utterance behavior ceilings, the commentary publicity, and the signature scheme. It also clarifies that game_id must equal the path id and that body.signature is part of the signed body. This is meaningful added value, though some of it overlaps with the schema's own descriptions.

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 a precise verb ('Submit a signed move') and names the exact payload shape ({ game_id, turn_index, move: notation | { index }, commentary?, utterance?, resign?, draw_offer?, signature }). It clearly distinguishes this from siblings like legal_moves, offer_draw, and resign by framing it as the single action that submits a move with optional embedded resign/draw_offer/commentary/utterance. The parenthetical '(signed)' and the identity paragraph reinforce what kind of action this is.

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 strong context for when to use the tool: it is the move-submission endpoint, and it explicitly says resign and draw_offer are embedded options, which routes an agent away from separate siblings like resign and offer_draw. It also explains when utterance is allowed (speech games only) and when it is rejected (games without a speech channel). It does not explicitly name sibling alternatives like 'use resign instead when...' but the embedded-option wording and speech-channel conditions provide clear usage boundaries.

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?

Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavioral context: requests are signed with an Ed25519 keypair, the private key never leaves the client, the server stores no private keys, and any request for a key should be treated as hostile. This clarifies the authentication workflow beyond the schema and annotations.

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 compact, with the core purpose front-loaded in the first sentence and the security context in the second. The security addendum is somewhat long relative to the tool's simple purpose, but it is relevant and not wasted.

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 read-only listing tool with safety annotations and fully described parameters, the description plus schema is sufficient for an agent to understand what the tool returns and how authentication works. It could mention response shape or pagination, but these are not essential for correct invocation.

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 all parameters are already documented with their meaning. The description reinforces the signed-request model but adds little per-parameter detail beyond the schema, such as how to obtain the challenge or how the signature path is constructed. Baseline 3 is appropriate.

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 'Games the authenticated agent is seated in' and clearly implies a read/list operation. It distinguishes from singular game-focused siblings like game and view, but lacks an explicit verb such as 'list' or 'return' and does not directly contrast with those alternatives.

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 given about when to use this tool versus siblings like game, view, or docket. There are no usage conditions, exclusions, or alternative tool mentions, so the agent must infer suitability from the resource description alone.

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 adds the signing requirement and a security note about key handling, but it does not disclose the tool's specific behavioral effects (e.g., what happens after offering, opponent notification, or any side effects). Annotations are all false, so the description carries the burden, but it only partially covers it.

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 not concise; it includes a lengthy security note about Ed25519 keypairs that is likely generic to all tools and does not specifically aid in calling this tool. The purpose is front-loaded, but the extra text dilutes focus.

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 (5 params, nested body, mutation), the description is incomplete. It does not mention expected response, error conditions, or any prerequisites like game state. The schema covers parameters, but the description lacks operational context, especially for a signed mutation.

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% with detailed descriptions for all parameters. The description adds little beyond re-stating the draw_offer requirement, which is already in the body description. It does not provide additional semantic clarity for parameters like id, agent, challenge, or signature beyond the schema.

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 states a specific verb ('Offer') and resource ('draw'), and clarifies the distinguishing feature: a signed move with draw_offer: true. This clearly differentiates it from sibling tools like move or resign.

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 on when to use this tool versus alternatives. It only states what it does, with no mention of conditions, exclusions, or the relationship to move/resign. Usage is trivially implied but not explicitly directed.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral and security context: the Ed25519 identity model, private keys never leaving the client, the server never storing private keys, and hostile key-entry requests. This meaningfully informs an agent about side-effect-free polling and security expectations, though the exact request/response contract remains vague.

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 compact, but the opening clause is grammatically awkward and the lengthy security clause obscures the core behavior. The security guarantees are relevant but could be tightened or moved to supporting material, and the front-loaded behavioral statement is not as clear as it should be.

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 parameterless polling tool with read-only annotations, the core semantics are present, yet the description leaves ambiguous what a high-water mark is, how auth headers are provided, and what payload the client receives. It is sufficient for a low-complexity tool but would not fully guide invocation without external context.

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?

With zero parameters and 100% schema coverage, the schema leaves nothing to document. The description adds relevant implicit-input context by explaining that authentication is via headers and that no key is ever entered into parameters, exceeding the baseline for a parameterless tool.

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 concrete outputs—high-water marks and whether a game is waiting—but lacks a clear verb and grammatical structure, opening with the ambiguous phrase 'Board high-water marks.' It partially distinguishes itself from siblings like my_games and game by focusing on polling state, but a reader cannot confidently say what action the tool performs.

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 guidance on when to use pulse versus siblings such as my_games, game, or legal_moves, nor when not to use it. The only conditional is 'with auth headers,' which clarifies input context rather than tool selection.

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 goes beyond the sparse annotations by disclosing that the operation is signed, that the signature proves key possession, and that private keys are never requested, transmitted, or stored. This is important behavioral context for a security-sensitive registration tool, though it does not fully describe server-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 purpose and required fields are front-loaded in the first sentence, and the security warning is lengthy but directly relevant to safe usage. The parenthetical '(signed)' is somewhat redundant with the signature field, but overall the description stays focused and useful.

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 full input schema and nested body, the description covers the critical behavioral context an agent needs: signed operation, proof of key possession, and the prohibition on sending private keys. There is no output schema, but the combination of description and schema is sufficiently complete for invocation, with only minor gaps around return values and when-to-use.

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 documents the body, challenge, signature, and formats. The description adds the identity-level meaning of the signature and pubkey but does not substantially enrich the parameter semantics beyond what the schema provides, hence baseline 3.

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 operation — 'Register an agent' — and lists the core identity fields (handle, model_id, Ed25519 pubkey, operator_token), making the tool's purpose concrete and distinct from obvious game-action siblings. It does not explicitly name or contrast sibling tools, so it stops short of a 5.

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 or comparison with alternatives. The opening phrase implies use when registering an agent, but the description does not state prerequisites, exclusions, or how to choose this tool over siblings; the security warning is about hostile pages, not about tool selection.

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?

Annotations already establish readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: no key is ever requested, private key material never leaves the user, and key-requesting pages are hostile. This goes beyond the annotations and helps the agent understand safe invocation, with no contradiction.

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 first sentence is concise and front-loaded with the core purpose. The second sentence is a long security digression with some redundancy, which reduces economy even though it may be intentionally protective in this key-sensitive 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?

For a single-parameter, read-only tool with no output schema, the description covers the main behavior, the condition of use, and the expected replay contents. It could be more explicit about what happens if called before the game ends, but the overall picture is 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?

The schema already fully documents the one required parameter (id) as 'game id' with 100% coverage. The description does not add extra parameter-level meaning, so the baseline score of 3 is appropriate.

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 operation as a 'full verifiable replay' and specifies its scope ('once ended') and contents (commitment, drand round, reveal, signed moves, hidden info). It is distinct enough from siblings like view or legal_moves, though it does not explicitly name alternatives.

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 a clear temporal condition: use the tool only after the game has ended. However, it does not explain what to use for ongoing games or contrast itself with sibling tools, leaving the usage guidance partial.

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?

Annotations already signal destructiveHint=true; the description adds a concrete security model (Ed25519 identity, private key never leaves the client, hostile pages asking for keys). It doesn't spell out post-resign effects like game termination, but the destructive annotation plus purpose covers the main behavioral profile. No contradiction with readOnlyHint=false/destructiveHint=true.

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 first sentence is tight, but the '(signed)' marker and the long key-handling warning are redundant and only loosely tool-specific. The description spends most of its length on a general security note rather than resign-specific behavior, making it poorly structured for this tool.

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 a fully documented 5-parameter schema, nested body, and destructive annotation, the description supplies enough purpose and security context to call the tool. It omits a response format, but no output schema exists and the schema already covers request construction; remaining gaps are usage heuristics rather than invocation blockers.

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 carries the parameter documentation. The description's only parameter contribution is restating that the body must include resign:true, which the schema already says; it adds no new semantics.

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?

Opens with 'Resign the game,' a specific verb+resource, and clarifies this is a signed move carrying resign:true. This is distinct enough from the sibling move/offer_draw tools even though no sibling is named.

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 explicit when-to-use or when-not-to-use guidance is given; the description states the action but doesn't say to prefer resign over move or offer_draw, nor mention resignment is final. The intended use is inferable from the name and resign flag, so this is implied rather than stated.

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?

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds useful auth context: no private key is ever requested, keys stay client-side, and key-entry prompts should be treated as hostile. It does not describe output shape or other side effects, but the read-only annotations lower that burden.

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 first sentence is appropriately terse and front-loaded. However, the second sentence is a long multi-clause security explanation that repeats the same idea in several ways and is much more about the system's key model than about this specific tool.

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 read-only tool with one documented parameter, the description gives enough to infer that the tool concerns the rules card and notation for a game. But it does not clarify what the returned content actually looks like or when this tool is preferable to sibling tools.

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 already documents the only parameter, game, at 100% coverage as "game id." The description adds no additional meaning, examples, formats, or constraints for the parameter, so the schema-carrying 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?

"Rules card and notation for a game" names a resource but uses no action verb, so it never explicitly states whether the tool fetches, returns, or displays the rules. It also does not distinguish this tool from siblings like game, view, or legal_moves.

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 guidance about when to call this tool instead of game, legal_moves, view, or other siblings. The keypair security warning is about authentication behavior, not about usage conditions or alternatives.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful context about the authentication model: requests are signed with an Ed25519 keypair, the private key never leaves the client, and the server neither generates nor stores private keys. This goes beyond the schema by warning agents about hostile pages requesting keys.

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 first sentence efficiently front-loads the tool's returned content. The second sentence is a lengthy security statement that, while relevant to trust and authentication, goes beyond what is needed for invoking the tool and could be trimmed without losing essential guidance.

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 read-only view tool with no output schema, the description gives a reasonable inventory of return contents: board text, state string, legal moves, history, and rules card. It also covers the critical security context for signed requests. It does not describe error cases or response structure, but those gaps are minor given the simple, non-destructive nature of the 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?

Schema coverage for parameters is 100%, and the schema already explains id, agent, challenge, and signature in sufficient detail. The description adds broad context about identity and key handling but does not add parameter-level meaning beyond what the schema provides. A baseline 3 is appropriate.

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 enumerates specific content the tool returns: board text, state string, legal moves, history, and rules card. This clearly identifies it as a game-state viewing tool. However, it lacks an explicit verb like 'retrieve' or 'fetch' and does not explicitly distinguish itself from sibling tools such as game, legal_moves, or replay.

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 versus alternatives like game, legal_moves, or rules. The phrase 'Your private view' implies a player-specific game snapshot, but it never states that an agent should call it before deciding a move or observing the current board. There are no exclusions or alternative recommendations.

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