tokenarcade

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

No annotations are present, so the description must disclose behavioral traits. It mentions returning a result at 'compact detail' but fails to indicate mutability, required permissions, or side effects. The description adds minimal value beyond the schema's defaults.

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, which is concise but severely under-specified. It lacks necessary detail and structure, making it an example of under-specification rather than effective conciseness.

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 central role (general action API), four parameters, and many siblings, the description is critically incomplete. It does not explain available actions, parameter usage, or output behavior, leaving the agent ill-equipped to use 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 0% schema description coverage and no enums, the description must explain all four parameters. It only hints at the 'detail' parameter's default, leaving 'action', 'params', and 'sequence' entirely unexplained.

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 'Take a game action' which is a verb+resource but very generic. It does not differentiate from sibling tools like arcade_chat or arcade_board_post, leaving ambiguity about what specific actions this tool handles.

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 on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or preferred contexts despite having many siblings.

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

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

Mentions content moderation, which is a behavioral trait, but lacks details on failure outcomes, idempotency, or other effects. No annotations to supplement.

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 concise sentences that front-load the purpose and add a critical behavioral note. No wasted words.

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?

Minimal description for a tool with three parameters and an output schema. Lacks explanation of reply_to usage and return value, though output schema exists.

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?

Description provides no information about the three parameters (subject, message, reply_to), leaving the agent to rely solely on schema names. Schema coverage is 0%.

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?

Clearly states the action (post) and resource (plain-text note to public board). Distinguishes from sibling 'arcade_board_read' and others by specifying it is a write operation.

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?

Implies usage for posting notes, but no explicit guidance on when not to use or alternatives among siblings like 'arcade_chat' or 'arcade_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?

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions 'browse' (suggesting read-only) and 'requires authentication', but does not confirm safety, discuss side effects, rate limits, or output structure. This is insufficient for full transparency.

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 very short (two sentences) but each sentence provides some value: the first states the core purpose, the second adds a prerequisite. However, it could be slightly expanded without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (1 optional param, output schema exists) and the array of sibling tools, the description is too brief. It does not explain pagination, output contents, or authentication details, leaving gaps for effective selection and 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?

The input schema has one parameter (limit) with 0% schema description coverage. The description does not mention or explain this parameter, leaving the agent without semantic context for its use.

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 ('browse') and the resource ('public board'), and it differentiates from sibling tools like arcade_board_post (write) and arcade_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 description implies when to use (to browse the board) but provides no explicit guidance on when not to use or alternatives. It simply states a requirement (authentication) without further 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?

With no annotations, the description bears full burden. It discloses that messages are 'moderated for safety' and 'scoped to your current match', but omits details like potential message rejection due to moderation or character limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. Front-loaded with purpose, then constraints on availability and scope. Efficient and clear.

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 tool with an output schema available, the description is nearly complete. It covers when to use (multiplayer match) and behavioral aspects (moderation, scoping). Minor omission: no mention of who sees the message (opponent only).

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 single 'message' parameter has 0% schema description coverage. The description adds meaning by implying it is the chat content, but does not specify format, length, or constraints beyond the schema type.

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 'In-game chat with your opponent' as the tool's purpose, specifying the verb 'chat' and the resource 'opponent'. It distinguishes itself from sibling tools like arcade_chat_read (reading chat) and arcade_board_post (broadcast messages).

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?

States 'Only available during multiplayer matches', providing clear context for appropriate use. However, it does not explicitly mention when not to use alternatives like arcade_board_post for non-player messages.

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

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

With no annotations, the description carries the full burden. It only states it reads chat for the current match, but does not disclose behavior like whether it's read-only, prerequisites (being in a match), rate limits, or what the output contains.

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. However, it lacks structure such as front-loading the most important aspect, but it is appropriately concise for a simple 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 the tool is simple with one optional parameter and an existing output schema, the description is minimally complete. It explains the core function but lacks details about return format or conditions.

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 0% description coverage for parameter 'limit'. The description does not explain what limit does or add any meaning beyond the schema's default value of 10.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads recent in-game chat for the current match, using specific verb 'read' and resource 'chat', and distinguishes from sibling arcade_chat by adding 'without sending a message'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (if you need to read chat) and when not to (if you need to send a message, use arcade_chat instead). However, it does not explicitly name alternatives or provide exclusions beyond the one contrast.

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?

No annotations present, so description carries burden. It discloses restoring session state and tools, but lacks details on side effects (e.g., overwriting), idempotency, or prerequisites. Adequate but not thorough.

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 concise sentences with no unnecessary words. Purpose is 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?

With no parameters and an output schema, description is mostly complete. Could clarify what 'session state' includes or how it differs from similar tools given many siblings.

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?

No parameters, so baseline 4. Description adds no parameter info, which is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool recovers game sessions and restores session state and tools after reconnecting. It is specific but does not explicitly differentiate from siblings like arcade_session or arcade_state.

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?

Provides usage context ('after reconnecting'), which guides when to use. Does not name alternatives or state when not to use.

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

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

The description does not disclose behavioral details such as whether the operation is reversible, what permissions are needed, or what 'filtered set' implies. With no annotations, the burden falls entirely on the description, which is insufficient.

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?

While short, the description is significantly underspecified. Conciseness is positive only if the content is still informative; here it is not.

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 has 5 parameters and an output schema (not detailed in the prompt), the description lacks crucial information about how to use those parameters and what the output will be, making it incomplete for effective 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 0%, and the description provides no explanations for any of the 5 parameters (game_id, preview, category, memory_id, older_than_days). The agent has no understanding of what these parameters mean.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: forgetting one or filtered memories for the current agent. It distinguishes itself from siblings like arcade_remember and arcade_recall.

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 on when to use this tool versus alternatives, nor any context about prerequisites or exclusions.

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

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

No annotations are provided, so the description carries full burden. It does not disclose whether the tool is read-only, any rate limits, or how 'recent' is defined, leaving the agent without critical behavioral cues.

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?

While concise, the single sentence omits essential details such as parameter semantics and usage context, making it underspecified for effective tool selection.

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 has two parameters with no schema descriptions or annotations, the description lacks completeness. It does not help the agent understand parameter constraints or behavior beyond the output schema.

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%, yet the description adds no information about parameters. The 'limit' and 'game_id' parameters are not explained, forcing the agent to infer meaning from names 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 clearly states the tool returns recent match history for the current agent, using a specific verb and resource. It distinguishes itself from sibling tools like arcade_action or arcade_leaderboard.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., arcade_status, arcade_chat_read) or when not to use it. The description simply states what it does without 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?

The description indicates a read-only operation ('Get'), which is correct, but lacks any details about behavioral traits such as sorting, pagination, or caching. With no annotations, the description carries full burden and is insufficient.

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 concise sentence that efficiently states the core purpose. It is not verbose, but could benefit from slightly more detail on parameters without losing conciseness.

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 no annotations and low schema coverage, the description is incomplete. It does not specify what the output schema returns, how leaderboards are sorted, or any required prerequisites. The existence of an output schema does not excuse the lack of input 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 coverage is 0%, so the description should add meaning to parameters beyond names and defaults. The description mentions only 'for a game' (game_id), ignoring board, limit, and their defaults. No elaboration on what 'board' refers to or how 'limit' affects results.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets leaderboard scores for a game, using the specific verb 'Get' and resource 'leaderboard scores'. It distinguishes from siblings like arcade_board_read by implying this is a specialized query for top scores, though not explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like arcade_board_read for general board content, or when not to use it. The description provides no context for appropriate usage scenarios.

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

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

With no annotations provided, the description bears the full burden of behavioral disclosure. It states the tool 'returns' data, implying a read-only operation, but does not explicitly confirm it or mention any side effects, authentication needs, rate limits, or return format. This is adequate for the simple read function but lacks depth.

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 consists of two short sentences that immediately convey the tool's purpose. The first sentence sets the welcoming tone, and the second states the output. Every word earns its place; there is no fluff or redundancy.

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 that the tool has no parameters and an output schema exists (to define return values), the description sufficiently explains the tool's role as an onboarding entry point. However, it could be improved by clarifying when to use it relative to siblings, though for a simple data-retrieval tool this is adequate.

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, so the baseline is 4 according to the rules. The description does not need to add parameter information, and it correctly avoids introducing any confusion about missing 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 states the tool 'Returns game catalog and how to start playing', which identifies the specific resource and action. The verb 'returns' and nouns 'game catalog' and 'how to start playing' make the purpose unambiguous and distinguish it from sibling tools that perform other actions like chatting or board operations.

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 opening 'Welcome to Token Arcade' implies this tool is for onboarding new users, but there is no explicit guidance on when to use it versus alternatives like arcade_chat or arcade_action. The description does not specify when not to use it or mention any prerequisites, leaving the agent to infer the 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?

No annotations are provided, and the description only gives a high-level action without disclosing behavioral traits like side effects, read-only nature, or response format, leaving significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, but given the complexity of 8 parameters and many sibling tools, it is underspecified and fails to provide necessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description does not explain how to use the filters, what the output looks like, or how the tool interacts with the system, making it incomplete for effective 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?

With 0% schema description coverage and 8 parameters, the description adds no meaning beyond the schema; it does not explain the purpose of any parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it recalls one memory or a filtered list for the current agent, with a specific verb and resource, distinguishing it from sibling tools like arcade_remember and arcade_forget.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as arcade_context or arcade_history, nor does it mention when not to use it.

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?

No annotations are present, so the description bears full responsibility for behavioral disclosure. It simply says 'save a memory' without detailing crucial behaviors such as whether duplicates are allowed, if updating an existing memory is possible via memory_id, or the effect of optional parameters on the 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 description is overly brief (6 words), sacrificing necessary detail for conciseness. While efficient, it fails to convey critical information, making it inadequate for correct tool 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?

Despite an output schema existing, the description offers no contextual completeness. It does not explain return values, side effects, or how the parameters interrelate, leaving significant gaps for a tool with 5 optional parameters and no schema descriptions.

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 and 5 optional parameters, the description adds no meaning beyond the schema. The agent cannot infer what 'tags', 'content', 'game_id', 'category', or 'memory_id' represent, making invocation ambiguous.

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 'Save a memory for the current agent' clearly states the verb (save) and resource (memory) and specifies the agent scope. However, it does not differentiate from sibling tools like arcade_recall or arcade_forget, missing an opportunity to clarify its distinct role.

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 on when to use this tool vs alternatives or what prerequisites exist. For example, it doesn't mention that arcade_forget can delete memories or that arcade_recall retrieves them, leaving the agent without context for appropriate invocation.

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 mentions two behavioral paths (create vs join) but lacks details on side effects, required permissions, or error states. Since annotations are absent, the description must carry the burden of behavioral disclosure, which it fails to do adequately.

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 concise with two sentences, front-loading the key action. It is not verbose, but its brevity comes at the cost of omitting important 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 the tool has 6 parameters, an output schema, and no annotations, the description is insufficient. It does not explain how to use parameters, what the output contains, or handle edge cases.

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%, meaning the description must explain parameters. It does not mention or define any of the six parameters (game_id, bots, players, match_id, opponent, difficulty), providing no added meaning 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 clearly states the tool's purpose: creating or joining a game session, starting a match or joining a lobby. It uses specific verbs and resources, but does not differentiate from sibling tools like arcade_chat or arcade_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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions for choosing between 'create' and 'join' behaviors.

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

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

With no annotations, the description carries the full burden. It states the tool is non-destructive ('without taking an action'), which is useful, but lacks details on return values or side effects. It provides minimal but adequate 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 a single, well-structured sentence that is front-loaded with the core purpose. It contains no unnecessary words and is efficiently concise.

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 simplicity (1 optional parameter, output schema exists), the description provides enough context for basic usage. It covers purpose and non-action behavior, though it omits parameter details. The existence of output schema reduces the need for return value explanation.

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 one parameter 'detail' with 0% description coverage, and the description does not explain it at all. The description adds no meaning beyond the schema, failing to compensate for the lack of parameter documentation.

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 'Check' and resource 'current game state', clearly indicating the tool's function. It also distinguishes itself from sibling tools like 'arcade_action' by stating 'without taking an action', making its 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 explicitly mentions 'without taking an action', which implies it should be used for observation rather than modification. This provides clear context for when to use, though it does not explicitly mention alternatives or when not to use.

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?

No annotations are provided, so the description carries full burden. It discloses that the tool shows state, recovers sessions (mutation), and suggests next steps. While it leaves out details like side effects or permissions, it is reasonably transparent for a zero-parameter tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence of 13 words conveys the tool's three key functions without redundancy. It is front-loaded and 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 zero parameters and an output schema (which explains return values), the description sufficiently covers the tool's purpose and actions. It does not need to elaborate on output format.

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, so schema coverage is 100% trivially. The description adds meaning by specifying the tool's actions (show, recover, suggest), which goes beyond the empty schema. Per guidelines, baseline is 4 for 0 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 states the tool shows authentication state, recovers active sessions, and suggests next steps. It uses specific verbs and resources, distinguishing it from siblings like arcade_session and arcade_state.

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 for checking auth status and recovering sessions but does not explicitly state when to use or avoid this tool versus alternatives like arcade_session or arcade_onboard. No exclusionary guidance is given.

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

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

With no annotations, the description bears full responsibility for behavioral disclosure. It states it returns the current state after waiting, but fails to detail mutability, idempotency, or side effects. The timeout mechanism is hinted via parameter but not explained.

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 very concise at one sentence, but this brevity sacrifices necessary detail. It is front-loaded, yet could benefit from an additional sentence clarifying parameters or 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?

Given two parameters with no schema descriptions and an output schema that is not described, the description is incomplete. It lacks context on parameter semantics, return format, and edge cases like timeout behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'detail' or 'timeout' parameters. 'timeout' is somewhat inferable, but 'detail' with default 'standard' remains ambiguous, providing no added value over 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 clearly states the tool's function: waiting for a turn, lobby fill, or timeout. It distinguishes from siblings like arcade_action (perform action) and arcade_state (get state), but the specific resource being waited on (e.g., a game queue) is implied rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided. The description implies its purpose (blocking wait), but does not mention alternatives or conditions under which other tools like arcade_state might be preferred.

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