Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Send DTMF digits

send_dtmf
Destructive

Sends keypad tones on a live call to navigate remote IVRs or enter digits, supporting 0-9, *, #, and pause characters. Use when an active call must receive DTMF input.

Instructions

Send keypad tones on a LIVE call (POST /Account/{auth_id}/Call/{call_uuid}/DTMF/), as if the user pressed the keys: digits 0-9, *, #; w = 0.5 s pause, W = 1 s pause. Use it only when the user asked to press keys on an active call (e.g. navigating a remote IVR). To collect keys FROM the other party use gather_dtmf instead. The tones are sent once and cannot be recalled; a call that is not live fails with call_not_active.

Input Schema

NameRequiredDescriptionDefault
legsNoWhich call leg hears the tones: aleg (the call's first leg, default), bleg (the party bridged by <Dial>) or both.
digitsYesKey sequence to send, 1-64 characters of 0-9 * # w W, e.g. 1w2# (press 1, wait half a second, press 2, then #).
call_uuidYesUUID of the live call: the request_uuid from 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`.
sentNoTrue once Vobiz accepted the digits for sending.
call_uuidNoThe call UUID the request was about, echoed back.
http_statusNoHTTP status Vobiz answered with.
backend_messageNoVobiz's own confirmation text, or null when it sent none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.2
    • changedInput schema / properties / call_uuid / description
      Previous value: -"UUID of the live call."New value: +"UUID of the live call: the request_uuid from make_call, or a UUID from list_live_calls."
    • changedInput schema / properties / digits / description
      Previous value: -"Digits to send, e.g. 1w2#"New value: +"Key sequence to send, 1-64 characters of 0-9 * # w W, e.g. 1w2# (press 1, wait half a second, press 2, then #)."
    • changedInput schema / properties / legs / description
      Previous value: -"Which call leg hears the tones (default aleg)."New value: +"Which call leg hears the tones: aleg (the call's first leg, default), bleg (the party bridged by <Dial>) or both."
    • 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, or null when it sent none.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "call_uuid": {
+      "description": "The call UUID the request was about, echoed back.",
+      "type": "string"
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "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"
+    },
+    "sent": {
+      "const": true,
+      "description": "True once Vobiz accepted the digits for sending.",
+      "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 flag destructive/non-idempotent, and the description reinforces this with 'the tones are sent once and cannot be recalled' and adds the concrete failure mode ('a call that is not live fails with call_not_active'), which annotations cannot express. It also documents the tone alphabet and pause semantics.

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 scope, then routing guidance, then behavioral caveats. Every sentence carries distinct information (endpoint, alphabet, when-to-use, alternative, failure mode) with 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?

With annotations, a 100%-covered schema, and an output schema present, the description fills exactly the remaining gaps: usage conditions, the sibling alternative, irreversibility, and the live-call precondition with its error code.

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 beyond it by spelling out the pause semantics ('w' = 0.5 s, 'W' = 1 s) and the valid character set, details the schema only implies through its example. The legs parameter is still left entirely to the schema.

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+resource ('Send keypad tones on a LIVE call'), names the exact endpoint, and explicitly distinguishes itself from gather_dtmf, which is the tool an agent could most plausibly confuse it with.

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 when-to-use ('only when the user asked to press keys on an active call, e.g. navigating a remote IVR') plus a named alternative for the inverse operation ('To collect keys FROM the other party use gather_dtmf instead'). Both the selection condition and the exclusion are stated.

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