Skip to main content
Glama

leave_room

Vacate your seat and return to lobby. During a match, leaving auto-concedes your team to prevent zombie rooms. Use in pre-game, mid-match, or post-match.

Instructions

Vacate this connection's seat and return the caller to the lobby.

Accepts from IN_ROOM (pre-game) OR IN_GAME (mid-match or post-match). Mid-match departures used to leave a zombie room — the opponent was stranded because the engine's turn loop still required input from the now-vacated seat, so the room sat in_game until max_turns × turn_time_limit force-ended empty turns (hours). Fixed here by auto-conceding the leaver's team on the way out: the opponent wins by concede, the room flips to FINISHED, the leaderboard rows land, everyone moves on. Post-match departures are the normal 'back to lobby' flow.

── Locking ── Three phases, no nested locks:

  1. state_lock: peek at (conn, room_id, slot, is_in_game, leaver_team) — everything we'll need. Does NOT mutate.

  2. session.lock (only if we decided to auto-concede): flip session.state.status = GAME_OVER via the same concede tool end_game dispatches use. Guarded by a re-check of session.state.status so we never double- concede a match that finished between phases.

  3. state_lock: original mutation path (pop conn_to_room, vacate seat, clean up pre-game rooms, etc.).

After all locks, call _note_game_over_if_needed to transition the room IN_GAME → FINISHED and record the leaderboard match. That function has its own 3-phase locking protocol.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
connection_idYes
Behavior5/5

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

No annotations are provided, so the description carries full burden. It discloses critical behavioral traits: auto-concede for mid-match, locking protocol with three phases, and transition to FINISHED state. The internal implementation details (variable names, lock order) are transparent, providing a complete picture of side effects.

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

Conciseness3/5

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

The description is front-loaded with the core purpose in the first sentence, but includes several paragraphs of internal locking implementation that may be excessive for an agent. While structured with headings, it lacks conciseness; the locking details could be summarized without sacrificing essential transparency.

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 and no annotations, the description explains the tool's lifecycle: returning to lobby, auto-concede, state transitions, and locking. However, it omits description of the single parameter and what the tool returns (if anything). This gap reduces completeness but overall coverage of behavior and side effects is strong.

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

Parameters2/5

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

The schema has 0% description coverage for the single required parameter 'connection_id'. The description does not explain the parameter's meaning beyond the name, nor does it provide any guidance on its format or usage. Given the low coverage, the description should compensate but fails to add 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 clearly states the tool's purpose: 'Vacate this connection's seat and return the caller to the lobby.' It also specifies accepted states (IN_ROOM, IN_GAME) and distinguishes from siblings like 'concede' by noting auto-concede behavior. The verb 'vacate' and resource 'connection's seat' are specific, making the purpose unambiguous.

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 explicitly states when to use the tool: from IN_ROOM (pre-game) or IN_GAME (mid-match or post-match). It explains the behavioral difference for mid-match departures (auto-concede) versus post-match (normal lobby return). However, it does not explicitly contrast with alternatives like 'concede' or state when not to use it, which would improve guidelines.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/haoyifan/Silicon-Pantheon'

If you have feedback or need assistance with the MCP directory API, please join our Discord server