get_audio_streamRetrieve details of a Vobiz call's audio stream—status, WebSocket URL, track, format, and timing—using call UUID and stream ID. Read-only for monitoring or integration.
Return one audio stream on a Vobiz call (GET /Call/{uuid}/Stream/{stream_id}/): status, WebSocket URL, track, audio format, start and end time. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| call_uuid | Yes | ||
| stream_id | Yes |
Changes observed during successful MCP inspections.
v1.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so 'Read-only' in the description earns no credit. The enumeration of returned fields (status, WebSocket URL, track, audio format, timestamps) adds genuine context given no output schema, but there is no mention of auth requirements, error behavior for unknown/ended streams, or whether the stream must be active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the action, resource, and scope before the endpoint and field list. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only getter with two required path params and no output schema, listing the response fields is exactly what's needed. It falls short only on failure modes and any precondition about the stream's state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden; it does map call_uuid and stream_id into the URL path template, clarifying they are path identifiers on a call's stream. However it adds no format, length, or validity guidance beyond the regex patterns already in the schema, leaving the required-parameter contract thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return one audio stream'), the resource, the underlying endpoint (GET /Call/{uuid}/Stream/{stream_id}/), and enumerates the fields returned. The singular 'one' implicitly separates it from the sibling list_audio_streams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: retrieving a single known stream, versus list_audio_streams for enumeration or start_audio_stream/stop_audio_stream for lifecycle changes. No explicit when-to-use or when-not-to-use statement routes the agent among those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.