Skip to main content
Glama

Update trunk IP ACL entry

update_ip_acl_entry
DestructiveIdempotent

Replace a Vobiz IP ACL entry's label and trusted IP address; both fields are required, the old address loses trust, and the entry ID stays unchanged for existing trunks.

Instructions

Replace a Vobiz IP ACL entry's label and address. Both name and ip_address are required on every update; resend the current value of the one you keep. Traffic from the old address stops being trusted (changes can take a little time to reach the SIP edge); the entry keeps its id, so trunks referencing it need no change. Read the current values with list_ip_acl_entries first. The same address rules as add_ip_acl_entry apply. An unknown ip_acl_id raises not_found. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true.

Input Schema

NameRequiredDescriptionDefault
nameYesLabel of 1-255 characters (resend the current one to keep it). Returned by Vobiz as `description`.
confirmYesMust be true, set only after the user explicitly approved: changing this IP ACL entry.
ip_acl_idYesIP ACL entry UUID: the id from list_ip_acl_entries or add_ip_acl_entry. Unknown ids raise not_found.
ip_addressYesPublic IPv4 address or IPv4 CIDR network, prefix 8-32 (resend the current one to keep it).

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`.
updatedNoTrue when the change was applied by this call.
http_statusNoHTTP status Vobiz answered with.
ip_acl_entryNoThe entry after the change.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.2
    • addedInput schema / properties / ip_acl_id / description
      Added value: +"IP ACL entry UUID: the id from list_ip_acl_entries or add_ip_acl_entry. Unknown ids raise not_found."
    • changedInput schema / properties / ip_address / description
      Previous value: -"IPv4 address or IPv4 CIDR block (resend the current one to keep it)."New value: +"Public IPv4 address or IPv4 CIDR network, prefix 8-32 (resend the current one to keep it)."
    • changedInput schema / properties / name / description
      Previous value: -"Label for the entry (resend the current one to keep it)."New value: +"Label of 1-255 characters (resend the current one to keep it). Returned by Vobiz as `description`."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "http_status": {
      +      "description": "HTTP status Vobiz answered with.",
      +      "type": "number"
      +    },
      +    "ip_acl_entry": {
      +      "anyOf": [
      +        {
      +          "additionalProperties": {},
      +          "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"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "description": "The entry after the change."
      +    },
      +    "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.7/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the real side effect ("Traffic from the old address stops being trusted"), propagation latency to the SIP edge, id stability so referencing trunks are unaffected, the provisioning gate plus confirm requirement, and the not_found error on unknown ids. These are exactly the traits an agent cannot infer from destructiveHint/idempotentHint alone.

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?

Four tight sentences, action first, then side effects, workflow, error behavior and gating. Parentheticals carry genuine operational detail rather than filler, so nothing is wasted.

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 annotations covering the safety profile and an output schema covering return values, the description fills the remaining gaps: side effects, propagation, idempotency semantics, prerequisites, error case and the confirm/provisioning gate. Nothing needed to call this correctly 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%, so the baseline is 3, but the description adds the non-obvious full-replacement semantics (both name and ip_address required every time, resend the unchanged one) that an agent must understand to invoke this correctly.

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 and resource ("Replace a Vobiz IP ACL entry's label and address") and immediately clarifies the scope is an existing entry's two mutable fields. This clearly separates it from list_ip_acl_entries, add_ip_acl_entry 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete workflow prerequisite ("Read the current values with list_ip_acl_entries first") and explains the PUT-style requirement to resend both fields, which prevents the most likely misuse. It does not explicitly state when to prefer add_ip_acl_entry or delete_ip_acl_entry, so it falls short of full alternative routing.

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