Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Add trunk IP ACL entry

add_ip_acl_entry
Destructive

Allow-list a public IPv4 address or CIDR range to let static-IP PBX, SBC, or carrier devices use Vobiz trunks without digest credentials. Attach to a trunk via update_sip_trunk.

Instructions

Allow-list a public IPv4 address or CIDR range (e.g. 198.51.100.42 or 10.20.30.0/24) so a static-IP PBX, SBC or carrier can use Vobiz trunks without digest credentials. Attach it to a trunk with update_sip_trunk (ipacl_uuid); for peers on dynamic IPs use create_trunk_credential instead. The server rejects ranges wider than /8, host bits set in a CIDR, and non-unicast or loopback addresses; IPv6 is not accepted. Returns the entry's id. Remove it later with delete_ip_acl_entry. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true.

Input Schema

NameRequiredDescriptionDefault
nameYesLabel of 1-255 characters, e.g. Office PBX. Returned by Vobiz as `description`.
confirmYesMust be true, set only after the user explicitly approved: allow-listing this IP address for SIP traffic.
ip_addressYesPublic IPv4 address (198.51.100.42) or IPv4 CIDR network (10.20.30.0/24, prefix 8-32, no host bits). Use the peer's public address, not a NAT-internal one.

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`.
createdNoTrue when the record was created by this call.
ip_acl_idNoUUID of the new entry: use it as ipacl_uuid on a trunk. Null if Vobiz did not return one.
http_statusNoHTTP status Vobiz answered with.
ip_acl_entryNoThe entry as Vobiz returned it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.2
    • changedInput schema / properties / ip_address / description
      Previous value: -"IPv4 address or IPv4 CIDR block."New value: +"Public IPv4 address (198.51.100.42) or IPv4 CIDR network (10.20.30.0/24, prefix 8-32, no host bits). Use the peer's public address, not a NAT-internal one."
    • changedInput schema / properties / name / description
      Previous value: -"Label, e.g. Office PBX. Returned as `description`."New value: +"Label of 1-255 characters, e.g. Office PBX. Returned by Vobiz as `description`."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "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"
+    },
+    "ip_acl_entry": {
+      "additionalProperties": {},
+      "description": "The entry as Vobiz returned it.",
+      "properties": {
+        "account_id": {
+          "description": "Owning account Auth ID.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "created_at": {
+          "description": "Creation timestamp.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "description": {
+          "description": "Label given as name when the entry was created.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "enabled": {
+          "description": "False while the entry is switched off.",
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "id": {
+          "description": "IP ACL entry UUID; use it as ipacl_uuid on a trunk or ip_acl_id here.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "ip_address": {
+          "description": "Allow-listed IPv4 address or CIDR block.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "updated_at": {
+          "description": "Last-change timestamp.",
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "ip_acl_id": {
+      "description": "UUID of the new entry: use it as ipacl_uuid on a trunk. Null if Vobiz did not return one.",
+      "type": [
+        "string",
+        "number",
+        "null"
+      ]
+    },
+    "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"
+}
  2. First observedv1.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructive/non-idempotent/write behavior, and the description adds substantial context beyond them: server-side validation rules (/8 width limit, host bits, non-unicast/loopback rejection, no IPv6), the provisioning gate plus confirm requirement, and the return value. This is unusually rich disclosure of side effects and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose plus examples, then attachment, alternative, validation, return value, cleanup, and gating. Every clause carries actionable information with no 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?

For a 3-parameter mutation tool with an output schema and safety annotations, the description covers purpose, alternatives, attach/remove workflow, validation rejection cases, and the provisioning/confirm gate. An agent has everything needed to invoke it 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by stating the accepted formats (198.51.100.42, 10.20.30.0/24), the /8 rejection rule, and that confirm must follow explicit user approval. It stops short of explaining the name label semantics that the schema already covers.

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 ('Allow-list a public IPv4 address or CIDR range') with concrete examples and the business purpose (static-IP PBX/SBC/carrier trunks without digest credentials). It is clearly distinguished from sibling tools it names, such as create_trunk_credential and delete_ip_acl_entry.

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 the agent: attach via update_sip_trunk (ipacl_uuid), use create_trunk_credential instead for dynamic-IP peers, and remove later with delete_ip_acl_entry. Preconditions (VOBIZ_ENABLE_PROVISIONING and confirm: true) are stated as well, so nothing about when/when-not is left to inference.

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