Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Start recording a live call

start_recording
Destructive

Records a live call to one mp3/wav file, mixed or per-party, ending at a set time, hangup, or manual stop; the file is then available for retrieval.

Instructions

Start recording a LIVE call (POST /Call/{uuid}/Record/) into one file, either mixed (mono, default) or one party per channel (stereo). Recording ends at time_limit seconds (default 60, max 8 hours), when the call hangs up, or with stop_recording; the file then appears in get_call_recording / list_recordings and its storage is billed. Playback and speech on the call (play_audio, speak_text) are unaffected; to capture only a caller's answer inside an IVR use the record action of generate_answer_xml instead. Recording may require consent from the other party in your jurisdiction, so confirm with the user first. Requires confirm: true.

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true, set only after the user explicitly asked to record this call. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved.
call_uuidYesUUID of the LIVE call to act on: the request_uuid returned by make_call, or a UUID from list_live_calls.
time_limitNoMaximum seconds to record, 1-28800 (default 60). The recording also ends when the call does.
file_formatNoAudio format of the file: mp3 (default) or wav.
record_channel_typeNomono (default): both parties mixed into one channel; stereo: each party on its own channel.

Output Schema

NameRequiredDescriptionDefault
okNoTrue on success. On a failure the result is isError with ok: false plus `error` (kind), `message`, `retryable` and sometimes `http_status`.
urlNoURL of the recording file as Vobiz reports it; pass it to stop_recording to stop just this recording. Null when not reported.
noteNoReminder that the file is only retrievable (get_call_recording) after the recording stops.
call_uuidNoThe call UUID the action was applied to, echoed from the request.
recordingNoTrue once Vobiz accepted the request and started recording.
http_statusNoHTTP status Vobiz answered with: 202 when an action was accepted, 204 when one was stopped.
recording_idNoIdentifier Vobiz assigned to this recording, or null when it did not report one.
backend_messageNoVobiz's own confirmation text for the request, or null when it sent none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.4.2
    • addedInput schema / properties / call_uuid / description
      Added value: +"UUID of the LIVE call to act on: the request_uuid returned by make_call, or a UUID from list_live_calls."
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true, set only after the user explicitly asked to record this call."New value: +"Must be true, set only after the user explicitly asked to record this call. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved."
    • addedInput schema / properties / file_format / description
      Added value: +"Audio format of the file: mp3 (default) or wav."
    • addedInput schema / properties / record_channel_type / description
      Added value: +"mono (default): both parties mixed into one channel; stereo: each party on its own channel."
    • changedInput schema / properties / time_limit / description
      Previous value: -"Max seconds to record (Vobiz max 28800; default 60)."New value: +"Maximum seconds to record, 1-28800 (default 60). The recording also ends when the call does."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "backend_message": {
+      "description": "Vobiz's own confirmation text for the request, or null when it sent none.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "call_uuid": {
+      "description": "The call UUID the action was applied to, echoed from the request.",
+      "type": "string"
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with: 202 when an action was accepted, 204 when one was stopped.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "note": {
+      "description": "Reminder that the file is only retrievable (get_call_recording) after the recording stops.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "True on success. On a failure the result is isError with ok: false plus `error` (kind), `message`, `retryable` and sometimes `http_status`.",
+      "type": "boolean"
+    },
+    "recording": {
+      "const": true,
+      "description": "True once Vobiz accepted the request and started recording.",
+      "type": "boolean"
+    },
+    "recording_id": {
+      "description": "Identifier Vobiz assigned to this recording, or null when it did not report one.",
+      "type": [
+        "string",
+        "number",
+        "null"
+      ]
+    },
+    "url": {
+      "description": "URL of the recording file as Vobiz reports it; pass it to stop_recording to stop just this recording. Null when not reported.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint, openWorldHint) by disclosing how recording terminates (time_limit, hangup, stop_recording), where the file surfaces (get_call_recording / list_recordings), that storage is billed, and that playback/speech are unaffected. It also raises the legal consent requirement and the confirm gate, which are material behaviors an agent must know before invoking.

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?

The core action is front-loaded in the first clause, and subsequent sentences carry distinct value (termination, storage, alternatives, consent). It is dense and somewhat run-on, but almost no sentence is redundant.

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 no explanation, and the description covers the remaining gaps an agent needs: termination conditions, sidelining siblings, billing, and the confirm/consent gate. Nothing essential for correct invocation 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?

Schema coverage is 100%, so all five parameters are already documented, including defaults for time_limit, file_format, and record_channel_type. The description largely restates those defaults (60s, mono) rather than adding new semantics, 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 and resource ('Start recording a LIVE call'), includes the exact endpoint, and clarifies the output shape (one file, mono or stereo). It is immediately distinguishable from siblings like start_conference_recording and the IVR record action it explicitly names.

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?

Explicitly gives the alternative and the condition that selects it: 'to capture only a caller's answer inside an IVR use the record action of generate_answer_xml instead.' It also names stop_recording as an end condition and states the confirm: true prerequisite plus consent guidance, leaving little 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