Skip to main content
Glama

Leave the meeting

leave_meeting

Make the bot leave a meeting, save the transcript, and keep other participants in the room; a scheduled session inside its window is marked as left early.

Instructions

The bot leaves and the transcript is saved. Same result as end_meeting. Call this when someone asks the bot to leave. Other participants stay. A scheduled order still inside its window is marked left early.

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/5.0
Behavior4/5

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

With no annotations, the description does real work: it discloses that the transcript is saved, that other participants remain, and that a scheduled order inside its window is marked left early. It omits idempotency, permission requirements, and behavior when the bot is not in the meeting.

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?

Four short sentences, front-loaded with the action and its effect, then the trigger, then the edge-case behavior. No filler and no repetition of the title.

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?

Covers the outcome, the trigger, the effect on other participants, and the scheduling side effect, which is more than most single-parameter tools offer. Missing error/idempotency behavior and any mention of what is returned, though with no output schema that last gap is minor.

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?

Only one parameter and schema coverage is 100%, so the schema already documents meeting_id including its provenance (create_broadcast or join_broadcast). The description adds nothing about the parameter, which is the expected baseline when the schema is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and actor (the bot leaves) plus the key side effect (transcript saved), and distinguishes the scope from end_meeting by noting other participants stay. The line 'Same result as end_meeting' muddies the distinction slightly, since it implies the two tools are interchangeable when the trigger differs.

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?

Gives an explicit trigger condition ('Call this when someone asks the bot to leave') and references the sibling end_meeting as an equivalent-outcome alternative. It stops short of stating when to choose end_meeting over this tool, leaving that boundary to inference.

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