Skip to main content
Glama

Generate Vobiz call XML

generate_answer_xml
Read-only

Build a validated VobizXML call flow from ordered actions like speak, play, gather, record, dial, redirect, or hangup; optionally host it and return a usable answer URL.

Instructions

Build a validated VobizXML document from an ordered list of actions: speak, play, wait, gather (DTMF/speech), record, dial (number or sip_uri), redirect, hangup. Text is XML-escaped; callback/redirect URLs must be on approved hosts; dial numbers must pass the server's destination policy (countries, blocked prefixes, allowlist); actions after redirect/hangup are rejected with invalid_input. Without host it only returns the XML (no API call, works in stdio mode) for you to serve yourself as a make_call answer_url. With host: true (HTTP mode with VOBIZ_PUBLIC_URL) this server also serves it for 24 hours and returns a url usable as make_call answer_url, transfer_call aleg_url or unhold_call resume_url; a hosted gather action posts its digits to this server, readable with get_gather_result and the returned flow_id. For a simple keypad menu prefer gather_dtmf, which builds the step for you; this is the general builder.

Input Schema

NameRequiredDescriptionDefault
hostNotrue: also serve the XML from this server for 24 hours and return its url and flow_id (HTTP mode only). Default false: return the XML only.
actionsYes1-20 actions run top to bottom, each an object with `type` plus that element's attributes in snake_case, e.g. [{type:'speak',text:'Hello'},{type:'hangup'}]. A gather's `prompt` holds nested speak/play actions.

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`.
urlNoOnly when hosted: https URL Vobiz fetches the XML from (valid 24 hours, lost on server restart).
xmlNoThe complete VobizXML document (<Response>...</Response>), ready to serve to Vobiz.
hostedNoTrue when this server serves the document at `url`.
methodNoOnly when hosted: the HTTP method to give Vobiz for `url` (answer_method / aleg_method).
flow_idNoOnly when hosted: 32-hex id of the hosted flow; pass it to get_gather_result if the XML contains a gather.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.2
    • changedInput schema / properties / actions / description
      Previous value: -"Ordered actions, e.g. [{type:'speak',text:'Hello'},{type:'hangup'}]"New value: +"1-20 actions run top to bottom, each an object with `type` plus that element's attributes in snake_case, e.g. [{type:'speak',text:'Hello'},{type:'hangup'}]. A gather's `prompt` holds nested speak/play actions."
    • changedInput schema / properties / host / description
      Previous value: -"Serve the XML from this server and return its URL (HTTP mode only)."New value: +"true: also serve the XML from this server for 24 hours and return its url and flow_id (HTTP mode only). Default false: return the XML only."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "flow_id": {
      +      "description": "Only when hosted: 32-hex id of the hosted flow; pass it to get_gather_result if the XML contains a gather.",
      +      "type": "string"
      +    },
      +    "hosted": {
      +      "description": "True when this server serves the document at `url`.",
      +      "type": "boolean"
      +    },
      +    "method": {
      +      "const": "POST",
      +      "description": "Only when hosted: the HTTP method to give Vobiz for `url` (answer_method / aleg_method).",
      +      "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"
      +    },
      +    "url": {
      +      "description": "Only when hosted: https URL Vobiz fetches the XML from (valid 24 hours, lost on server restart).",
      +      "type": "string"
      +    },
      +    "xml": {
      +      "description": "The complete VobizXML document (<Response>...</Response>), ready to serve to Vobiz.",
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observedv1.1.1

TDQS

A4.6/5.0
Behavior4/5

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

With annotations already declaring readOnlyHint/openWorldHint, the description still adds substantial behavior: XML escaping, approved callback/redirect hosts, dial destination policy (countries, blocked prefixes, allowlist), rejection of actions after redirect/hangup with invalid_input, and the 24-hour hosting lifetime plus flow_id for get_gather_result. The one tension is that hosting creates server-side state for 24 hours, which sits awkwardly with readOnlyHint=true — though the default no-host mode is a pure read/build, so this reads as a qualification rather than a contradiction.

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 the core purpose and action list, and nearly every remaining clause carries load-bearing information (escaping, host allowlist, dial policy, redirect/hangup ordering rule, sibling routing). It is dense — one long paragraph with a couple of run-on clauses — but not padded.

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?

For a complex validator/builder tool with an output schema present, the definition covers the build contract, validation failure modes, mode-dependent return (XML vs url+flow_id), and downstream consumption. Nothing an agent needs in order to call it correctly — or to predict a validation error — is 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 coverage is 100% and the schema already documents `host` and the actions array in detail, so the baseline is met by structure. The description still adds non-schema meaning: why `host` matters (works in stdio without it; requires VOBIZ_PUBLIC_URL in HTTP mode), the ordered-execution model, and the validation rules that constrain `url`, dial `number`, and terminal actions.

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?

Opens with a specific verb+resource: 'Build a validated VobizXML document from an ordered list of actions', then enumerates every supported action type (speak, play, wait, gather, record, dial, redirect, hangup). An agent can immediately tell this apart from the step-specific sibling gather_dtmf.

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?

Explicitly states the alternative and the condition selecting it: 'For a simple keypad menu prefer gather_dtmf, which builds the step for you; this is the general builder.' It also gives the when-to-use split for `host` (stdio/XML-only vs HTTP/hosted) and names the concrete consumers of the returned url (make_call answer_url, transfer_call aleg_url, unhold_call resume_url).

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