Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Stop recording a conference

stop_conference_recording
DestructiveIdempotent

Stops recording in a live Vobiz conference while the call continues, letting you capture only the needed segment and later retrieve the file from recordings.

Instructions

Stop the recording started by start_conference_recording on a live Vobiz conference room (DELETE /Conference/{name}/Record/). Use it when the part you needed is captured; the conference itself keeps running and the file appears later in list_recordings. A room that is not running returns the not_found error.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "conference_name": "<conference_name>"
    },
    "name": "stop_conference_recording"
  }
}

Input Schema

NameRequiredDescriptionDefault
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).
recordingNoAlways false: recording is stopped.
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"
+    },
+    "ok": {
+      "description": "True on success; false when the result is an error (then error, message and retryable are set).",
+      "type": "boolean"
+    },
+    "recording": {
+      "const": false,
+      "description": "Always false: recording is stopped.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds genuine context beyond that: the conference itself keeps running, the file only appears later in list_recordings, and a non-running room yields a not_found error.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Three sentences, action front-loaded, each carrying useful information (counterpart tool, endpoint, post-conditions, error case). Minor density but no wasted padding.

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?

For a single-parameter mutation tool with an output schema present, the description covers trigger, side effects (conference continues), follow-up (file in list_recordings), and the failure mode (not_found). 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?

With a single parameter at 100% schema coverage, the schema already documents conference_name fully. The description adds only the {name} path placeholder, which does not meaningfully extend the schema's meaning.

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 (stop the recording on a Vobiz conference room) and ties it directly to its counterpart start_conference_recording, so an agent can distinguish it from siblings like stop_recording or start_conference_recording. The endpoint reference reinforces exactly what it does.

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?

"Use it when the part you needed is captured" gives clear triggering context, and the note that the conference keeps running clarifies the scope of the action. It doesn't explicitly name alternative tools or spell out when-not to use it, keeping it just short of a 5.

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