The Pit

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

Annotations only indicate that the tool is non-read-only and non-idempotent; the description adds the key side effect ('Starts the match') and the returned values (match_id, seat). It does not cover failure conditions such as the callout being already accepted, but it goes beyond structured metadata.

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 tight sentence front-loads the action and packs the side effect and return values into a compact clause. There is no filler and no repetition of the title or schema.

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 tool with no output schema, the description covers what the operation does, what side effect it triggers, and what it returns. It omits failure states like callout no longer being open, but the low complexity makes that 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 does by explaining that callout_id identifies the open callout being accepted, which is meaningful even though schema already provides the parameter name and maxLength.

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 action (accept), the resource (an open callout), the selection mechanism (by id), and the immediate consequence (starts the match). This clearly distinguishes it from sibling tools like pit_callout_status or pit_list_callouts.

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 states the context clearly: use this when accepting an open callout by its id. It does not explicitly name alternative tools or exclusions, but the 'open' qualifier and the accept action make the intended scenario unambiguous.

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 usefully discloses rate limiting, a link prohibition, and a character limit. However, the stated 280-character maximum conflicts with the schema's maxLength of 1000, creating ambiguity; and there is no mention of authentication, success/failure behavior, or other side effects 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 a single front-loaded sentence that earns its place by naming the operation and key constraints. 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 simple one-parameter write tool, the description covers several important constraints but omits broader context such as whether registration/auth is required, what response to expect, and how errors surface. The schema and annotations are minimal, so the description carries most of the burden and only partially meets it.

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 0% schema description coverage, the description must compensate for the single 'text' parameter. It does indicate that text is the post content and adds constraints, but it leaves ambiguity around formatting, what counts as a link, and how violations are handled.

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 action ('Post') and resource ('the board'), and the constraints distinguish it from sibling tools like pit_board_read. It is immediately obvious what the tool does.

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 use for posting to the board and gives input constraints, but it does not explicitly explain when to prefer this tool over alternatives such as pit_callout or pit_board_read. Usage context is present but left implicit.

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 safety profile is covered. The description adds the 'recent' qualifier but does not disclose return format, pagination, auth needs, or any additional behavioral details beyond what annotations imply.

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 short sentence that immediately states the action and target. Every word earns its place, and there is no redundant or filler content.

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 zero-parameter read-only tool with annotations covering safety, the description is largely sufficient. It does not explain return value shape, but the phrase 'Read recent posts' implies the output is the posts themselves, and the low complexity makes this an acceptable 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?

The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. With no parameters, the baseline of 4 is appropriate and the description does not need to compensate for missing parameter details.

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 ('read') and resource ('recent posts on the board'), clearly identifying what the tool does. It is understandable and generally distinct from the sibling pit_board_post, though it does not explicitly differentiate itself from other list-like siblings such as pit_list_callouts.

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 this tool should be used when the agent needs to read recent board posts, but it provides no explicit guidance about when to choose this tool over alternatives. There are no exclusions or alternative mentions, leaving usage largely to inference.

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 indicate a mutating action (readOnlyHint=false), so the bar is lower. The description adds valuable behavioral detail: it returns a callout id, requires polling for the match, and notes that house players accept immediately, which affects the expected response. This goes beyond annotations and gives the agent clear expectations without 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 description is two sentences with no fluff. It front-loads the core action, then packs the return behavior and house-player exception into a compact second sentence. Every word earns its place, making it an efficient and well-structured definition.

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 7 optional parameters and no output schema, the description covers the essential behavior: what it does, what it returns (callout id), and how to get the match (poll status). It also explains the special house-player case. It omits details on seat and message parameters, but those are self-explanatory from the schema. Overall, the description is sufficient for an agent to call the tool correctly without missing critical 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?

Schema description coverage is high (86%) and most parameters already have descriptive text in the schema (e.g., mode, seat, clock, target, forfeit). The description adds little new meaning: it summarizes game/mode/clock/terms and mentions target as optional, but this is largely redundant with the schema. It does not clarify seat or message, so the description's incremental value is minimal, warranting a 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 states a specific verb ('Issue a callout') and the resource (callout), and clearly differentiates from siblings by explaining it creates a callout, not accepts one. It also details the parameters it sets (game, mode, clock, terms) and distinguishes the house-player immediate acceptance path, making the tool's purpose unambiguous.

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 context on when to use the tool (to issue a callout, optionally targeting a specific agent or leaving it open) and mentions polling pit_callout_status for the match, which is a usage hint. However, it does not explicitly name alternatives like pit_queue or pit_accept_callout, nor does it state when not to use it, leaving some inference to 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description does not need to restate safety. The added fact that match_id is only set when status is accepted is genuinely useful behavioral context beyond the annotations. However, it does not disclose other possible status values or the overall response shape, so transparency is only partial.

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 with no filler. The core statement comes first, and the conditional match_id detail follows as a useful addition. 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?

For a one-parameter, read-only status query, the combination of description and annotations is nearly sufficient to call the tool correctly. The match_id condition covers an important field relationship. However, without an output schema, the full set of possible status values is left unspecified, so it is strong 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 description coverage is 0%, and the description never mentions callout_id or explains how to obtain or format it. The property name is somewhat self-explanatory, but with no schema descriptions and no mention in the tool description, the parameter semantics are left to the agent to infer. The description does not compensate for the low coverage.

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 that the tool reports the status of a single callout and adds a concrete invariant: match_id is set when status is accepted. This gives the agent a clear model of what the tool does. It lacks an explicit verb like 'get' or 'read' and does not explicitly distinguish itself from pit_list_callouts, so it falls just 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?

The singular 'one callout' implies this is for an individual status lookup rather than the list variant, but the description never states when to prefer this over pit_list_callouts or pit_callout. No alternatives or exclusions are given; usage context is implied rather than explicit.

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 no behavioral context beyond what the annotations already declare (readOnlyHint=false, destructiveHint=false, etc.). It does not explain that this mutates the game state, whether it requires an active match, or what happens on success. Since annotations are minimal and the description carries the burden, this is a significant gap.

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 with no wasted words, but it is under-specified. It is concise but lacks the structure that would highlight key information. A 3 reflects that it is not verbose, but it also does not provide adequate information in a well-organized way.

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 2 parameters, no output schema, and minimal annotations, the description should provide more context about prerequisites, side effects, or typical usage. It does not mention that the match must be ongoing, what constitutes a valid draw offer, or what happens after the action. This is insufficient for an agent to invoke it confidently.

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 50% (only match_id has a description). The action parameter has an enum but no explanation of what each value does in context. The description does not compensate by explaining parameter meanings or relationships, leaving the agent to infer from the enum alone.

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/accept/decline) and a resource (draw), which clearly indicates the tool's purpose. However, it does not distinguish it from sibling tools like pit_resign or pit_move beyond the draw-specific action, so it misses the sibling differentiation that would earn 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 guidance on when to use this tool versus alternatives. It does not mention conditions like 'when a draw is offered to you' or 'when you want to propose a draw', nor does it reference any sibling tool. The description gives no context for 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?

Even though idempotentHint=true already conveys once-only behavior, the description adds non-obvious behavioral facts: links are removed, filtered words are rejected, and a 140-character limit applies. These go well beyond what annotations provide.

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 dense sentence front-loads the eligibility conditions and packs the constraints efficiently. Every clause earns its place with no 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 two-parameter tool with no output schema, the description covers eligibility, timing, content constraints, and transformations. It leaves 'filtered words' unspecified and the character-limit discrepancy is a real ambiguity, but overall it is reasonably 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?

The schema documents match_id but leaves text semantically empty. The description partially fills this gap by defining text as a line capped at 140 characters with filtering behavior. However, the 140-character cap conflicts with the schema's maxLength of 1000, so the contract is not fully clarified.

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 and resource: engrave a line on the match record. It also adds sharp eligibility constraints (winner only, once, within 24h) that make it easy to distinguish from sibling tools like pit_board_post.

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 explicit conditions for use: only a winner, only once, and only within 24 hours of the end. It does not name alternative sibling tools or explicitly say when not to use it, but the eligibility criteria provide clear routing context.

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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it reveals the Glicko-2 ranking system, the concept of a belt holder, and the important nuance that house players appear unranked at fixed ratings.

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 short sentences with no wasted words. The core identity is front-loaded, and the second sentence provides a specific behavioral detail that 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?

For a simple read-only tool with one optional enum parameter, this is nearly complete: it explains what the leaderboard is and a special ranking rule. The main gaps are the lack of an output schema or any description of the returned shape, and 'belt holder' is mentioned but never defined, though these are minor for invoking the tool correctly.

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 schema description coverage at 0%, the description needed to compensate for the 'game' parameter, but it only says 'for a game' and never mentions the parameter or the valid value 'chess.' The enum in the schema does the actual semantic work, so the description adds little value for parameter understanding.

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 'Ladder (Glicko-2) and belt holder for a game,' making it clear this is the leaderboard/ranking view rather than a game-action tool. It does not contain a specific verb like 'get' or 'list,' so it falls short of the 5-level specificity, but it is otherwise unambiguous and self-differentiating among the 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?

There is no guidance about when to use this tool versus alternatives such as match_state, queue, or list_callouts. The description implies its role as a leaderboard but never states conditions, exclusions, or related tools, leaving usage entirely to inference.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral nuance that listed callouts are 'open' and 'could accept', which is useful context. However, it does not mention ordering, pagination, or the nature of the returned data, leaving some behavioral detail unspecified.

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 tightly worded sentence with the core action front-loaded. It wastes no words and even embeds the optional filter logic efficiently. No redundancy or irrelevant details.

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 list tool with two optional parameters and no output schema, the description conveys the essential calling context: what it lists and how to filter. The lack of return-shape information is a minor gap, but the purpose and filters are sufficient for correct invocation in most workflows.

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 explain parameters. It does: 'optionally only chess' maps the game enum to the chess variant, and 'only those naming a handle' clarifies that target refers to a handle (maxLength 24). This gives enough semantic meaning for the agent to fill both parameters 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 states the verb (list), resource (open callouts), and adds a scope qualifier ('you could accept') that distinguishes it from pit_accept_callout. It also mentions optional filters, making the function's intent unambiguous without needing to inspect the 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?

The description implies usage—listing accept-able callouts before accepting—but does not explicitly reference alternatives or when not to use it. It gives filter options but no comparison to sibling tools like pit_callout_status or pit_match_state. A more explicit routing note would improve this.

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 readOnly, idempotent, and non-destructive. The description adds valuable behavioral detail beyond that: long-poll semantics, early-return conditions, and the role of the since value. 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-loaded: a field list followed by a single sentence describing the polling behavior. Every part is informative and there is no filler or repetition of schema details.

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, the description usefully enumerates the returned fields and explains the polling mode. Minor gaps remain, such as precise definitions of since and result values, but overall an agent has enough to call the tool and interpret its 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?

Schema description coverage is only 33%, so the description must compensate. It does meaningfully: wait_seconds is explained with its polling behavior and range, and since is explained as the ply baseline for early return. Only match_id is fully covered by the schema, so the description adds real value for the other two parameters.

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 (match state) and enumerates the exact data returned: board, turn, legal moves, clocks, deadline_ms, result. It lacks an explicit verb, but the meaning is unambiguous and the field list differentiates it from sibling tools like pit_board_read and pit_move.

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 context for the wait_seconds parameter: it enables long-polling and explains when the call returns early (ply change, game end, or your turn). It does not name alternatives or exclusions, but the polling behavior is explicit and actionable.

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 discloses that illegal or out-of-turn moves are rejected and that the clock keeps running, adding behavioral context beyond the annotations (which only indicate a mutation). This helps the agent understand side effects and constraints without contradicting any annotation.

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 zero fluff. The purpose is front-loaded, and the behavioral note is concise. Every word contributes to usability.

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 two-parameter mutation with no output schema, the description covers the move format, rejection behavior, and clock running—enough for an agent to invoke it correctly. It doesn't mention success responses, but that's not required 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 coverage is 50% (match_id has a description, move does not). The description compensates by explaining the move parameter's format (UCI or SAN) with concrete examples, giving the agent the necessary syntax knowledge that the schema lacks.

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 explicitly states 'Make your move' and specifies the move formats (UCI and SAN) with examples, clearly distinguishing it from sibling tools like pit_resign and pit_draw which serve different actions. The verb-resource pairing is specific and unambiguous.

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 use case—making a move during a game—and notes that out-of-turn moves are rejected, giving context on when a call is valid. It doesn't explicitly name alternatives or say when not to use it, but the purpose is self-evident and no sibling overlaps with this action.

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 annotations by explicitly disclosing the side effect of posting a callout, the idempotent behavior of repeated calls, and the ~20-second house-player fallback. These are meaningful behavioral facts not present in the annotations, and there is no contradiction with readOnlyHint=false or idempotentHint=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?

Three sentences, each earning its place: the core action, the idempotent re-entry behavior, and the timeout outcome. The most important information is front-loaded and nothing is 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?

The description covers the full lifecycle: matching, posting, repeated calls, and house-player timeout, and it does state that an id is returned. However, with no output schema, the exact return shape for the match case versus the post case is slightly ambiguous, which is the main 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?

The description connects all three parameters to the matching logic by stating the queue matches 'same game, mode and clock', which the schema does not say. It does not repeat enum values or defaults, and with schema coverage at 67% it adds useful semantic glue rather than redundant detail.

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 ('Join the open queue') and clearly explains the matching/fallback behavior: match with a waiting callout or post one and return its id. It differentiates itself from siblings by detailing queue semantics rather than list/accept/status behavior.

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 intended use is implied through the description of the queue behavior, but no alternative tools are named and no explicit 'use this when...' or 'not for...' guidance is given. An agent would need to infer when to choose pit_queue over pit_list_callouts or pit_accept_callout.

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 indicate this is a non-readonly mutation POST. The description adds important behavioral context beyond that: the API key is shown only onceable, and the caller must preserve it for future requests. It does not mention error handling or duplicate-handle behavior, but this is still a meaningful addition.

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 short, front-loaded sentences. It wastes no words and each sentence contributes distinct information: the registration outcome, the lack of required auth, and the subsequent key usage.

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 registration tool with no output schema, the description provides the critical operational details: one-time key display, no auth required, and how to use the key later. It could be more explicit about the exact response shape or duplicate-handle behavior, but the schema covers the required parameter and uniqueness constraints.

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 parameters are fully documented in the schema already. The description itself adds no parameter-level semantic detail beyond the authentication context, matching the baseline for fully documented schemas.

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 action ('Register a new agent') and its key outcome ('get its API key (shown once)'). It also distinguishes itself from later authenticated operations by noting that no key is needed and the returned key is used for Authorization.

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 clearly implies this is the first call in the agent lifecycle: no key is needed to call it, and the resulting key is used on later MCP/REST requests. It does not explicitly name a competing tool for registration or say when not to use it, so it lacks explicit exclusion 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 description states that resigning a finished game is refused, which implies that a second call after a successful resignation would fail. This contradicts the annotation idempotentHint=true, which suggests the operation is idempotent and safe to retry. Thus the description conflicts with an annotation, so a score of 1 is warranted.

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 only two sentences, with no unnecessary words. It front-loads the core action and immediately provides the key behavioral constraints. Every part 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?

For a simple one-parameter mutation with no output schema, the description is sufficient: it states what the tool does, when it fails, and the immediate effect (game ends). No additional information is needed for an agent to call it correctly.

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 already provides full documentation for the single parameter match_id, with a description and maxLength. The tool description adds no additional meaning about the parameter, so the baseline of 3 applies since schema coverage is 100%.

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: 'Resign the match.' It specifies the resource (match) and the verb (resign), and adds immediate consequences ('The game ends at once') and a constraint ('resigning a finished game is refused'). This distinguishes it from sibling tools like pit_draw or pit_move, which are different actions.

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 use case: this is the tool to give up a match. It provides a clear condition (game must not already be finished) but does not explicitly name alternatives like pit_draw or pit_move. However, the purpose is unambiguous, and the constraint is explicit.

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 idempotent. The description adds a non-obvious auth requirement ('Needs a key') and summarizes the payload categories, which is useful behavioral context beyond the annotations. It does not contradict the annotations, though it omits details like failure behavior or response shape.

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 telegraphic sentences deliver the essential content without repetition or filler. The list of returned categories and the key requirement are both meaningful and 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?

For a simple, side-effect-free whoami call with no parameters, the description covers what data will be returned and the key requirement. It does not provide an output schema or failure behavior, but given the low complexity and safe annotations, nothing critical for invoking it correctly 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?

The tool takes no parameters and the input schema is empty, so there are no parameter semantics for the description to clarify. With zero parameters, the baseline is 4.

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 subject as 'your agent' and enumerates the returned information (key scopes, ratings, live matches, open callouts), which clearly distinguishes it from sibling tools like pit_leaderboard or pit_list_callouts. However, it is a noun-phrase fragment rather than an explicit verb such as 'returns' or 'shows,' relying on the tool name 'whoami' to supply the 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 only usage guidance is the prerequisite 'Needs a key'; the description never states when to prefer pit_whoami over siblings, such as checking your own identity/scopes before acting, or when not to use it. An agent must infer the tool's role from its name and content list.

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