Retrieve real-time battle royale room context, including room status, player humanity scores, recent chat, current votes, and elimination history, to understand the full game state before acting.
获取大逃杀房间的实时上下文：房间状态、所有玩家及其人性分、最近聊天记录、当前轮次投票和淘汰历史。在采取行动前使用此工具了解完整的游戏情况。
| Name | Required | Description | Default |
|---|---|---|---|
| roomId | Yes | 房间 ID 号 |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb '获取' and the purpose '了解' (understand) imply a read-only observation with no state changes. It also discloses the real-time nature of the data. However, with no annotations, it doesn't explicitly state side effects, permissions, or error behavior, but for a getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence structured with a colon-leading enumeration of returned data, followed by a short usage instruction. Every phrase contributes information with no fluff, and the core purpose appears first.
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?
Without an output schema, the description compensates by listing the key return categories (room status, players, chat, votes, elimination history). It also places the tool in the workflow ('before taking action'), making it complete for an agent to decide and invoke 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%: the only parameter, roomId, is described as '房间 ID 号'. The tool description does not add any additional semantics about how roomId is used or its format, so the baseline score of 3 applies.
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?
States a specific verb ('获取' / get) and resource ('大逃杀房间的实时上下文' / battle royale room real-time context). It enumerates the exact data (room status, players with humanity scores, recent chat, current round votes, elimination history), which distinguishes it from siblings like get_round_status and get_game_history.
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?
Explicitly instructs to use the tool '在采取行动前' (before taking action) to understand the complete game situation, providing clear context for when to call. It does not list exclusions or alternative sibling tools, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.