Vobiz MCP Server

Official

by vobiz-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Create voice application

create_application

Destructive

Create a Vobiz voice application to define webhook URLs for inbound calls, then link its app_id to phone numbers or SIP endpoints.

Instructions

Create a Vobiz voice application: the set of webhook URLs Vobiz calls for inbound calls on the numbers and SIP endpoints linked to it. Only app_name and answer_url are required; hangup_url defaults to answer_url and every URL must be https on an approved host (VOBIZ_ALLOWED_URL_HOSTS). Returns the new app_id; link it afterwards with update_phone_number (application_id) or create_sip_endpoint (application_id). To change an existing application use update_application. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true. Every call creates another application, so after a timeout check list_applications before retrying.

Input Schema

Name	Required	Description
`confirm`	Yes	Must be true, set only after the user explicitly approved: creating this application. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved.
`app_name`	Yes	Application name, 1-120 characters: letters, digits, - and _ only (Vobiz rejects other characters).
`answer_url`	Yes	URL Vobiz fetches for VobizXML when a call reaches a number or SIP endpoint linked to this application. Must be https on an approved host (VOBIZ_ALLOWED_URL_HOSTS) and answer within 10 seconds.
`hangup_url`	No	URL Vobiz notifies when a call on this application ends (CallUUID, CallStatus, Duration, HangupCause). Omitted at creation, it defaults to answer_url. Must be https on an approved host.
`answer_method`	No	HTTP method used to fetch answer_url: GET or POST (Vobiz default POST).
`hangup_method`	No	HTTP method for hangup_url: GET or POST (Vobiz default POST).
`fallback_method`	No	HTTP method for fallback_answer_url: GET or POST (Vobiz default POST).
`default_number_app`	No	true makes this the application for newly bought numbers that have none (Vobiz default false). Existing numbers are not re-routed.
`fallback_answer_url`	No	Fetched only when answer_url is unreachable, times out or returns invalid VobizXML; must itself return VobizXML. Without one the call drops on answer_url failure. Must be https on an approved host.
`default_endpoint_app`	No	true makes this the application for newly created SIP endpoints that have none (Vobiz default false). Existing endpoints are not re-routed.

Output Schema

Name	Required	Description
`ok`	No	True on success. On a failure the result is isError with ok: false plus `error` (kind), `message`, `retryable` and sometimes `http_status`.
`app_id`	No	ID of the new application; use it as app_id or application_id elsewhere. Null if Vobiz did not return one.
`created`	No	True when the record was created by this call.
`http_status`	No	HTTP status Vobiz answered with.
`backend_message`	No	Status message from Vobiz (e.g. 'created' or 'changed'), when it sent one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedv1.4.2Oct 21, 2026

addedInput schema / properties / answer_method / description

Added value: +"HTTP method used to fetch answer_url: GET or POST (Vobiz default POST)."

addedInput schema / properties / answer_url / description

Added value: +"URL Vobiz fetches for VobizXML when a call reaches a number or SIP endpoint linked to this application. Must be https on an approved host (VOBIZ_ALLOWED_URL_HOSTS) and answer within 10 seconds."

addedInput schema / properties / app_name / description

Added value: +"Application name, 1-120 characters: letters, digits, - and _ only (Vobiz rejects other characters)."

changedInput schema / properties / confirm / description

Previous value: -"Must be true, set only after the user explicitly approved: creating this application."New value: +"Must be true, set only after the user explicitly approved: creating this application. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved."

addedInput schema / properties / default_endpoint_app / description

Added value: +"true makes this the application for newly created SIP endpoints that have none (Vobiz default false). Existing endpoints are not re-routed."

addedInput schema / properties / default_number_app / description

Added value: +"true makes this the application for newly bought numbers that have none (Vobiz default false). Existing numbers are not re-routed."

addedInput schema / properties / fallback_answer_url / description

Added value: +"Fetched only when answer_url is unreachable, times out or returns invalid VobizXML; must itself return VobizXML. Without one the call drops on answer_url failure. Must be https on an approved host."

addedInput schema / properties / fallback_method / description

Added value: +"HTTP method for fallback_answer_url: GET or POST (Vobiz default POST)."

addedInput schema / properties / hangup_method / description

Added value: +"HTTP method for hangup_url: GET or POST (Vobiz default POST)."

addedInput schema / properties / hangup_url / description

Added value: +"URL Vobiz notifies when a call on this application ends (CallUUID, CallStatus, Duration, HangupCause). Omitted at creation, it defaults to answer_url. Must be https on an approved host."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "app_id": {
+      "description": "ID of the new application; use it as app_id or application_id elsewhere. Null if Vobiz did not return one.",
+      "type": [
+        "string",
+        "number",
+        "null"
+      ]
+    },
+    "backend_message": {
+      "description": "Status message from Vobiz (e.g. 'created' or 'changed'), when it sent one.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "created": {
+      "const": true,
+      "description": "True when the record was created by this call.",
+      "type": "boolean"
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "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"
+    }
+  },
+  "type": "object"
+}

First observedv1.1.1Oct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the destructiveHint/openWorldHint/idempotentHint annotations by disclosing the feature gate, the explicit user-approval requirement, the https/approved-host constraint on every URL, and the concrete hazard that each retry after a timeout creates another application. That last point is exactly the kind of non-idempotency detail an agent needs and the annotation alone 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?

Front-loaded with the purpose and kept to two sentences, but the second sentence is very dense, stacking linking, the alternative tool, gating, the confirm flag, and the retry hazard. Efficient overall, though a bulleted split would read better.

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 notes the app_id. For a 10-parameter destructive, non-idempotent creation tool with a feature gate, the description covers approval, preconditions, linking follow-up, and retry safety — nothing an agent needs 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%, so the schema already documents all ten parameters in detail. The description consolidates a few facts (only app_name and answer_url required, hangup_url defaults to answer_url, all URLs must be https on an approved host) but it largely restates what the schema properties already say. Baseline 3 is appropriate.

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 and then defines the resource concretely: 'the set of webhook URLs Vobiz calls for inbound calls on the numbers and SIP endpoints linked to it.' This lets an agent distinguish it from update_application and create_sip_endpoint without opening any schema.

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 routes alternatives: use update_application to change an existing app, and link afterwards via update_phone_number(application_id) or create_sip_endpoint(application_id). It also states preconditions (VOBIZ_ENABLE_PROVISIONING, confirm:true) and a recovery path after timeouts (check list_applications before retrying).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server