Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List configured webhooks

list_webhooks
Read-only

Retrieve all webhook URLs configured on your Vobiz account for applications and SIP trunks, covering answer, hangup, fallback, message, SIP-transfer, and trunk event callbacks.

Instructions

List every webhook URL configured on this Vobiz account: the answer, hangup, fallback, message and SIP-transfer URLs of Applications (used for inbound calls on their linked numbers) and the webhook_url of SIP trunks (CallInitiated and Hangup events, plus recording.completed when enabled). Per-call URLs given to make_call are not included, and callbacks already received are listed by list_webhook_events, not here. Change them with update_application or update_sip_trunk; there is no separate webhook object to create or delete. Reads the first 20 applications (application_list_truncated is true when there are more) and up to 100 trunks.

Input Schema

NameRequiredDescriptionDefault

No arguments

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`.
countNoNumber of webhook entries returned.
webhooksNoOne entry per configured URL, applications first, then SIP trunks.
how_to_changeNoWhich tools update these URLs.
application_list_truncatedNoTrue when the account has more than 20 applications, so some application webhooks are not listed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.2
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "application_list_truncated": {
+      "description": "True when the account has more than 20 applications, so some application webhooks are not listed.",
+      "type": "boolean"
+    },
+    "count": {
+      "description": "Number of webhook entries returned.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "how_to_change": {
+      "description": "Which tools update these URLs.",
+      "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"
+    },
+    "webhooks": {
+      "description": "One entry per configured URL, applications first, then SIP trunks.",
+      "items": {
+        "additionalProperties": {},
+        "properties": {
+          "events": {
+            "description": "SIP trunks only: the event names delivered to webhook_url.",
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          },
+          "id": {
+            "description": "app_id of the application or trunk_id of the SIP trunk (null when Vobiz omitted it)."
+          },
+          "kind": {
+            "description": "Which URL this is: answer_url, hangup_url, fallback_answer_url, message_url, sip_transfer_url or webhook_url.",
+            "type": "string"
+          },
+          "method": {
+            "description": "HTTP method Vobiz uses for it (GET or POST), or null when not set."
+          },
+          "name": {
+            "description": "Display name of the application or trunk, or null."
+          },
+          "source": {
+            "description": "Which object the webhook is configured on.",
+            "enum": [
+              "application",
+              "sip_trunk"
+            ],
+            "type": "string"
+          },
+          "url": {
+            "description": "The configured https URL."
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "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?

Annotations only declare readOnlyHint/openWorldHint; the description adds real operational context beyond that: reads are limited to the first 20 applications with application_list_truncated flagging overflow, and up to 100 trunks. It also clarifies the mutability model (no standalone webhook object).

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 enumeration, then progressively narrower constraints. It is dense—one long opening sentence—but each following sentence (exclusions, alternatives, pagination) carries distinct information rather than 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?

An output schema exists, so return-value documentation is not required, yet the description still surfaces the key output signal (application_list_truncated) and the scoping limits. Combined with the exhaustive scope definition and alternatives, an agent has everything needed to select and call this correctly.

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?

Zero parameters, so the baseline is 4 per the rubric. The description has no parameter behavior to explain, and nothing about the schema needs compensating for.

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 (list webhook URLs on this account) and then enumerates exactly what counts as a webhook: Application URLs (answer, hangup, fallback, message, SIP-transfer) and SIP trunk webhook_url events. It crisply distinguishes itself from list_webhook_events and from per-call URLs passed to make_call.

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/when-not guidance: per-call URLs from make_call are excluded, received callbacks belong in list_webhook_events, and modifications belong in update_application/update_sip_trunk. It even rules out a category of operation ('no separate webhook object to create or delete'), leaving nothing to infer.

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