Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get an audio stream

get_audio_stream
Read-only

Retrieve a single audio stream on a Vobiz call to check its status, WebSocket URL, track, format, and start/end time, confirming whether it is still running or when it ended.

Instructions

Return one audio stream on a Vobiz call (GET /Call/{uuid}/Stream/{stream_id}/): status, WebSocket URL, track, audio format, start and end time. Use it to check whether a stream you started is still running or when it ended; for every stream on the call use list_audio_streams, and to end one use stop_audio_stream. An unknown call or stream fails with not_found (streams of older calls may no longer be retrievable).

Input Schema

NameRequiredDescriptionDefault
call_uuidYesUUID of the call the stream belongs to (request_uuid from make_call or call_uuid from list_live_calls).
stream_idYesThe stream's ID: stream_id as returned by start_audio_stream or listed by list_audio_streams.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
streamNoThe stream as Vobiz returns it: stream_id, status, service_url, audio_track, content_type, bidirectional, start and end time.
call_uuidNoThe call the stream belongs to.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.2
    • addedInput schema / properties / call_uuid / description
      Added value: +"UUID of the call the stream belongs to (request_uuid from make_call or call_uuid from list_live_calls)."
    • addedInput schema / properties / stream_id / description
      Added value: +"The stream's ID: stream_id as returned by start_audio_stream or listed by list_audio_streams."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "call_uuid": {
+      "description": "The call the stream belongs to.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "true on success; false (with error and message) when the tool failed.",
+      "type": "boolean"
+    },
+    "stream": {
+      "additionalProperties": {},
+      "description": "The stream as Vobiz returns it: stream_id, status, service_url, audio_track, content_type, bidirectional, start and end time.",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile, yet the description adds genuinely new behavior: an unknown call or stream fails with not_found, and streams of older calls may no longer be retrievable. That error and retention context is valuable beyond the annotations, though return formatting/pagination isn't addressed.

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?

Two tight sentences, front-loaded with the operation and returned fields, then alternatives and error behavior. Dense and purposeful, though the field enumeration and error clause make it slightly longer than strictly necessary.

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, and the description still covers purpose, alternatives, and failure modes. For a simple two-parameter read tool, an agent has everything needed to select and 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 both call_uuid and stream_id already carry origin and pattern documentation. The description adds no additional parameter semantics such as formats or constraints beyond what the schema provides, 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?

The description states a specific verb and resource (return one audio stream on a Vobiz call), enumerates the returned fields, and names the endpoint. It clearly differentiates itself from list_audio_streams (all streams) and stop_audio_stream (end one).

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?

It explicitly states when to use it (check whether a stream you started is still running or when it ended) and routes the agent to the correct alternatives for other needs: list_audio_streams for every stream, stop_audio_stream to end one. Nothing is left 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