Vobiz MCP Server

Official

by vobiz-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Create trunk credential

create_trunk_credential

Destructive

Create a SIP digest credential for trunk authentication on a Vobiz account, enabling dynamic-IP PBXs, remote sites, or voice agents to register; returns credential ID and SIP realm.

Instructions

Create a SIP digest credential (username and password) on this Vobiz account for trunk authentication, for dynamic-IP PBXs, remote sites or voice agents. Attach it to a trunk afterwards with update_sip_trunk (credential_uuid); for static-IP peers use add_ip_acl_entry instead. The username is permanent; rotate the password with update_trunk_credential. Returns the credential id and the realm the SIP client must present. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true. The password is write-only and never returned; every call creates another credential, so a retry after a timeout should first check list_trunk_credentials.

Input Schema

Name	Required	Description
`confirm`	Yes	Must be true, set only after the user explicitly approved: creating this trunk credential.
`password`	Yes	SECRET: the trunk credential's SIP password (8+ characters; 12+ with mixed case, digits and symbols recommended). It is sent to Vobiz once and never shown again.
`username`	Yes	SIP username, 3-64 letters, digits or _, unique on the account and permanent. Letters and digits are safest.

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`.
`note`	No	How the client authenticates and that the password is never shown again.
`created`	No	True when the record was created by this call.
`credential`	No	The credential as Vobiz returned it, password redacted; realm is what the SIP client presents.
`http_status`	No	HTTP status Vobiz answered with.
`credential_id`	No	UUID of the new credential: use it as credential_uuid on a trunk. Null if Vobiz did not return one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.4.2Oct 21, 2026

changedInput schema / properties / username / description

Previous value: -"SIP username, unique on the account and permanent. Letters and digits are safest."New value: +"SIP username, 3-64 letters, digits or _, unique on the account and permanent. Letters and digits are safest."

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"
+    },
+    "credential": {
+      "additionalProperties": {},
+      "description": "The credential as Vobiz returned it, password redacted; realm is what the SIP client presents.",
+      "properties": {
+        "account_id": {
+          "description": "Owning account Auth ID.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "created_at": {
+          "description": "Creation timestamp.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "description": {
+          "description": "Free-text note, if any.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "enabled": {
+          "description": "False while authentication with this credential is paused.",
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "id": {
+          "description": "Credential UUID; use it as credential_uuid on a trunk or credential_id here.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "password": {
+          "description": "Always [redacted]; the real password is never returned.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "realm": {
+          "description": "SIP digest realm the client must present, {account_id}.sip.vobiz.ai.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "updated_at": {
+          "description": "Last-change timestamp.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "username": {
+          "description": "SIP username (permanent).",
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "credential_id": {
+      "description": "UUID of the new credential: use it as credential_uuid on a trunk. Null if Vobiz did not return one.",
+      "type": [
+        "string",
+        "number",
+        "null"
+      ]
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "note": {
+      "description": "How the client authenticates and that the password is never shown again.",
+      "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"
+    }
+  },
+  "type": "object"
+}

First observedv1.1.1Oct 19, 2026

TDQS

A4.8/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 VOBIZ_ENABLE_PROVISIONING + confirm:true gate, that the password is write-only and never returned, that every call creates a new credential (so a timeout retry should first check list_trunk_credentials), and the permanence of the username. These are non-obvious destructive/idempotency details an agent could not infer from structured fields.

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?

Dense but every sentence carries an actionable fact, and the identifying verb+resource is front-loaded. Slightly information-heavy in one block, but 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 destructive, gated mutation with an output schema, the description covers safety gates, side effects, alternatives, and follow-up steps. An agent has everything needed to call it correctly and safely.

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 schema already documents all three parameters well. The description still adds meaning beyond the schema by characterizing the password as write-only/never returned and the username as permanent, reinforcing constraint semantics.

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 (Create) and resource (SIP digest credential for trunk authentication) with the scope of context (dynamic-IP PBXs, remote sites, voice agents). It clearly distinguishes itself from siblings like add_ip_acl_entry and update_sip_trunk.

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 names when to use it, the alternative for the opposite case ('for static-IP peers use add_ip_acl_entry instead'), the follow-up action ('attach it to a trunk afterwards with update_sip_trunk'), and the rotation path ('rotate the password with update_trunk_credential'). Nothing 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