Skip to main content
Glama

Hang up a conference member

hangup_conference_member
DestructiveIdempotent

Ends a conference member's call so they leave the room and their call hangs up. Use to drop a participant completely; set confirm to true.

Instructions

End the calls of members in a live Vobiz conference (DELETE /Conference/{name}/Member/{id}/): they leave the room and their call hangs up. Use it to drop a participant completely; to keep their call going after they leave, use kick_conference_member. Requires confirm: true. A room that is not running, or a member who already left, returns the not_found error.

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true, set only after the user explicitly asked to hang up this member's call.
member_idYesConferenceMemberID from the ConferenceEnter callback (or get_conference), a comma-separated list such as 17,45,82, or `all` for every member.
conference_nameYesConference room name, exactly as used in the <Conference> XML element.

Output Schema

NameRequiredDescriptionDefault
okNoTrue on success; false when the result is an error (then error, message and retryable are set).
noteNoHow to confirm the members actually left.
hung_upNoAlways true: the hang-up was accepted.
member_idNoMembers the action was applied to: the literal "all", or the list of member IDs as Vobiz echoed them (or as requested).
http_statusNoHTTP status Vobiz answered with (202 = accepted, 204 = done).
conference_nameNoRoom the action was applied to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.2
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "conference_name": {
      +      "description": "Room the action was applied to.",
      +      "type": "string"
      +    },
      +    "http_status": {
      +      "description": "HTTP status Vobiz answered with (202 = accepted, 204 = done).",
      +      "type": "number"
      +    },
      +    "hung_up": {
      +      "const": true,
      +      "description": "Always true: the hang-up was accepted.",
      +      "type": "boolean"
      +    },
      +    "member_id": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "items": {},
      +          "type": "array"
      +        }
      +      ],
      +      "description": "Members the action was applied to: the literal \"all\", or the list of member IDs as Vobiz echoed them (or as requested)."
      +    },
      +    "note": {
      +      "description": "How to confirm the members actually left.",
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "True on success; false when the result is an error (then error, message and retryable are set).",
      +      "type": "boolean"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observedv1.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds the concrete effect (members leave the room and their call hangs up), the confirmation gate, and the error semantics for a stopped room or an already-departed member. That is real behavioral context beyond the structured hints.

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?

Three tight sentences: effect first, sibling disambiguation second, preconditions and failure mode last. No sentence is redundant and the most decision-relevant content is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described. Scope, alternative routing, confirmation requirement, and error behavior are all covered — an agent has everything needed to select and invoke this correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by restating the hard confirm: true requirement in prose and clarifying that the operation applies to 'members' (plural), which aligns with the schema's comma-separated list and `all` support. It stops short of adding format or syntax detail the schema does not already carry.

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 ('End the calls of members in a live Vobiz conference') and even names the underlying endpoint. It is immediately distinguishable from the sibling kick_conference_member, which it explicitly calls out as the non-destructive alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use ('drop a participant completely') and a when-to-use-the-other-tool rule ('to keep their call going after they leave, use kick_conference_member'). It also states the confirm: true precondition and the not_found failure case, leaving nothing to inference.

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

Deploy Server

Other Tools