Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update voice application

update_application
DestructiveIdempotent

Modify selected fields of an existing Vobiz voice application—name, webhook URLs, methods, or default-app flags—while keeping app_id and sub_account unchanged.

Instructions

Change selected fields of an existing Vobiz voice application (name, webhook URLs and methods, default-app flags). Only the fields you pass change; app_id and sub_account cannot change. Vobiz resets default_endpoint_app to false whenever it is omitted, so this tool reads the current value and re-sends it. New URLs must be https on an approved host (VOBIZ_ALLOWED_URL_HOSTS). Use create_application for a new application and update_phone_number to change which application a number uses. An unknown app_id raises not_found. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true.

Input Schema

NameRequiredDescriptionDefault
app_idYesNumeric Vobiz application ID (5-25 digits): the app_id returned by list_applications or create_application.
confirmYesMust be true, set only after the user explicitly approved: changing 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_nameNoApplication name, 1-120 characters: letters, digits, - and _ only (Vobiz rejects other characters).
answer_urlNoURL 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_urlNoURL 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_methodNoHTTP method used to fetch answer_url: GET or POST (Vobiz default POST).
hangup_methodNoHTTP method for hangup_url: GET or POST (Vobiz default POST).
fallback_methodNoHTTP method for fallback_answer_url: GET or POST (Vobiz default POST).
default_number_appNotrue makes this the application for newly bought numbers that have none (Vobiz default false). Existing numbers are not re-routed.
fallback_answer_urlNoFetched 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_appNotrue makes this the application for newly created SIP endpoints that have none; false clears that. Omitted, the current value is re-sent (Vobiz would otherwise reset it to false).

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`.
app_idNoThe application that was changed.
updatedNoTrue when the change was applied by this call.
http_statusNoHTTP status Vobiz answered with.
backend_messageNoStatus message from Vobiz (e.g. 'created' or 'changed'), when it sent one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv1.4.2
    • addedInput schema / properties / answer_method / description
      Added value: +"HTTP method used to fetch answer_url: GET or POST (Vobiz default POST)."
    • changedInput schema / properties / answer_url / description
      Previous value: -"XML URL fetched when a call reaches a number linked to this application (approved host)."New 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_id / description
      Added value: +"Numeric Vobiz application ID (5-25 digits): the app_id returned by list_applications or create_application."
    • 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: changing this application."New value: +"Must be true, set only after the user explicitly approved: changing 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; false clears that. Omitted, the current value is re-sent (Vobiz would otherwise reset it to false)."
    • 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": "The application that was changed.",
+      "type": "string"
+    },
+    "backend_message": {
+      "description": "Status message from Vobiz (e.g. 'created' or 'changed'), when it sent one.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "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"
+    },
+    "updated": {
+      "const": true,
+      "description": "True when the change was applied by this call.",
+      "type": "boolean"
+    }
+  },
+  "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?

Goes well past the annotations (destructive/idempotent/openWorld) by disclosing patch semantics ("Only the fields you pass change"), immutable fields (app_id, sub_account), the vendor quirk that default_endpoint_app resets to false when omitted and the read-and-re-send workaround, https/approved-host URL constraints, the not_found error, and the confirmation gate.

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 action and mutable field list, and nearly every sentence carries distinct information (immutability, quirk, URL policy, alternatives, error, gating). It is dense and slightly overpacked into one paragraph, but there is no filler to cut.

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 destructive, gated, open-world mutation tool, the description covers partial-update semantics, side effects on other state (default_endpoint_app), authorization/confirmation requirements, validation constraints, and error behavior. An output schema exists, so return values need not be described.

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 11 parameters in detail, including the default_endpoint_app re-send behavior and enum defaults. The description adds only the app_id/sub_account immutability note, which is minor; 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 and resource ("Change selected fields of an existing Vobiz voice application") and enumerates the mutable field groups (name, webhook URLs and methods, default-app flags). It explicitly differentiates from siblings by naming create_application and update_phone_number as the tools for other jobs.

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 when-to-use routing ("Use create_application for a new application and update_phone_number to change which application a number uses") plus the operational preconditions (VOBIZ_ENABLE_PROVISIONING gating, confirm: true). An agent knows both when to pick this tool and when to pick another.

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