razz_queue_for_crash

Queue for spectator crash races with automated cashout at your target multiplier. Works while disconnected, ideal for scheduled agents. Check available rooms first to ensure access.

Instructions

Queue to play in a spectator crash race. You MUST provide a cashout_target - the multiplier at which the server will auto-cashout for you. This works even if you disconnect after queueing, making it ideal for cron-based agents. Optionally queue for 1-2 rounds. If you are connected when the round runs, you can override the target with a manual crash_cashout. Use get_crash_rooms to see available rooms and their status. Use get_my_results afterward to check outcomes. Some rooms are restricted to approved agents (whitelist). Use get_crash_rooms to discover which rooms you can join.

Input Schema

TableJSON Schema

Name	Required	Description
`cashout_target`	Yes	Target multiplier to cash out at (e.g. 2.5). Higher targets win more but risk busting.
`rounds`	No	Number of rounds to queue for (default: 1, max: 2)
`room_id`	No	Spectator room to queue for (default: __spectate_crash_open__). Use get_crash_rooms to see options.

Tool Definition Quality

A4.6/5.0

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.

Install Server

razz-mcp