Skip to main content
Glama

Collect keypad input

gather_dtmf
Destructive

Create a hosted IVR step that plays a prompt, collects DTMF keypad digits, stores them for retrieval, and can move a live Vobiz call into it.

Instructions

Create a hosted IVR step that plays a prompt and collects keypad (DTMF) digits with Vobiz : the digits are posted back to this server, signature-checked and stored, and you read them with get_gather_result and the returned flow_id. Give call_uuid (+ confirm: true) to move a LIVE call into the step now (a transfer: its current flow stops), or use the returned url as make_call answer_url or unhold_call resume_url for a call that is not up yet. Input ends after num_digits, on finish_on_key, or after digit_end_timeout of silence between keys, then then runs (default: say 'Thank you' and hang up). If nothing is pressed within execution_timeout the prompt ends without posting a result, so get_gather_result keeps reporting waiting; check the call with get_call_status. To press keys on a remote IVR yourself use send_dtmf; for free-form flows use generate_answer_xml. The step lives 24 hours in this server's memory. HTTP mode with VOBIZ_PUBLIC_URL only.

Input Schema

NameRequiredDescriptionDefault
thenNoUp to 10 XML actions (same format as generate_answer_xml) run after input is received, e.g. speak a confirmation then dial. Default: say 'Thank you' and hang up.
confirmNoRequired (true) with call_uuid, set only after the user agreed: the transfer replaces the live call's current flow. Ignored without call_uuid.
languageNoLocale for speaking prompt_text, e.g. en-US (default), en-IN, hi-IN, de-DE. Ignored without prompt_text.
call_uuidNoUUID of a LIVE call to move into this step right now (the request_uuid from make_call, or from list_live_calls). Omit to only create the step and get its url.
num_digitsNoDigits to collect before the input is submitted, 1-32 (default 32). Use 1 for a single-key menu.
prompt_textNoSpoken prompt (text-to-speech, max 1000 characters), e.g. 'Press 1 for sales'. Give this and/or prompt_audio_url.
finish_on_keyNoKey that submits the digits early (default #). none: submit only on num_digits or digit_end_timeout, so # counts as a digit.
prompt_audio_urlNohttps .mp3/.wav played as the prompt, after prompt_text when both are given.
digit_end_timeoutNoSeconds of silence between keys after which the digits entered so far are submitted: 2-10, or auto (default).
execution_timeoutNoSeconds to wait for the first key after the prompt finishes, 5-60 (default 15).

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`.
urlNohttps URL of the step's XML, usable as make_call answer_url or unhold_call resume_url (valid 24 hours, lost on server restart).
xmlNoThe generated <Gather> VobizXML, for inspection.
noteNoHow to read the result.
flow_idNo32-hex id of the hosted step; pass it to get_gather_result to read the digits.
transferredNoTrue when call_uuid was given and Vobiz accepted moving that call into the step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv1.4.2
    • changedInput schema / properties / call_uuid / description
      Previous value: -"Live call to move into this step now."New value: +"UUID of a LIVE call to move into this step right now (the request_uuid from make_call, or from list_live_calls). Omit to only create the step and get its url."
    • changedInput schema / properties / confirm / description
      Previous value: -"Required (true) with call_uuid: this replaces the live call's current flow."New value: +"Required (true) with call_uuid, set only after the user agreed: the transfer replaces the live call's current flow. Ignored without call_uuid."
    • addedInput schema / properties / digit_end_timeout / description
      Added value: +"Seconds of silence between keys after which the digits entered so far are submitted: 2-10, or auto (default)."
    • changedInput schema / properties / execution_timeout / description
      Previous value: -"Seconds to wait for input (default 15)."New value: +"Seconds to wait for the first key after the prompt finishes, 5-60 (default 15)."
    • addedInput schema / properties / finish_on_key / description
      Added value: +"Key that submits the digits early (default #). none: submit only on num_digits or digit_end_timeout, so # counts as a digit."
    • addedInput schema / properties / language / description
      Added value: +"Locale for speaking prompt_text, e.g. en-US (default), en-IN, hi-IN, de-DE. Ignored without prompt_text."
    • addedInput schema / properties / num_digits / description
      Added value: +"Digits to collect before the input is submitted, 1-32 (default 32). Use 1 for a single-key menu."
    • changedInput schema / properties / prompt_audio_url / description
      Previous value: -"Or an https .mp3/.wav prompt."New value: +"https .mp3/.wav played as the prompt, after prompt_text when both are given."
    • changedInput schema / properties / prompt_text / description
      Previous value: -"Spoken prompt, e.g. 'Press 1 for sales'."New value: +"Spoken prompt (text-to-speech, max 1000 characters), e.g. 'Press 1 for sales'. Give this and/or prompt_audio_url."
    • changedInput schema / properties / then / description
      Previous value: -"XML actions to run after input is received (default: 'Thank you' and hang up)."New value: +"Up to 10 XML actions (same format as generate_answer_xml) run after input is received, e.g. speak a confirmation then dial. Default: say 'Thank you' and hang up."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "flow_id": {
      +      "description": "32-hex id of the hosted step; pass it to get_gather_result to read the digits.",
      +      "type": "string"
      +    },
      +    "note": {
      +      "description": "How to read the result.",
      +      "type": "string"
      +    },
      +    "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"
      +    },
      +    "transferred": {
      +      "description": "True when call_uuid was given and Vobiz accepted moving that call into the step.",
      +      "type": "boolean"
      +    },
      +    "url": {
      +      "description": "https URL of the step's XML, usable as make_call answer_url or unhold_call resume_url (valid 24 hours, lost on server restart).",
      +      "type": "string"
      +    },
      +    "xml": {
      +      "description": "The generated <Gather> VobizXML, for inspection.",
      +      "type": "string"
      +    }
      +  },
      +  "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?

Far exceeds the annotation bar: digits are posted back, signature-checked and stored, read via get_gather_result with flow_id; a live transfer replaces and stops the call's current flow; input-ending conditions (num_digits, finish_on_key, digit_end_timeout) and post-input `then` behavior; the timeout path leaves get_gather_result reporting waiting; step TTL of 24h; HTTP mode requires VOBIZ_PUBLIC_URL. This is unusually rich behavioral disclosure.

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?

Front-loaded with purpose and creation, then live-transfer usage, then termination conditions, then alternatives. Dense and generally efficient, though a few sentences are long and clause-heavy, and the 24h/HTTP-mode constraints are appended without a clear structural break.

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-value explanation is not required, and the description still covers creation vs. live-transfer modes, the result-retrieval path, timeout semantics, and environment prerequisites. Nothing needed to call it correctly appears missing.

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 description coverage is 100% (baseline 3), but the description adds meaning beyond it by explaining how num_digits, finish_on_key, and digit_end_timeout interact to terminate input, that the default `then` says 'Thank you' and hangs up, and that confirm:true is what makes the transfer destructive. That elevates it above the schema-only baseline.

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: 'Create a hosted IVR step that plays a prompt and collects keypad (DTMF) digits with Vobiz <Gather>'. It explicitly distinguishes itself from siblings send_dtmf (to press keys on a remote IVR) and generate_answer_xml (for free-form flows), and names get_gather_result as the reader of the result.

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 selection criteria: pass call_uuid + confirm:true to move a LIVE call into the step now, or use the returned url as make_call answer_url / unhold_call resume_url for a call not yet up. It also names two alternatives (send_dtmf, generate_answer_xml) with the conditions that select them.

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