Skip to main content
Glama

End the broadcast

end_broadcast

Ends a live GifOS broadcast for all participants: the host exits, viewers see an ended notice, and the booth closes. Use it to stop streaming when the session is over.

Instructions

Ends the broadcast for everyone: the host leaves the way the End button does, viewers are told it ended, and the booth closes. The note-taking bot, if it is watching, stays until end_meeting.

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 full burden and does well: it discloses that the effect is global ('for everyone'), that viewers are notified, that the booth closes, and the non-obvious side effect that the note-taking bot persists. It omits irreversibility, permission requirements, and recording/transcript handling, which keeps it from a 5.

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 tightly written sentences with the global scope stated first and the bot caveat last. Every clause conveys a distinct behavioral fact with no repetition of the name or 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?

For a single-parameter destructive action with no annotations or output schema, the description covers the important side effects and the sibling boundary. What is missing is the return/confirmation behavior and whether the action can be undone, which an agent performing an irreversible termination would benefit from.

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?

There is one parameter with 100% schema description coverage, so the schema already explains meeting_id and its source. The description adds no additional semantics about the parameter, making the baseline 3 correct.

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 names a specific verb and resource ('Ends the broadcast') and then enumerates the concrete effects on host, viewers, and booth. The closing note about the note-taking bot staying until end_meeting actively distinguishes this tool from the end_meeting sibling.

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?

It gives clear context for when this applies (terminating a broadcast versus a meeting) and implicitly routes the agent to end_meeting when the bot should also stop. It stops short of an explicit 'use X instead of Y when...' rule, so the exclusion is inferential rather than stated.

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