Skip to main content
Glama

Close the booth without ending

close_booth

Closes the host seat without the End step, so if the host was live, viewers see them leave. Use end_broadcast to end it for everyone.

Instructions

Closes the host seat on this computer without the End step. If the host was live, viewers see the host leave. Use end_broadcast to end it for everyone.

Input Schema

NameRequiredDescriptionDefault
meeting_idYesThe meeting_id of the room (from create_broadcast or join_broadcast).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses that the effect is local to this computer, that it is not the End step, and that viewers see the host leave if the host was live. It stops short of saying whether the booth can be reopened (open_booth) or what state the meeting is left in.

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 short sentences, front-loaded with the action and its scope, followed by the user-visible consequence and the sibling routing. No 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?

For a one-parameter, no-annotation, no-output-schema tool, the description covers scope, side effect, and the alternative. It leaves minor gaps around follow-up state (reopening, whether the meeting persists), but nothing an agent needs to call it correctly is missing.

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 single meeting_id parameter is fully described in the schema (100% coverage), including its source (create_broadcast or join_broadcast). The description adds nothing about parameters, which is acceptable at this coverage level – 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?

States a specific verb and resource ('Closes the host seat') plus a precise scope qualifier ('on this computer'), which immediately separates it from end_broadcast. An agent can distinguish it from open_booth and end_broadcast without opening any schema.

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 routes the agent to the alternative: 'Use end_broadcast to end it for everyone.' The condition for choosing this tool is implied by 'without the End step.' It doesn't address the potentially confusable leave_meeting, but the primary alternative is named.

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