Skip to main content
Glama
vobiz-ai

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Kick a conference member

kick_conference_member
Destructive

Remove members from a live conference while keeping their call active, then play a message or route them elsewhere.

Instructions

Remove members from a live Vobiz conference while keeping their call up (POST /Conference/{name}/Member/{id}/Kick/): their call continues with the next VobizXML element after , so you can play them a message or route them elsewhere. To end their call instead, use hangup_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 remove this member from the conference.
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).
noteNoWhat happens to the members' calls next.
kickedNoAlways true: the members left the room.
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).
backend_messageNoVobiz's own status message, or null.
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": {
+    "backend_message": {
+      "description": "Vobiz's own status message, or null."
+    },
+    "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"
+    },
+    "kicked": {
+      "const": true,
+      "description": "Always true: the members left the room.",
+      "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": "What happens to the members' calls next.",
+      "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.5/5.0
Behavior4/5

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

Goes beyond the annotations by disclosing the post-kick lifecycle (call continues at the next VobizXML element), the confirm requirement, and the not_found error for a stopped room or an already-departed member. Annotations already cover the destructive/write safety profile, so this is useful added context rather than a full disclosure of permissions or 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.

Conciseness5/5

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

Three sentences, zero waste, with the defining behavior (call stays up) and the sibling routing front-loaded. The API path is included without bloating the text.

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 explained. For a 3-required-param destructive tool, the description covers the differentiator, the confirm gate, the alternative, and the failure mode — everything an agent needs to invoke it correctly.

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?

Schema description coverage is 100%, so the schema already documents confirm, member_id (including the 'all' and comma-list forms), and conference_name. The description repeats 'Requires confirm: true' but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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+resource ('Remove members from a live Vobiz conference') plus the crucial nuance that their call stays up. It explicitly contrasts with the sibling hangup_conference_member, so an agent can distinguish the two kick/end operations without opening either schema.

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?

Names the alternative ('To end their call instead, use hangup_conference_member') and the condition selecting it, and gives a positive use case (play a message or route elsewhere after the <Conference> element). The confirm precondition is also stated explicitly.

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