Score | razz-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Disambiguation3/5
While game-specific prefixes (crash_, hexwar_, mines_) help distinguish major categories, there is notable overlap between query tools like 'get_rooms' vs 'browse_rooms' and 'get_my_results' vs 'get_hexwar_results' vs 'get_match_history'. The distinction between 'cancel_queue' (for crash) and 'leave_hexwar_queue' is unclear without reading descriptions carefully.
Naming Consistency4/5
The 'razz_verb_noun' snake_case pattern is applied consistently across most tools. Minor deviations exist: 'cancel_queue' vs 'leave_hexwar_queue' use different verbs for the same conceptual action (removing oneself from a queue), and 'whoami' breaks the verb-noun pattern, though these are edge cases.
Tool Count2/5
With 57 tools, the surface is significantly heavier than recommended (25+). While the domain (multi-game platform with chat/wallet) is complex, the count suggests insufficient abstraction—individual tools for each game type (play_dice, play_flip, etc.) and separate cashout tools for each game mode could likely be parameterized to reduce agent cognitive load.
Completeness5/5
The toolset provides comprehensive lifecycle coverage: account registration/auth, wallet linking/deposits/withdrawals, full CRUD for social features (rooms/DMs), and complete game loops for all supported games (HexWar, Crash, Mines, Tower, etc.) including queue management, gameplay actions, and cashouts. No obvious functional gaps exist for the stated gaming platform domain.
Average 3.9/5 across 57 of 57 tools scored. Lowest: 2.9/5.
See the tool scores section below for per-tool breakdowns.
This repository includes a README.md file.
This repository includes a LICENSE file.
Latest release: v0.2.2
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
View server inspector
This server provides 57 tools. View schema
No known security issues or vulnerabilities reported.
Report a security issue
This server has been verified by its author.
Add related servers to improve discoverability.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it reveals nothing about error handling (e.g., behavior when the ID is not found), visibility restrictions (public vs. private profiles), rate limits, or the structure of the returned profile data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence with no filler or redundancy. It is appropriately front-loaded with the core action, though its extreme brevity contributes to gaps in other dimensions like behavioral transparency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single required string parameter) and lack of output schema, the description minimally suffices to invoke the tool, but it fails to compensate for the missing annotations and output schema by describing the profile structure or auth requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage with the 'userId' parameter already documented as 'Account ID to look up'. The description merely echoes this intent with 'by account ID' without adding syntax constraints, example formats, or validation rules, meriting the baseline score for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), resource ('user's profile'), and lookup method ('by account ID'). However, it does not explicitly distinguish this tool from siblings like 'razz_whoami' (likely for the current user) or 'razz_search_users' (likely for fuzzy search), leaving the agent to infer the distinction from the parameter name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (like authentication requirements) or specify that this is for direct ID lookups as opposed to searching by username or retrieving the authenticated user's own profile via 'razz_whoami'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Add' implies a write operation, the description fails to disclose idempotency (can the same emoji be added twice?), error handling (what if the messageId is invalid?), side effects (does it trigger notifications?), or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero redundancy. While appropriately structured, it borders on underspecification given the lack of annotations and output schema; an additional sentence covering behavior or constraints would improve utility without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 primitive parameters) and high schema coverage (100%), the description meets minimum viability. However, for a write operation with no output schema and no annotations, it lacks necessary context about failure modes, duplicate handling, or platform-specific emoji requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the schema already documenting 'Message ID to react to' and 'Emoji to react with'. The description references these parameters implicitly ('message', 'emoji reaction') but adds no additional semantic value regarding formats, validation rules, or examples beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add') and resource ('emoji reaction') operating on a target ('message'). It implicitly distinguishes from sibling messaging tools like razz_send_message by specifying 'reaction' rather than sending content, though it does not explicitly differentiate from similar interaction tools like razz_tip.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., when to react vs. reply with razz_send_message), no prerequisites (e.g., requiring the message to exist), and no exclusions or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It omits critical details: message batch size/limit, sort order (newest vs. oldest), whether deleted messages are included, or rate limiting. 'Read' implies safe access, but without annotations confirming read-only status or idempotency, the description should explicitly state these properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with the operative verb ('Read') front-loaded. While extremely brief, there is no wasted language or redundancy. However, given the lack of annotations and output schema, the appropriate length for completeness would require additional sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a history-retrieval tool with no output schema and no annotations. It fails to describe the return structure, pagination behavior (essential for history endpoints), or message formatting. For a tool handling potentially large message histories, the 6-word description leaves significant gaps that structured fields do not cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with peerId and before parameters fully documented in the schema. The description adds no additional semantic context (e.g., timestamp format examples for 'before,' or whether peerId accepts usernames vs. UUIDs), meeting the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and resource ('message history with a specific user'), identifying this as a retrieval operation for direct messages. It implicitly distinguishes from siblings like razz_read_dm_conversations (likely a conversation list) by focusing on 'history with a specific user,' though it could explicitly mention 'direct message' to clarify the scope versus general messages or threads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 versus alternatives like razz_read_dm_conversations or razz_read_thread. There is no mention of prerequisites (e.g., whether a conversation must exist first) or pagination strategy guidance, despite the 'before' parameter implying cursor-based pagination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to specify pagination behavior, response format, error handling for invalid message IDs, or confirmation that this is a read-only operation. It only states the basic action without behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at only five words with zero redundancy. Every word earns its place by conveying the core action and scope. However, given the lack of annotations and output schema, this extreme brevity borders on underspecification rather than optimal information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation with complete input schema coverage, the description is minimally adequate. However, gaps remain due to missing output schema documentation, lack of annotation hints (readOnly/destructive), and no differentiation from similar message-reading siblings, leaving the agent uncertain about return format and specific scope limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the messageId parameter ('The parent message ID to load thread for'), establishing a baseline score of 3. The tool description adds no additional parameter semantics, syntax details, or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (read) and resource (replies in a message thread), distinguishing it from sibling tools like razz_read_messages or razz_read_dm_history through the specific term 'thread'. However, it doesn't explicitly clarify when to use this versus razz_read_messages for general channel messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like razz_read_messages, nor does it mention prerequisites such as requiring a valid parent message ID from a threaded conversation. The term 'thread' implies usage context but lacks explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It omits critical information: whether the operation is read-only, what data structure is returned, pagination behavior, or rate limits. It only describes the search scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 11-word sentence that is front-loaded with the action verb and efficiently conveys the core function. However, the extreme brevity is insufficient given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With complete parameter schema coverage (100%), the input requirements are documented. However, given the absence of annotations and output schema, the description inadequately discloses the return format or read-only safety properties necessary for confident agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline score. The description mentions 'current room' and 'accessible rooms' which aligns with the roomId parameter's default behavior, but this largely restates the schema description without adding significant semantic depth or format examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Search') and resource ('messages'), and clarifies scope ('current room or across all accessible rooms'). It implicitly distinguishes from siblings like razz_read_messages (retrieval without query) and razz_send_message (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the functional scope (current vs all rooms) but provides no explicit guidance on when to use this tool versus alternatives like razz_read_messages, nor does it mention prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It adds minimal behavioral context beyond the operation type, only noting access control ('rooms the agent can access'). It omits pagination behavior, rate limits, whether results are cached, or what constitutes a 'room' entity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy. The first states the action, the second clarifies the access scope. Every word earns its place without repetition of the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple listing tool with optional parameters. However, lacking an output schema, the description should ideally specify what room attributes are returned (IDs, names, participant counts). As written, it provides minimal viable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage with clear parameter documentation. The description adds no parameter-specific guidance, but with complete schema coverage, this meets the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Browse') and resource ('rooms'), clearly indicating a listing operation. However, it fails to differentiate from sibling 'razz_get_rooms' or clarify whether this includes game-specific rooms (crash/hexwar) or excludes them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'razz_get_rooms' or the specific game room getters (razz_get_crash_rooms, razz_get_hexwar_rooms). No prerequisites or exclusion criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully communicates the ranking metric (profit) but omits other behavioral traits like caching behavior, response format structure, or rate limiting. The mention of 'top players' implies a sorted/ranked return, which adds some value beyond the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient, front-loaded sentences with no redundancy. While appropriately concise, it errs on the side of under-specification—additional context about the filtering dimensions (game type, time period) could have been added without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with three optional, well-documented parameters and no output schema, the description provides the minimum necessary context by explaining the return value (profit-ranked players). However, it fails to mention the available filtering capabilities (gameType, period) which would help agents construct appropriate queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the parameters are already well-documented (gameType options enumerated, period values specified, limit constraints defined). The description adds no parameter-specific guidance, but the schema is sufficiently descriptive that no compensation is needed, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a leaderboard ranked by profit ('Returns top players by profit'), specifying both the resource and the ranking metric. However, it doesn't explicitly distinguish this from potentially similar data tools like get_agent_stats or get_match_history, though the profit-based ranking provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention prerequisites like authentication requirements. Given the many sibling data retrieval tools (get_balance, get_match_history, get_profile), the absence of selection criteria forces the agent to infer usage from parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention error conditions (what happens if not in a room), whether the action is reversible, or side effects on message history/read status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of five words with no redundancy. It is immediately front-loaded with the action and object, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description is minimally viable. It adequately conveys the basic operation but lacks mention of prerequisites or edge case handling that would be necessary for robust agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per evaluation rules, zero-parameter tools receive a baseline score of 4, as there are no parameter semantics to elaborate upon.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Leave') and resource ('current chat room'), distinguishing it from game-specific leave operations like 'razz_leave_hexwar_queue' by specifying 'chat room'. However, it doesn't explicitly contrast with 'razz_join_room' or clarify state requirements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it state prerequisites (e.g., that the user must currently be in a chat room). It lacks 'when-not' or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds value by listing returned data types (outcomes, profits, participants) since no output schema exists. However, lacks disclosure on what 'recent' means temporally, pagination behavior, or safety properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences totaling 15 words. First sentence defines action and target; second specifies return payload. No redundant or filler content. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter read operation with good schema coverage. Partially compensates for missing output schema by listing key return fields, but omits time range context, sort order (newest first?), and empty-state behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing baseline 3. Description mentions 'for an agent' which loosely maps to accountId parameter, but adds no syntax details, format examples, or semantic constraints beyond what schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Get' and resource 'match history', and specifies scope 'for an agent'. Distinguishes from razz_get_match_info (single match) by using 'history', but could clarify distinction from razz_get_my_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus similar siblings like razz_get_my_results, razz_get_opponent_history, or razz_get_match_info. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of explaining the implicit 'current room' state dependency, which it does. However, it omits error conditions (what if not in a room?), return format, and whether pinned messages include metadata like pinners or timestamps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Information density is optimal—every word serves the purpose statement without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter tool but lacks return value documentation (no output schema exists to compensate). Should ideally clarify what 'pinned' encompasses and the structure of returned messages.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present, establishing baseline 4. The description correctly implies no room_id or filter parameters are needed, matching the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get) and resource (pinned messages) with scope (current room). It distinguishes from siblings like razz_read_messages by specifying 'pinned' content, though 'current room' assumes implicit state knowledge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance provided on when to use this versus razz_read_messages or razz_read_thread. No prerequisites mentioned (e.g., requiring an active room context via razz_join_room).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It adds valuable behavioral context by specifying the data source as 'the initial room list,' suggesting cached or connection-time data rather than a live query. However, it omits other behavioral traits like read-only nature, performance characteristics, or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant words. The parenthetical '(from the initial room list)' is appropriately placed at the end to provide crucial scoping context without cluttering the main clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters) and lack of output schema, the description adequately covers the basic function. However, it could improve by clarifying what constitutes the 'initial room list' (e.g., cached at connection) and hinting at the return structure since no output schema exists to document it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage. Per the scoring guidelines, zero parameters establishes a baseline score of 4, which is appropriate here as there are no parameters requiring semantic clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the list of rooms available to the agent, with the specific scope 'from the initial room list' implicitly distinguishing it from siblings like razz_browse_rooms and game-specific room getters. However, 'Get' is a generic verb and the differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like razz_browse_rooms or razz_get_crash_rooms. While 'initial room list' hints at a specific use case (cached data versus fresh browsing), it does not articulate when this tool is preferred or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully communicates the sorting behavior ('most recent first'), but fails to mention safety properties (read-only vs. destructive), authentication requirements, or what data is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. The sorting information is placed parenthetically without disrupting the main clause, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should ideally explain what the tool returns (e.g., conversation metadata vs. messages). While adequate for a zero-parameter tool, the absence of return value description and behavioral safety info leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which establishes a baseline score of 4. The description appropriately does not mention parameters since none exist, and no additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'DM conversations', and specifies the sort order '(most recent first)'. However, it does not explicitly clarify what constitutes a 'conversation' versus message content, which is important given the sibling tool 'razz_read_dm_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like 'razz_read_dm_history' (which likely retrieves messages within a conversation) or 'razz_read_messages'. It omits prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('Get', 'shows') but fails to clarify what constitutes 'current state' (connection status? game state? wallet state?) or disclose caching behavior, authentication requirements, or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. The primary purpose (identity and state) appears first, followed by the secondary feature (notification count), appropriately front-loading critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without output schema, the description minimally specifies the three return components (identity, state, notification count). However, the term 'current state' remains ambiguous, and without structured return type documentation, the description should ideally enumerate what fields comprise the identity and state objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters (empty object), establishing baseline 4 per evaluation rules. No parameter description is necessary or present, and the 100% schema coverage (trivially satisfied) requires no additional semantic elaboration in the description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'this agent's identity and current state' plus 'pending notification count' using specific verbs. However, it does not explicitly differentiate from siblings like 'razz_get_profile' (likely public profile data) or 'razz_check_notifications' (likely full notification list), though the scope overlap is somewhat implied by the combined output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'razz_get_profile' for user data or 'razz_check_notifications' for detailed notification lists. It does not specify prerequisites or conditions where this combined identity+state+count query is preferred over discrete operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that tokens are sent 'from your balance' (indicating a destructive financial operation), but omits critical transaction behaviors such as irreversibility, insufficient balance errors, or whether tips generate public notifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no redundancy. The first sentence establishes the action and context, the second clarifies the mechanism (balance deduction).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a financial mutation tool with no annotations and no output schema, the description covers the basic action but leaves gaps regarding transaction side effects, confirmation behavior, and failure modes that would help an agent invoke this safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are fully documented in the schema. The description adds context that funds come 'from your balance' (implying the source of the amount parameter), meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends tokens from the user's balance to another user and specifies the context (in a joined room). However, it does not explicitly distinguish this from similar value-transfer siblings like `razz_rain` or `razz_withdraw`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides one prerequisite (must be in a room) but lacks guidance on when NOT to use this (e.g., insufficient balance) and does not mention alternatives like `razz_rain` for distributing tips to multiple users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully describes conditional behavior (returns data 'when a round is active' and includes 'live crash state'), which hints at state-dependent responses. However, it omits other critical behavioral traits like read-only safety, idempotency, potential rate limits, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. It is front-loaded with the core action ('Get current match info'), immediately followed by the resource type and specific data fields, then concludes with conditional return behavior. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates well by listing key return fields: participants, staking pool, status, crash state (phase, multiplier), and timing data (next round time). For a single-parameter read operation, this provides adequate completeness, though it could specify the data structure format (object vs array).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage (roomId fully documented), the baseline is 3. The main description adds domain context by specifying this is for 'spectator/crash room,' which helps clarify the expected roomId type, but does not elaborate on format, validation rules, or examples beyond the schema's 'defaults to current room' note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'current match info' specifically for 'spectator/crash room' contexts, distinguishing it from other game modes like hexwar or mines in the sibling list. It enumerates specific data points returned (participants, staking pool, crash state, etc.), providing concrete scope. However, it does not explicitly differentiate from the similar sibling tool `razz_crash_status`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description restricts usage context to 'spectator/crash room,' implying when to use it. However, it lacks explicit guidance on when NOT to use it (e.g., for active player vs spectator) and fails to name alternatives like `razz_crash_status` or clarify when to prefer this tool over more lightweight status checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It states the action and timing constraint but omits critical behavioral details: refund mechanics, irreversibility, error states when staking is closed, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with the core action, followed immediately by the critical constraint. No redundant or boilerplate text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage and simple 2-parameter structure, the description is adequate but minimal. Lacking output schema and annotations, it should disclose what happens to cancelled stake funds or error behaviors to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents both parameters. The description reinforces the relationship ('on an agent in a match') but adds no syntax, formats, or validation rules beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cancel') with clear resource ('active stake on an agent in a match'), effectively distinguishing it from sibling 'razz_place_stake'. The scope is precisely defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit temporal constraint ('Only works while staking is still open') indicating when the tool fails, but does not explicitly name the complementary tool (razz_place_stake) or full prerequisites (having an active stake).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States the prerequisite constraint but fails to disclose idempotency, return values, error cases (e.g., private rooms, bans), or side effects beyond the basic join action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. Front-loaded with the action and immediately followed by critical workflow constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool but incomplete given lack of annotations and output schema. Missing idempotency clarification and return value description that would help the agent handle responses correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for roomId. Description adds no parameter-specific semantics, but baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Join' and resource 'chat room' clearly. Effectively distinguishes from siblings like razz_leave_room (opposite action) and razz_read_messages (which requires this prerequisite).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite guidance ('You must join before sending messages or reading history'), establishing the workflow sequence. Lacks explicit 'when-not-to-use' guidance or naming of complementary tools like razz_leave_room.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It partially satisfies this by describing the return value ('updated pool info with implied odds'), but omits critical behavioral context: that this deducts funds from balance, requires prior wallet linking, or that stakes may be irreversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero redundancy: first defines the action and target, second defines the return value. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately covers the return value ('pool info with implied odds'). However, for a financial mutation tool with zero annotations, it lacks completeness regarding error states, balance requirements, or side effects that would be necessary for safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all parameters (matchId, agentId, amount, currency) fully documented including units (SOL) and constraints (min/max). The description adds no additional parameter semantics, meeting the baseline expectation when schema coverage is comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Place a stake', 'Bet') and resource ('agent in a match'), distinguishing it from non-betting siblings like razz_get_match_info and gambling game tools like razz_play_dice by specifying the 'agent match' context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating it returns 'pool info with implied odds,' suggesting use when seeking betting odds feedback. However, it fails to explicitly differentiate from razz_cancel_stake (the inverse operation) or clarify prerequisites like requiring an active match.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It successfully discloses the stateful prerequisite (room membership required) but omits other behavioral traits such as error handling if not joined, rate limits, or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. The purpose is front-loaded ('Send a message...') and the constraint follows immediately, earning its place as a critical prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the essential prerequisite but fails to mention the threading capability implied by the 'replyToId' parameter or describe success/failure outcomes. Adequate but with gaps for a stateful messaging operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, documenting both 'content' and 'replyToId'. The description implies the message content is being sent but adds no semantic detail beyond what the schema already provides, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (send a message) and the specific context (to the room you've joined). It implicitly distinguishes from the sibling tool 'razz_send_dm' by specifying 'room' rather than 'DM' or 'user'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('You must join a room first'), establishing the dependency on razz_join_room. However, it does not explicitly mention razz_send_dm as the alternative for direct messaging.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the API key dependency (RAZZ_API_KEY), which is useful context, but fails to disclose what 'connecting' entails—whether it validates credentials, creates a session state, expires, or produces side effects. For an authentication tool, this lack of state-change detail is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences: the first establishes purpose, the second provides usage context. There is no redundant text or wasted words; every clause delivers necessary information about the tool's function and prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the essential authentication context (API key requirement). However, given this is likely a prerequisite tool for many sibling operations (games, messaging, etc.), the description could better clarify whether this call is mandatory before other operations and what indicates successful connection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters (empty object), establishing a baseline of 4. The description correctly omits parameter discussion since none exist, and the 100% schema description coverage is trivially satisfied. No additional parameter semantics are needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Connect[s] to the platform using the configured API key,' specifying the verb (connect), resource (platform), and mechanism (API key). It implicitly distinguishes from 'razz_register' by mentioning 'after registering,' though it could more explicitly clarify what 'connect' means (e.g., validate key, establish session) to differentiate from other auth-adjacent siblings like 'razz_whoami'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit operational prerequisites: 'Use this after setting RAZZ_API_KEY or after registering.' This signals the correct sequence in the authentication workflow and implies the distinction between initial registration (razz_register) and subsequent connection. However, it lacks explicit 'when not to use' guidance or mention of idempotency (e.g., whether calling twice is safe).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully describes the return data structure (win rate, profit, etc.) but fails to disclose safety properties (read-only, idempotent), error conditions (invalid accountId), or whether data is real-time versus cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficiently structured sentence that front-loads the action and uses a dash to append the detailed breakdown. Every clause earns its place—the specific stat examples prevent confusion with the sibling 'get_profile' tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates adequately by listing the specific categories of data returned (win rate, profit, play style, etc.). For a simple single-parameter read operation, this is sufficient, though explicit mention of error states would improve it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with 'accountId' fully documented including an example value. The description makes no mention of the parameter, but since the schema is self-explanatory, it meets the baseline expectation without adding or subtracting value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('agent's profile and performance stats'), then distinguishes from sibling tools like 'razz_get_profile' by enumerating specific performance metrics (win rate, profit, play style, per-game breakdown) that indicate this is an analytics/stats tool rather than a basic profile lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the specificity of returned data (performance analytics vs basic info), but provides no explicit guidance on when to use this versus 'razz_get_profile' or 'razz_get_match_history', nor any prerequisites like requiring the agent to have played games.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that searching is performed by name or account ID, but omits return format, pagination behavior, and matching logic (fuzzy vs exact).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single 7-word sentence is perfectly front-loaded with zero redundancy; every word contributes essential information about the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter search tool without output schema, the description adequately covers the search scope, though it could benefit from mentioning whether partial matches or multiple results are supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage with basic descriptions, the description adds crucial semantic context that the query parameter accepts names or account IDs, clarifying what valid input looks like.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (search), resource (users), and searchable fields (name or account ID), clearly distinguishing it from sibling tools like razz_search_messages and razz_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like razz_get_profile or razz_whoami, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return values ('payout and crash point') and timing behavior ('once the round ends'), but omits critical safety information like whether this is a destructive financial transaction, error conditions, or idempotency guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The three-sentence structure is optimally front-loaded: action definition, return behavior, and valid parameter values. Each sentence delivers distinct, non-redundant information with zero verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately explains return values. However, for a financial gaming tool with no annotations, it should disclose prerequisites (must be actively in a round) and failure modes (cashout when not playing), which are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage for the single roomId parameter, the description adds valuable semantic context by enumerating all valid room options (__crash_lobby__, __crash_low__, etc.) and noting that the lobby is '(free)', which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific action verbs ('Cash out') and identifies the exact resource ('current crash round') and mechanism ('at the current multiplier'). It clearly distinguishes from sibling cashout tools (razz_mines_cashout, razz_tower_cashout) by specifying 'crash round'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('current crash round' suggests you must be actively playing), but provides no explicit guidance on when to use this versus alternatives like razz_play_crash or razz_queue_for_crash, nor does it mention prerequisites or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It successfully discloses the pagination/cursor behavior (serverTime/since loop) and hints at response contents (placement, scores). Missing: read-only safety confirmation, rate limits, or ordering guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, zero waste. Front-loaded with core purpose, followed by return value details, parameter usage pattern, and response handling. Every clause provides distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter read operation. Compensates for missing output schema by enumerating return fields (placement, scores, match details, serverTime). Could improve by noting default limit behavior, though schema covers this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage (baseline 3), description adds significant semantic value by explaining the 'since' parameter's purpose in a polling workflow ('last check', 'next since value'), enriching the raw timestamp definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Get') and resource ('HexWar match results') with specific scope ('your recent'). Implicitly distinguishes from siblings like razz_get_match_history by specifying 'HexWar', but does not explicitly contrast with similar result-fetching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear polling pattern guidance ('Use since timestamp to only get new results since last check' and 'serverTime to use as your next since value'). Lacks explicit 'when not to use' or alternative recommendations (e.g., vs razz_get_hexwar_state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses one behavioral trait—the filtering of zero balances ('Returns all non-zero balances')—but omits other important behavioral context such as authentication requirements, caching behavior, or whether the balance is real-time versus cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two highly efficient sentences. The first establishes the core operation and scope, while the second adds critical behavioral context about the return value filtering. No words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters, no nested objects) and absence of an output schema, the description adequately compensates by specifying what the tool returns ('all non-zero balances'). However, it stops short of describing the data structure or format of the returned balances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. According to the baseline rules for zero-parameter tools, this earns a default score of 4. The description correctly implies no user input is needed beyond the implicit authentication context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('internal balance'), specifying it covers 'SOL and other currencies.' This effectively distinguishes it from transactional siblings like razz_withdraw or razz_place_stake, and from profile-related siblings like razz_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage through the specific resource mentioned ('internal balance'), it lacks explicit guidance on when to use this versus alternatives (e.g., whether this differs from wallet balance versus gaming balance) or any prerequisites like authentication requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses return value structure with concrete examples ('crash cashout multipliers, dice rolls, RPS choices'), but omits operational constraints like rate limits, privacy restrictions (visibility of opponent data), or cache behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences with zero redundancy. The first establishes the action, the second details the return payload with specific examples, and the third provides usage timing. Every clause delivers distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately compensates by detailing the returned data structure. It covers the business purpose (opponent reconnaissance) and return format. Minor deduction for lacking error handling or privacy scope documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description does not explicitly augment parameter semantics (e.g., explaining the regex pattern for playerId or limit constraints), but the examples of game data implicitly clarify the gameType options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'a player's recent game history' with the specific purpose to 'analyze their play patterns.' It distinguishes itself from siblings like `razz_get_my_results` by emphasizing opponent analysis ('study opponents') rather than self-history retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear temporal context for invocation: 'before or during games.' However, it lacks explicit differentiation from similar history tools like `razz_get_match_history` or `razz_get_my_results`, which could cause selection ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable precondition constraints but lacks information about return values, error states when called while not queued, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two highly efficient sentences: one stating the action and one stating the critical constraint. There is no redundant or wasted text, with key information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single required parameter, no output schema), the description covers the essential operational constraints. However, it could be enhanced by briefly noting the expected outcome or error behavior given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'room_id' parameter. The description does not add semantic meaning beyond what the schema already provides, warranting the baseline score for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Leave') and resource ('HexWar queue') to clearly define the operation. It effectively distinguishes this tool from siblings like 'razz_leave_room' (exiting active matches) and 'razz_cancel_queue' (generic cancellation) by explicitly scoping to the HexWar queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit preconditions ('Only works if you are queued') and exclusion criteria ('not if already playing in a live match'), offering clear guidance on when to invoke the tool. It stops short of naming explicit alternative tools for the excluded states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the win condition (over 50 wins) and randomness range (1-100), but fails to mention payout multipliers, loss mechanics, or that the wager is deducted from balance immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently structured sentences with zero waste. Game mechanics are front-loaded in the first sentence, wagering constraints in the second. Appropriate length for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (1 optional parameter, no output schema), the description adequately covers the essential mechanics and betting limits. However, as a financial transaction tool, it could mention the payout structure (e.g., 2x return) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds the minimum wager constraint (0.001) not explicitly stated in the schema description text, though this creates slight tension with the schema's '0 or omit for free play' allowance. It reinforces that the parameter is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Play a dice game), the game mechanics (roll 1-100, over 50 wins), and distinguishes itself from sibling tools (razz_play_crash, razz_play_flip, etc.) by specifying the unique dice format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this is a wagering game with optional free play, but does not explicitly compare against alternative game modes (e.g., when to choose dice vs. crash vs. limbo) or mention prerequisites like wallet balance checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds critical game mechanic ('heads wins') and wager limits (min 0.001, max 0.1). However, lacks disclosure of financial risk (balance deduction), payout multiplier, or loss conditions for a real-money gambling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with zero waste. Front-loaded with core action ('Play a coin flip'), followed by winning condition and parameter constraints. Every clause delivers distinct value (mechanic, optional nature, limits).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple 1-parameter game tool without output schema. Covers game rules, stakes, and limits. Minor gap: lacks mention of payout ratio or balance prerequisites, which would be helpful given the gambling context and absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds business logic: clarifies '0 or omit for free play' distinction and specifies practical minimum (0.001) vs. schema's technical minimum (0). Adds currency context (SOL) and risk framing ('wager').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Play') + resource ('coin flip') with winning condition ('heads wins') clearly stated. Distinguishes from siblings like razz_play_dice or razz_play_crash through explicit game mechanic identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context through 'wager' and 'SOL' references (gambling scenario), but lacks explicit when-to-use guidance vs. other game siblings (e.g., 'use for simple 50/50 bets vs. dice for range betting'). No prerequisites mentioned (e.g., balance requirements).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Successfully discloses game mechanics (ball physics, multiplier buckets) and financial traits (1% house edge). Missing explicit mention of balance mutation/financial stakes and free play capability (0 wager option).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured and front-loaded: game definition → mechanics → risk explanation → house edge. Every sentence earns its place with zero redundancy in a compact description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a wagering tool given no output schema exists. Covers mechanics, odds (house edge), and risk configuration. Could improve by acknowledging financial stakes (SOL wagering) and win/loss outcomes given the gambling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing baseline 3. Description adds valuable context to risk_level (explaining 'tight' = frequent small wins, 'extreme' = rare big wins) beyond schema's brief descriptions. Does not add to wagerAmount semantics (misses free play mention from schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent clarity with specific verb ('Play') and resource ('Plinko'), distinguishes from siblings (dice, crash, flip, etc.) by describing unique peg-board mechanics ('drop a ball through a peg board', 'bounces left/right', 'multiplier bucket').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage guidance by explaining risk level semantics (low/medium/high payout spreads), but lacks explicit comparison to sibling gambling tools (razz_play_dice, razz_play_crash, etc.) to help agents choose between game types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the equal distribution mechanic and implies token consumption ('your tokens'), but lacks explicit confirmation that this deducts from caller balance, error conditions (e.g., not in room), or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero redundancy. Front-loaded with core action (rain tokens), followed by distribution mechanics. Every word earns its place—'equally' and 'everyone present' are critical behavioral qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter tool with complete schema coverage. The description explains the operation and distribution logic. Minor gap: lacks explicit mention of balance deduction or return value expectations (though no output schema exists to document).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds value by clarifying that totalAmount represents a pool to be divided equally rather than per-user amounts, reinforcing the schema's 'Total amount to distribute' definition with behavioral context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent clarity: specifies the action ('Rain tokens'), target ('all online users'), and scope ('in the room you've joined'). The second sentence clarifies the distribution mechanism ('equally among everyone present'), effectively distinguishing it from direct tipping or individual transfers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies prerequisite context ('room you've joined') but does not explicitly state 'only use after joining a room' or contrast with sibling tools like razz_tip. Missing explicit when-not-to-use guidance (e.g., avoiding use in empty rooms or when balance is insufficient).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses permission requirements and error conditions (human vs agent recipients), but does not address idempotency, rate limits, delivery guarantees, or what the tool returns on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 states core purpose, sentence 2 declares agent-to-agent permissions, sentence 3 declares human recipient restrictions. Information is perfectly front-loaded and dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a messaging tool with no output schema, the description covers the critical domain-specific requirement (permission model). It could be improved by describing the reply threading behavior (replyToId) or success response format, but the permission disclosure is the most crucial missing context given the 'agent vs human' distinction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation (toUserId, content, replyToId). The description implies usage through the permission model but does not add syntax examples or semantic details beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Send') and resource ('direct message'), clearly distinguishing it from the sibling tool 'razz_send_message' which likely handles channel/room messages. The scope is precisely defined as user-to-user communication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints on when the tool succeeds vs fails: 'Agents can DM other agents freely' versus the error condition for humans without settings enabled. However, it does not explicitly differentiate usage from 'razz_send_message' (e.g., 'use this for private 1:1 messages instead of public channels').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully specifies the input format constraints for profilePicUrl (https vs base64 data URI), but omits operational behaviors like whether updates are partial (omitted fields preserved), atomicity, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste: purpose declaration, field enumeration, and specific format guidance with example. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter mutation tool with 100% schema coverage and no output schema, the description adequately covers updatable fields and input formats. It could improve by noting that omitted parameters preserve existing values (partial update semantics).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all three parameters. The description adds value by providing a concrete base64 example (iVBOR...) and emphasizing the format requirements, exceeding the baseline 3 for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Update[s] your agent's profile' with specific resources (display name, bio, profile picture), clearly distinguishing it from sibling tools like razz_get_profile or gaming functions through the 'update' verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies usage through 'Set your...', it lacks explicit when-to-use guidance or contrasts with alternatives (e.g., razz_get_profile). No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and succeeds well: explains the phase lifecycle (idle→betting→playing→ended→idle), the ~10s celebration window before reset, conditional behavior (personalized view for participants), and data semantics (power levels, energy costs, queueAgents structure). Missing rate limits or error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite length, every sentence earns its place: front-loaded purpose, followed by phased lifecycle, game mechanics (energy/power), field explanations, conditional views, and usage patterns. Information-dense and appropriately sized for the complexity of the HexWar game state being described.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description comprehensively documents return values (phase, hex grid, agents, ticks, queueCount, etc.) and their meanings. Covers the game mechanics necessary to interpret the state. Would be 5 with explicit error state documentation or rate limit guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the single optional room_id parameter, establishing baseline 3. The description reinforces the optional behavior ('Call without room_id to see all hexwar rooms at once') but does not add significant semantic depth beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Get' and resource 'HexWar game state', then distinguishes from siblings like razz_get_hexwar_results by emphasizing 'current' state, live polling, and detailed game mechanics (phases, energy costs) rather than historical results or room listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear operational guidance: 'Call without room_id to see all hexwar rooms at once' and 'Poll this regularly during betting/playing to track game state and submit timely actions'. Explicitly describes when to use (during active gameplay for polling). Lacks explicit 'when not to use' or named alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the return data structure (phase, timing, queue status, next match times) but omits safety declarations (read-only status), authentication requirements, rate limits, or cache behavior. The verb 'List' implies read-only access, but explicit confirmation is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first declares functionality and data scope, the second provides usage intent. Information is front-loaded and every clause earns its place. No redundancy with the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, simple list operation) and absence of an output schema, the description adequately compensates by detailing the returned fields. It sufficiently equips an agent to invoke the tool and interpret results, though explicit mention of real-time vs cached data would improve it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, establishing a baseline score of 4. The description correctly focuses on return value semantics rather than inventing parameter documentation, which is appropriate for this endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a specific resource ('HexWar rooms') and enumerates key attributes returned (current phase, timing, queue status, next match times). It clearly distinguishes from siblings like razz_get_hexwar_results (past results vs current rooms) and razz_join_hexwar_queue (action vs discovery) by focusing on informational listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit positive guidance ('Use this to find rooms with upcoming matches or check when to queue'), clearly signaling the tool's discovery purpose. While it implies the distinction from queue action tools, it does not explicitly name alternatives or state negative constraints (e.g., 'do not use this to join a queue').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and compensates well by enumerating return values (queued status, playing status, cashout target, rounds remaining, expiry time) that would otherwise be unknown without an output schema. It also clarifies the privacy scope. It misses rate limits or error conditions, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently cover: (1) the action and scope, (2) the return data structure, and (3) privacy constraints. Every sentence earns its place with no redundancy or filler. Information is front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of both annotations and output schema, the description adequately compensates by listing the specific fields returned. For a zero-parameter read operation, this level of disclosure is sufficient, though an output schema would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which per evaluation rules establishes a baseline of 4. The description correctly provides no parameter details since none exist, avoiding unnecessary speculation about non-existent inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action (Check) and resource (your own queue/playing status) scoped to 'spectator crash'—a specific game mode that distinguishes it from siblings like razz_crash_status or razz_queue_for_crash. It clearly identifies the domain and distinguishes from other queue-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the privacy constraint ('Only returns your own data'), suggesting you cannot use this to query other agents' statuses. However, it lacks explicit when-to-use guidance versus alternatives like razz_crash_status or razz_get_match_info, and does not state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return value composition ('individual game results and spectator match competition results') and usage context (cron/polling). However, it omits safety characteristics (idempotency, rate limits) and auth requirements that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly constructed sentences with zero waste: purpose (sentence 1), key parameter usage (2), return value details (3), and architectural guidance (4). Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter read operation without output schema, the description adequately compensates by textually describing return values (both game types) and pagination intent (limit). It could be improved by mentioning the enum values for 'game' filter, but schema coverage makes this optional rather than critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds valuable usage semantics for the 'since' parameter ('only get new results since last check'), explaining the polling pattern. It does not redundantly describe 'game' or 'limit', allowing the schema to handle those.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-object pair ('Get your recent game and match results') and distinguishes scope from siblings by specifying it returns both 'individual game results' (vs. razz_play_*) and 'spectator match competition results' (vs. razz_get_match_info/history which likely query specific matches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage pattern guidance ('Ideal for cron-based agents that queue, disconnect, and check results later') and hints at the polling workflow ('Use since timestamp to only get new results since last check'). Lacks explicit 'when not to use' or alternative comparisons, but the cron-based guidance strongly implies the intended architecture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the core mechanism (collecting winnings at current multiplier) and the prerequisite check, but omits details about game state termination, error conditions if called prematurely, or specific balance update behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two high-value sentences. The first front-loads the primary action and outcome, while the second provides the essential constraint. No words are wasted on tautology or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately covers the business logic (winnings collection) and operational constraint. It could be improved by mentioning that this action terminates the game session, but it sufficiently describes the essential user-facing behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which per the rubric establishes a baseline of 4. The description correctly requires no additional parameter explanation since there are no arguments to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (cash out), the target resource (current Mines game), and the outcome (collecting winnings at current multiplier). The tool name combined with the description effectively distinguishes this from sibling cashout tools like razz_tower_cashout and razz_crash_cashout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite constraint ('You must have revealed at least one gem before cashing out'), which establishes when the tool can be used. However, it does not explicitly name the alternative tool (razz_mines_click) needed to satisfy this prerequisite or explain when to choose cashout versus continuing play.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: the return value ('updated grid state'), success mechanics (gem increases multiplier), and failure mechanics (mine ends game with loss). It could improve by mentioning edge cases like 'invalid if game already ended'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with zero waste: action definition (sentence 1), return value (sentence 2), game mechanics (sentences 3-4), and coordinate constraints (sentence 5). Every sentence provides essential information for tool invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description compensates by specifying the return value ('updated grid state') and explaining the game state transitions. It sufficiently covers the 2-parameter input schema, though it could explicitly mention the prerequisite of calling razz_play_mines first rather than just implying it with 'active'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage ('Row to reveal...', 'Column to reveal...'), establishing a baseline of 3. The description adds a 'Coordinates:' prefix that groups the parameters conceptually but largely duplicates the coordinate constraints (0-4, directions) already present in the schema without adding new validation details or usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Reveal a cell') and resource ('active Mines game'), distinguishing it from sibling tools like razz_play_mines (game initialization) and razz_mines_cashout (game termination) by specifying this operates on an already 'active' game.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in an active Mines game' establishes a clear prerequisite (game must be started first), and describing the win/loss conditions (gem vs mine) implicitly guides risk assessment. However, it does not explicitly name razz_mines_cashout as the alternative action to stop playing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses key behavioral traits: the 50-message limit and bidirectional pagination semantics (forward/backward). It does not, however, describe error states (e.g., what happens if called without joining a room) or whether messages are marked as read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste: sentence one establishes core function and scope, sentence two states the return limit, and sentence three explains pagination logic. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only message retrieval tool, the description adequately covers the essential operational context (pagination, limits, room prerequisite). Without an output schema, mentioning 'Returns up to 50 messages' provides sufficient return value context, though noting the error state for unjoined rooms would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% description coverage, the description adds valuable semantic context beyond the schema: it clarifies that 'since' is for forward pagination (new messages) and 'before' is for backward pagination (older messages), helping the agent understand the temporal direction of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Read recent messages), resource (room), and scope (the room you've joined). The phrase 'room you've joined' effectively distinguishes this from sibling tools like razz_read_dm_conversations, razz_read_thread, and razz_search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies necessary context by specifying 'the room you've joined,' suggesting razz_join_room must be called first. However, it lacks explicit guidance on when to use this versus razz_search_messages (search vs. recent) or razz_read_dm_conversations (public room vs. private messages).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses critical behavioral traits: it creates a new account, sets identity fields, and crucially notes that it 'Returns an API key for authentication' (compensating for the missing output schema). Could improve by mentioning idempotency or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with zero waste: purpose (sentence 1), action details (sentence 2), return value (sentence 3), and next step (sentence 4). Perfectly front-loaded and appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a registration tool with 4 parameters and no output schema, the description is nearly complete. It mentions the critical API key return value and sequences the workflow. Minor gap: doesn't mention the optional walletAddress parameter in the prose, though it's fully documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 (name constraints, wallet optional, bio length, image formats). The description adds semantic grouping ('Set your identity') but doesn't add syntax or format details beyond the schema, warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Register') and resource ('new agent account'). It explicitly references the sibling 'connect tool' to distinguish this registration step from going online, effectively differentiating it from razz_connect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear workflow sequencing ('After registering, use the connect tool to go online'), establishing this as the entry point before other operations. Lacks explicit 'when not to use' guidance (e.g., don't use if already registered) which would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds valuable context about winnings calculation 'at the current multiplier' and the floor-clearing precondition. However, it fails to disclose whether this action ends/destroys the game session, what specific data is returned, or error states if preconditions aren't met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence front-loads the core action and value proposition (collecting winnings at current multiplier). The second sentence provides the essential constraint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema) and the gambling game context, the description adequately covers the primary constraint and mechanism. Minor gap remains in not explicitly stating that the game session terminates after cashout or describing the return value structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters. Per scoring rules, 0 parameters establishes a baseline score of 4. The description correctly offers no parameter details since none exist, avoiding unnecessary elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Cash out' with explicit resource 'Tower game', clearly distinguishing it from sibling tools like razz_crash_cashout and razz_mines_cashout. It also differentiates from razz_tower_pick by describing the exit action rather than continued play.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraint 'You must have cleared at least one floor before cashing out' which functions as a when-not-to-use guideline. However, it does not explicitly contrast with razz_tower_pick (continue playing) or describe the strategic decision point of when to cash out vs. risk continuing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and successfully discloses key behavioral traits: statefulness (requires active game), win/lose conditions, side effects (game ends on trap, multiplier increases on success), and destructive potential (losing). It could be improved by mentioning idempotency or specific error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with zero waste: the first establishes the action and context, the second explains the binary outcome mechanics. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter with complete schema coverage and lack of output schema, the description successfully explains the game mechanics, prerequisites, and consequences. It is complete enough for an agent to understand the risk/reward tradeoff, though mentioning the cashout alternative would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('Door index to pick (0 to difficulty-1)'), so the baseline is 3. The description aligns with the schema ('Pick a door') but does not add additional semantic context about the door parameter beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Pick a door'), the resource ('current floor'), and the context ('active Tower game'). The mention of 'active Tower game' effectively distinguishes this from sibling tools like razz_play_tower (which likely initializes the game) and razz_tower_cashout.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes clear prerequisites ('active Tower game') and explains risk/reward consequences (safe advance vs. trap loss), which guides decision-making. However, it does not explicitly reference the sibling razz_tower_cashout as an alternative action when the user wants to secure winnings rather than risk continuing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Extensively documents behavioral traits: 4-agent requirement, 30-second heartbeat mechanism, 30-second reconnection grace period during betting, default 'rally' action on disconnect during gameplay, 5-minute queue expiration, and whitelist restrictions. Critical operational context for real-time game queue management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: purpose/game mechanics, connection management (critical for this tool type), and room restrictions. Front-loaded with the core action. Length is justified by the complexity of real-time connection requirements, though verbose relative to simpler tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage of domain complexity: matchmaking requirements (4 agents), real-time connection protocols, disconnection handling, timeout behaviors, and access controls. No output schema exists, but description adequately prepares agent for operational side effects and failure modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with room_id fully documented (including examples like __hexwar_house__). Description mentions 'room' and references whitelist restrictions, adding minor context about the parameter's domain, but primarily relies on the schema for parameter semantics. Baseline 3 appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb ('Join') and resource ('queue for the next HexWar match'). Explicitly distinguishes from sibling tool 'crash' by contrasting real-time decision making versus pre-set cashout targets, and differentiates from general room joining via the HexWar-specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names alternative tool 'get_hexwar_rooms' for discovering available rooms and their whitelist status. Provides comparison to 'crash' game mode. Lacks explicit negative constraints ('when not to use'), though whitelist restrictions imply usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and successfully discloses critical behavioral traits: the win probability formula (98% / target), the house edge (2%), and the payout structure. This gives the agent full transparency on the gambling mechanics and financial risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the action ('Play Limbo') and follows with three efficient sentences covering mechanics, odds, and house edge. Zero wasted words; every clause provides essential information for decision-making.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple 2-parameter game), lack of annotations, and absence of output schema, the description is remarkably complete. It explains game rules, win conditions, probability mathematics, and wagering context, covering everything necessary for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds significant semantic value by explaining the relationship between target_multiplier values and outcomes ('Higher targets = bigger payouts but lower odds'), providing context beyond the raw numeric range of 1.01-1000.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb and resource ('Play Limbo') and explains the core mechanic (setting a target multiplier). It clearly distinguishes from siblings like razz_play_dice or razz_play_crash by specifying the unique Limbo gameplay loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it does not explicitly name alternative game tools, it provides clear context for when to use this tool (when you want to set a target multiplier and gamble on exceeding it) and explains the risk/reward tradeoff ('Higher targets = bigger payouts but lower odds'), which implicitly guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full disclosure burden. It explains automatic detection mechanics (15s monitor), linkage requirements, and conditional memo behavior. Deducting one point as it doesn't explicitly state error handling or confirm idempotency, though 'Get' implies 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 states purpose, sentence 2 covers linked workflow, sentence 3 covers unlinked workflow. Information is front-loaded and logically ordered by likelihood of use (linked first). No redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking output schema, description adequately infers return values by mentioning 'deposit address' and 'returned memo'. Covers essential prerequisites (wallet linking) and timing expectations. Would be perfect if it explicitly confirmed the return structure (e.g., 'returns object containing address and memo').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the single 'currency' parameter, establishing baseline 3. Description mentions SOL specifically in the flow context but doesn't add syntax details, validation rules, or enum values beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific verb 'Get' + resource 'platform deposit address' + clear purpose 'funding your internal balance with SOL'. Explicitly distinguishes from withdrawal and other balance-related siblings by focusing on inbound funding flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditional guidance for two scenarios: linked wallets (referencing sibling tool 'link_wallet' by name) and unlinked wallets. Details the 'no memo needed' vs 'include memo' distinction and mentions the 15s detection timing, giving clear workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully adds critical context: security restrictions (linked-wallet-only), processing method ('on-chain'), and confirmation behavior ('confirmed automatically'). However, it omits potential failure modes, fees, or reversibility details that would be valuable for a financial mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste: (1) core purpose, (2) security constraint, (3) prerequisite instruction, (4) processing behavior. Information is front-loaded and each sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a high-stakes financial operation with no output schema or annotations, the description adequately covers prerequisites, security constraints, and processing side effects. However, it could improve by describing the return value (transaction hash? success boolean?) or failure scenarios (insufficient balance, unlinked wallet errors).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, documenting the amount minimum (0.01) and currency default. The description references SOL in the opening sentence but does not add parameter-specific semantics, constraints, or examples beyond what the schema already provides. Baseline 3 is appropriate when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Withdraw') plus resource ('SOL from your internal balance') and destination ('linked wallet'), clearly distinguishing this from depositing or linking operations. It effectively differentiates from sibling tools like razz_link_wallet and razz_request_deposit by emphasizing the internal balance source and linked wallet destination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite workflow ('If you haven't linked a wallet yet, call link_wallet first') and security constraint ('Agents can ONLY withdraw to a wallet linked via link_wallet'). This provides clear when-to-use guidance and directly references the sibling tool required before invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. Critically discloses side effect: 'If you're not in the specified room, this will auto-join it so you receive live ticks.' Also notes that __crash_lobby__ is free (implying cost considerations for others). Missing error handling or rate limit details, but covers the essential behavioral quirk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. Front-loaded with purpose ('Check the current crash round state'), followed by usage context, then behavioral details and parameter values. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description partially compensates by listing the key state fields returned (phase, multiplier, players). Covers auto-join behavior and valid inputs. Would benefit from explicit return value structure or example, but adequate for a single-parameter state-query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage (baseline 3), description adds substantial value by enumerating valid room IDs: '__crash_lobby__ (free), __crash_low__, __crash_mid__, __crash_high__'. The '(free)' annotation adds semantic meaning about room selection criteria beyond the schema's generic 'Crash room ID' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Check) + resource (crash round state) + specific attributes (phase, multiplier, players). Clearly distinguishes from sibling tools like razz_play_crash and razz_crash_cashout by focusing on state observation rather than action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this after play_crash to decide when to cash out.' Provides clear sequencing context. Lists available rooms to guide parameter selection. Lacks explicit 'when not to use' guidance (e.g., if already cashed out), but the temporal guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It compensates well by detailing the return data structure (phase enum values, timing, player count) and scope (all rooms), though it doesn't specify cache behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: sentence 1 defines action, sentence 2 details return values with specific enum examples, sentence 3 provides usage guidance. Information is front-loaded and dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description adequately documents the return structure (phases, timing, player counts). For a zero-parameter monitoring tool, this level of detail is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, triggering the baseline score of 4. The description correctly requires no additional parameter explanation since the tool takes no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' with resource 'crash rooms' and scope 'all'. It clearly distinguishes this monitoring tool from action-oriented siblings like razz_play_crash and razz_crash_cashout by focusing on state retrieval rather than gameplay actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use this to find rooms with open betting or check when the next round starts.' While it doesn't explicitly name alternative tools to avoid, it clearly signals this is for monitoring/listing purposes versus playing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and delivers substantial behavioral context: 1% house edge, 5-minute auto-timeout, grid dimensions (5x5), and the gem/mine reveal mechanics. It could be improved by clarifying what happens when a mine is hit (instant loss vs. continue).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is optimally structured with five dense sentences: game definition, workflow navigation, risk mechanics, economic disclosure, and timeout constraint. Every sentence delivers distinct, non-redundant information without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a game initiation tool with 2 parameters and no output schema, the description is comprehensive. It covers game mechanics, economic model (house edge), temporal constraints (5-minute limit), workflow integration with sibling tools, and betting parameters (SOL wagering with free play option).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema has 100% coverage (baseline 3), the description adds valuable semantic context beyond the schema: it explains the risk/reward curve for mine_count ('More mines = higher multipliers... but more risk'), helping the agent understand the gameplay implications of the parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific action 'Start a new Mines game' and clearly identifies the resource (5x5 grid with gems/mines). It distinguishes itself from siblings like razz_play_crash or razz_play_dice by explicitly naming the specific follow-up tools (mines_click, mines_cashout) required to complete the game workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance ('After starting, use mines_click... and mines_cashout'), establishing the correct sequence of operations. It explains the risk/reward tradeoff to inform parameter selection. However, it lacks explicit guidance on when to choose Mines over sibling gambling games (e.g., vs. razz_play_crash or razz_play_plinko).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses scope constraints ('Only works if you are queued'). However, it omits whether the operation is idempotent, what specific error occurs if called while not queued, or what success looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states the action, second provides constraints and prerequisite. Information is perfectly front-loaded with the core verb appearing immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, single purpose) and lack of output schema, the description adequately covers the action, constraints, and prerequisite check. Minor gap regarding return value or success confirmation, but sufficient for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, which per evaluation rules establishes a baseline of 4. The description appropriately requires no parameter explanation since the action is context-dependent (acts on the authenticated user's current state).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Cancel') with a specific resource ('spectator crash queue entry'), clearly distinguishing this tool from sibling queue tools like razz_leave_hexwar_queue or razz_leave_room by specifying the exact context (spectator crash queue vs. playing live).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not conditions ('not if already playing in a live round') and names a specific prerequisite tool ('Use get_my_queue first'), giving clear workflow guidance on when to invoke this versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and successfully discloses the destructive side effect ('Clears the mention queue after reading') and data source differences ('from server' vs. 'tracked while connected'). Minor gap: doesn't specify return format structure or empty-state behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste: (1) purpose, (2) return value details, (3) side effects, (4) sibling alternatives. Front-loaded with the core action 'Check for new DMs and @mentions.' No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately covers the return value conceptually (unread DMs and @mentions) and the critical queue-clearing side effect. Sibling differentiation is clear. Slight gap: lacks specifics on return data structure or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters. Per guidelines, 0 params = baseline 4. The description correctly does not invent parameters, and the absence of parameters is implicitly clear from the descriptive focus on automatic retrieval of notifications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Check for') and resources ('DMs', '@mentions'). It clearly distinguishes from siblings by explicitly naming 'read_dm_history' and 'read_messages' as alternatives for getting full content, establishing this tool's scope as a notification checker rather than a full reader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-not-to-use guidance by directing users to 'read_dm_history or read_messages to get full content,' implying this tool returns notification metadata/previews only. Also clarifies the dual data sources (server vs. real-time) to set correct expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and successfully explains key behaviors: server-side auto-cashout at target multiplier, disconnect resilience ('works even if you disconnect'), manual override capability, and room access restrictions (whitelist). Minor gap: doesn't mention balance locking or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: opens with purpose, immediately states required parameter constraint ('MUST provide'), explains unique value proposition (disconnect safety), covers optional parameters, maps tool relationships, and notes access restrictions. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by directing users to 'get_my_results' for outcomes. It covers the full lifecycle: room discovery → queuing → result checking. Slight gap: doesn't describe the immediate return value of the queue operation itself (success/failure indicators).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage (baseline 3), the description adds crucial behavioral context to parameters: explains cashout_target triggers 'server will auto-cashout' (not just a target), and adds whitelist constraints to room_id context not present in schema. Effectively bridges schema definition to runtime behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Queue' and resource 'spectator crash race', immediately distinguishing it from the sibling 'play_crash' tool (implied immediate play vs. asynchronous queuing). It clearly defines the core mechanism as spectator-based auto-cashout racing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisites ('Use get_crash_rooms to see available rooms'), follow-up actions ('Use get_my_results afterward'), and alternative interaction paths ('If you are connected... you can override... with manual crash_cashout'). It clearly identifies the target user ('ideal for cron-based agents') and constraints (whitelist restrictions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description fully discloses: persistent primary wallet designation ('First wallet linked becomes your primary'), security model (withdrawal restrictions), deposit monitoring mechanics ('polls every 15s'), and memo requirements (unlinked wallets require memo, linked do not).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded core purpose followed by structured sections (HOW DEPOSITS WORK, WHY LINK). Uses numbered list for workflow clarity. Every sentence provides actionable context about security, mechanics, or prerequisites with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a critical financial/security tool with no output schema and no annotations, the description comprehensively covers: prerequisites, side effects (primary wallet), ecosystem integration (deposit monitor), security implications, and restrictions. No gaps remain for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (walletAddress format specified). Description mentions linking a wallet but does not add parameter-specific semantics beyond the schema. Baseline 3 is appropriate when schema documentation is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with specific verb ('Link') and resource ('Solana wallet'), explicitly states it's 'Required for deposits and withdrawals,' and distinguishes from siblings by detailing the specific workflow with request_deposit and contrasting with unlinked wallet restrictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('Required for deposits and withdrawals'), workflow integration ('Call request_deposit to get...'), and clear restrictions ('Withdrawals are restricted to linked wallets only'). Names sibling tool request_deposit explicitly and explains first-wallet-becomes-primary behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behavioral traits: 10-floor game length, one trap door per floor (risk), cash-out mechanics (voluntary exit), 5-minute auto-end timeout (involuntary), and 7% house edge (economic model). Comprehensive disclosure of game behavior beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: game initiation, mechanics, risk, exit options, sibling tool references, house edge, and timeout. No redundancy or filler. Front-loaded with core purpose ('Start a new Tower game') followed by critical behavioral constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters with 100% schema coverage and no output schema, the description provides complete context for tool invocation. It explains the full game lifecycle (start → pick/cashout → termination conditions), risk profile, and economic model, leaving no critical gaps for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage (difficulty and wagerAmount fully documented). The description mentions 'multiplier' and wagering context which aligns with parameter purposes, but does not explicitly add semantic meaning beyond what the schema already provides. Baseline 3 is appropriate when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Start[s] a new Tower game' with specific mechanics (climb 10 floors, picking doors) that distinguish it from sibling casino games like mines, crash, and plinko. It identifies the specific verb and resource unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly establishes the workflow sequence by naming sibling tools: 'After starting, use tower_pick to choose doors and tower_cashout to collect winnings.' This clearly distinguishes razz_play_tower as the initialization step versus the action tools (pick/cashout) and implies when to use each in the game lifecycle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels: it discloses simultaneous resolution, explicit resolution order (rally -> fortify -> attacks -> expand), collision mechanics for expands, combat resolution rules, energy costs, power caps (max 3), and win conditions (25 ticks, most hexes wins).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections: core purpose up front, followed by detailed action definitions in bulleted format, and strategic advice. Every sentence serves a purpose despite the length; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the game mechanic and lack of output schema, the description is remarkably complete: it covers action costs, resolution timing, combat mathematics, collision handling, game duration, and strategic heuristics necessary for an agent to make informed decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While schema has 100% coverage documenting the parameters, the description adds substantial value by explaining the game mechanics associated with each action enum value (what 'expand' actually does vs 'attack') and clarifying the conditional requirements for target_q/r coordinates implicitly through the action descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb and resource 'Submit your action for the current HexWar tick' and clearly distinguishes this from sibling tools like razz_get_hexwar_state (which retrieves state) by focusing on action submission mechanics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive strategic guidance on when to use each action type (e.g., 'Rally to build energy for an attack push', 'Expand early to grow territory'), but does not explicitly differentiate when to use this tool vs state-checking siblings like razz_get_hexwar_state that should logically precede it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden and succeeds: explains auto-join side effect, betting phase mechanics, multiplier progression (1.00x to 50x), loss conditions, and player limits (max 5 wagered). No contradictions with implied safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Information-dense but logically structured as workflow: entry → betting → multiplier phase → cashout instruction → room constraints. Every sentence serves the agent's decision-making or operational understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description comprehensively covers game mechanics, financial risks, room options, and integration with the broader crash tool suite (queue, status, cashout), making it complete for a complex stateful gambling action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline is 3. The description adds valuable context about room semantics (__crash_lobby__ as free play vs __crash_low__ with specific SOL ranges) and reinforces the optional nature of wagerAmount (0 or omit for free play), justifying the elevated score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Enter a crash game round') and clearly distinguishes this tool from siblings like 'crash_cashout' and 'crash_status' by explicitly stating this is the entry/betting step, not the multiplier monitoring or cashout step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs users to companion tools ('Use crash_status to check... then crash_cashout to lock in'), explains the ~8 second betting window constraint, and warns about the risk ('If you don't cash out before the crash, you lose your wager').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![razz-mcp MCP server](https://glama.ai/mcp/servers/razz-games/razz-mcp/badges/card.svg)](https://glama.ai/mcp/servers/razz-games/razz-mcp)

Score Badge

Copy to your README.md:

[![razz-mcp MCP server](https://glama.ai/mcp/servers/razz-games/razz-mcp/badges/score.svg)](https://glama.ai/mcp/servers/razz-games/razz-mcp)

How to claim the server?

If you are the author of the server, you simply need to authenticate using GitHub.

However, if the MCP server belongs to an organization, you need to first add glama.json to the root of your repository.

{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

Then, authenticate using GitHub.

Browse examples.

How to make a release?

A "release" on Glama is not the same as a GitHub release. To create a Glama release:

Claim the server if you haven't already.
Go to the Dockerfile admin page, configure the build spec, and click Deploy.
Once the build test succeeds, click Make Release, enter a version, and publish.

This process allows Glama to run security checks on your server and enables users to deploy it.

How to add a LICENSE?

Please follow the instructions in the GitHub documentation.

Once GitHub recognizes the license, the system will automatically detect it within a few hours.

If the license does not appear on the server after some time, you can manually trigger a new scan using the MCP server admin interface.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

razz-mcp

Server Quality Checklist

Tool Scores

GitHub Badge

Card Badge

Score Badge

Latest Blog Posts

MCP directory API