Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Start an audio stream on a live call

start_audio_stream
Destructive

Fork a live Vobiz call's audio to your WebSocket server in near real time for transcription or AI voice agents. Returns a stream_id to manage the stream.

Instructions

Fork the audio of a LIVE Vobiz call to your WebSocket server in near real time (POST /Call/{uuid}/Stream/), for example for live transcription or an AI voice agent. service_url must be wss:// on an approved host. bidirectional: true lets your server play audio back into the call and requires audio_track inbound (the default when bidirectional). content_type sets the inbound audio format (L16 8 kHz default, L16 16 kHz, or mu-law 8 kHz). Returns a stream_id for get_audio_stream / stop_audio_stream. This sends live call audio to an external server, so it requires confirm: true after the user approves the destination. Fails with call_not_active once the call has ended. To play audio into the call without a socket use play_audio; to see streams already running use list_audio_streams.

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true, set only after the user explicitly approved: sending this call's live audio to this WebSocket server. 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 fork: the request_uuid returned by make_call, or call_uuid from list_live_calls.
audio_trackNoWhich audio to fork. Default both; must be inbound when bidirectional is true.
service_urlYeswss:// URL of your WebSocket server. Its host must be on the server's VOBIZ_ALLOWED_URL_HOSTS allowlist (or be a public host when any host is allowed).
content_typeNoInbound audio format sent to your server. Default audio/x-l16;rate=8000.
bidirectionalNoAllow your server to send audio back into the call (playAudio). Default false.
extra_headersNoComma-separated header:value pairs (e.g. X-Session:abc123) passed with the stream. Use the wss:// URL path, not these headers, to authenticate the socket.
stream_timeoutNoStop the stream automatically after this many seconds. Default 86400.
status_callback_urlNohttps URL (approved host) that receives stream status events (StartStream, PlayedStream, StopStream...).
status_callback_methodNoHTTP method for status_callback_url (default POST). Ignored without status_callback_url.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
call_uuidNoThe call whose audio is being forked.
stream_idNoID of the new stream for get_audio_stream and stop_audio_stream, or null if Vobiz did not return one.
streamingNotrue once the stream is running.
audio_trackNoWhich side is forked: inbound, outbound or both.
http_statusNoHTTP status Vobiz answered with.
bidirectionalNoWhether your server may send audio back into the call.
backend_messageNoMessage from Vobiz about the operation, or null.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.4.2
    • addedInput schema / properties / call_uuid / description
      Added value: +"UUID of the live call to fork: the request_uuid returned by make_call, or call_uuid from list_live_calls."
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true, set only after the user explicitly approved: sending this call's live audio to this WebSocket server."New value: +"Must be true, set only after the user explicitly approved: sending this call's live audio to this WebSocket server. 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."
    • changedInput schema / properties / service_url / description
      Previous value: -"wss:// URL of your WebSocket server (approved host)."New value: +"wss:// URL of your WebSocket server. Its host must be on the server's VOBIZ_ALLOWED_URL_HOSTS allowlist (or be a public host when any host is allowed)."
    • changedInput schema / properties / status_callback_method / description
      Previous value: -"Default POST."New value: +"HTTP method for status_callback_url (default POST). Ignored without status_callback_url."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "audio_track": {
+      "description": "Which side is forked: inbound, outbound or both.",
+      "type": "string"
+    },
+    "backend_message": {
+      "description": "Message from Vobiz about the operation, or null."
+    },
+    "bidirectional": {
+      "description": "Whether your server may send audio back into the call.",
+      "type": "boolean"
+    },
+    "call_uuid": {
+      "description": "The call whose audio is being forked.",
+      "type": "string"
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "ok": {
+      "description": "true on success; false (with error and message) when the tool failed.",
+      "type": "boolean"
+    },
+    "stream_id": {
+      "description": "ID of the new stream for get_audio_stream and stop_audio_stream, or null if Vobiz did not return one."
+    },
+    "streaming": {
+      "description": "true once the stream is running.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructive/openWorld/non-idempotent, and the description adds context beyond them: that live call audio is sent to an external server, that it requires explicit user approval via confirm, and the specific call_not_active failure once the call ends. It also discloses the return value (stream_id) and the host allowlist constraint.

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?

Purpose and destination are front-loaded, and every sentence carries information (endpoint, constraints, return, approval, failure, alternatives). It is a single dense block that could be split for readability, but there is no filler.

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 10-parameter destructive streaming tool with an output schema and full annotation coverage, the description supplies everything an agent needs: host/format constraints, the approval gate, the track/bidirectional coupling, the failure mode, and sibling alternatives.

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 adds genuine cross-parameter meaning: the bidirectional=true dependency on audio_track=inbound (and that inbound is the default), plus the wss:// + approved-host constraint on service_url. Some content (content_type options) merely restates the enum, keeping it below 5.

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 ('Fork the audio of a LIVE Vobiz call to your WebSocket server'), names the endpoint, and gives concrete use cases (live transcription, AI voice agent). It explicitly distinguishes itself from play_audio, list_audio_streams, get_audio_stream and stop_audio_stream, so an agent can route without opening schemas.

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 explicit when-not routing ('To play audio into the call without a socket use play_audio; to see streams already running use list_audio_streams') and a clear precondition/failure boundary ('requires confirm: true after the user approves', 'Fails with call_not_active once the call has ended'). Alternatives and conditions are named, not implied.

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