Set up a new game room in RTTA Arena by choosing tier, max players, and entry fee; you join automatically as the creator after paying the fee. Tier sets pace: Quick, Standard, or Epic.
创建一个新的游戏房间。你成为房间创建者并自动加入（收取入场费）。Tier 控制游戏节奏：Quick (0) = 快速轮次，Standard (1) = 平衡，Epic (2) = 长游戏。返回新房间 ID。
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | 玩家名称（1-20 字符，默认：XXXX） | |
| tier | Yes | 房间等级：0=快速，1=标准，2=史诗 | |
| entryFee | Yes | 入场费，单位 USDC（1-100） | |
| maxPlayers | Yes | 最大玩家数（3-50） |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does well by disclosing important side effects: the creator automatically joins, an entry fee is charged, and a new room ID is returned. It does not go deeper into lifecycle or failure behavior, but the key consequences of invoking the tool are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four short, purposeful clauses: purpose, behavior, tier semantics, and return value. There is no filler or redundancy, and the most important information is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description appropriately states that the tool returns a new room ID. The parameter details are fully covered by the schema, and the behavioral side effects are disclosed. It could mention next steps like starting the game, but that is not required to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some semantic value by explaining tier pacing ('Quick = fast rounds, Standard = balanced, Epic = long game'), but this largely mirrors the schema's enum labels. It does not add meaning for name, maxPlayers, or entryFee beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: '创建一个新的游戏房间' (create a new game room). It also distinguishes the tool from siblings by explaining that the caller becomes the room creator and automatically joins, which is unique among tools like match_room or get_arena_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when you want to create a new game room. However, it does not explicitly contrast with alternatives such as match_room or start_game, nor does it state when not to use it. The usage context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.