Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Stop recording a live call

stop_recording
DestructiveIdempotent

Stop a recording on a live Vobiz call: pass the recording URL to end only that recording, or omit it to stop all recordings; the call continues and the file is finalized.

Instructions

Stop a recording on a LIVE call (DELETE /Call/{uuid}/Record/): pass the url returned by start_recording to stop that one recording, or omit it to stop every recording on the call. The file is finalised and appears in get_call_recording shortly after; the call itself, playback (stop_audio) and speech (stop_speaking) are unaffected. A call that is not live fails with call_not_active (the hangup already closed its recordings).

Input Schema

NameRequiredDescriptionDefault
urlNoRecording file URL from start_recording, to stop only that recording. Omit to stop all recordings on the call.
call_uuidYesUUID of the live call being recorded.

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`.
stoppedNo"one" when a url was given, "all" when every recording on the call was stopped.
call_uuidNoThe call UUID the action was applied to, echoed from the request.
recordingNoFalse once Vobiz accepted the stop request.
http_statusNoHTTP status Vobiz answered with: 202 when an action was accepted, 204 when one was stopped.

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 live call being recorded."
    • changedInput schema / properties / url / description
      Previous value: -"Recording file URL from start_recording."New value: +"Recording file URL from start_recording, to stop only that recording. Omit to stop all recordings on the call."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "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"
+    },
+    "recording": {
+      "const": false,
+      "description": "False once Vobiz accepted the stop request.",
+      "type": "boolean"
+    },
+    "stopped": {
+      "description": "\"one\" when a url was given, \"all\" when every recording on the call was stopped.",
+      "enum": [
+        "one",
+        "all"
+      ],
+      "type": "string"
+    }
+  },
+  "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?

Annotations already declare the mutation/idempotency/open-world profile, and the description goes well beyond them: it discloses the post-condition (file finalised, appears in get_call_recording shortly after), the unaffected subsystems, and the specific error returned for non-live calls. That is exactly the side-effect context 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The action is front-loaded before scope and side-effect detail, and no sentence is filler. The two sentences are long and clause-dense, but every clause carries distinct operational information.

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?

With an output schema present, the description need not explain return values, and it still covers scope, side effects, non-effects, and the error path for a mutation tool. Nothing an agent needs to call this correctly 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 description coverage is 100%, and the description's parameter guidance ('pass the url returned by start_recording', 'omit to stop every recording') largely restates what the schema already documents for url and call_uuid. Baseline 3 is appropriate when the schema carries the parameter burden.

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 names a precise verb and resource (stop a recording) and immediately scopes it to a LIVE call with the underlying endpoint. It explicitly separates itself from nearby siblings (stop_audio, stop_speaking) and from delete_recording by noting the file is finalised and retrievable via get_call_recording.

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 states when the tool applies (live calls only), how to narrow vs broaden scope (pass url for one recording, omit for all), and the failure mode when misused (call_not_active once hung up). It also names what is explicitly out of scope for this call, routing the agent away from stop_audio and stop_speaking.

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