Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Play audio on a live call

play_audio
Destructive

Plays one to five pre-recorded .mp3 or .wav files into a live voice call in order, with optional looping, length cutoff, and mix-over or replace behavior.

Instructions

Play one to five audio files (https .mp3/.wav, in order) into a LIVE call (POST /Call/{uuid}/Play/). Use it for pre-recorded audio; for spoken text use speak_text, and to send the call's audio to your own WebSocket server use start_audio_stream. mix: true (default) plays over the conversation so the parties keep hearing each other; false replaces the leg's audio until playback ends. Playback ends when the files finish, after length seconds, or with stop_audio (stop_speaking and stop_recording do not affect it); with loop it repeats until stopped. A call that is not live fails with call_not_active.

Input Schema

NameRequiredDescriptionDefault
mixNotrue (default): play over the conversation; false: replace the leg's audio while playing.
legsNoWhich call leg the action applies to: aleg (the call's first leg, default), bleg (the leg bridged to it by <Dial>) or both.
loopNoRepeat the files until stop_audio or `length` ends playback (default false).
urlsYesOne to five https URLs of .mp3 or .wav files, played in this order.
lengthNoStop playback after this many seconds (1-3600). Omit to play to the end.
call_uuidYesUUID of the LIVE call to act on: the request_uuid returned by make_call, or a UUID from list_live_calls.

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`.
playingNoTrue once Vobiz accepted the playback request; audio starts within moments.
call_uuidNoThe call UUID the action was applied to, echoed from the request.
http_statusNoHTTP status Vobiz answered with: 202 when an action was accepted, 204 when one was stopped.
backend_messageNoVobiz's own confirmation text for the request, or null when it sent none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 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 / legs / description
      Previous value: -"Which call leg: aleg (default), bleg or both."New value: +"Which call leg the action applies to: aleg (the call's first leg, default), bleg (the leg bridged to it by <Dial>) or both."
    • changedInput schema / properties / length / description
      Previous value: -"Stop after this many seconds."New value: +"Stop playback after this many seconds (1-3600). Omit to play to the end."
    • changedInput schema / properties / loop / description
      Previous value: -"Repeat until stopped."New value: +"Repeat the files until stop_audio or `length` ends playback (default false)."
    • changedInput schema / properties / mix / description
      Previous value: -"Mix with the call audio (default true)."New value: +"true (default): play over the conversation; false: replace the leg's audio while playing."
    • changedInput schema / properties / urls / description
      Previous value: -"Audio files to play in order."New value: +"One to five https URLs of .mp3 or .wav files, played in this order."
    • 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"
+    },
+    "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"
+    },
+    "playing": {
+      "const": true,
+      "description": "True once Vobiz accepted the playback request; audio starts within moments.",
+      "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 declare this is a mutating, non-idempotent, open-world action, and the description adds substantial context beyond them: mix true plays over the conversation while false replaces the leg's audio, playback terminates on file end / length / stop_audio, loop repeats until stopped, and notably that stop_speaking and stop_recording do NOT affect it. This is unusually rich disclosure of behavior that annotations cannot convey.

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?

Front-loaded with the action and endpoint, then alternatives, then behavioral mechanics. Dense but every clause carries information an agent needs; no filler sentences.

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. The description covers the live-call requirement, the failure mode, alternative tools, and the full lifecycle of playback termination, leaving no material gap for a destructive live-call operation.

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, but the description goes further by explaining the effect of mix on the parties ('keep hearing each other') and enumerating the three ways playback can end, which color how length and loop interact. It adds real meaning over the schema entries rather than restating them.

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 ('Play one to five audio files ... into a LIVE call') with the exact endpoint and format constraints (https .mp3/.wav, in order). It explicitly distinguishes itself from speak_text and start_audio_stream by naming both and the condition that selects each.

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?

Explicit routing is provided: pre-recorded audio here, spoken text via speak_text, and streaming to your own WebSocket via start_audio_stream. It also states the precondition that the call must be live and that non-live calls fail with call_not_active.

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