Vobiz MCP Server

Official

by vobiz-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Create SIP endpoint

create_sip_endpoint

Destructive

Create a Vobiz SIP endpoint so a softphone, desk phone, or WebRTC client can register with a username, password, and call-handling application. Returns its endpoint ID and SIP URI.

Instructions

Create a Vobiz SIP endpoint so a soft-phone, desk phone or WebRTC client can register at registrar.vobiz.ai with its own username and password. Attach an application to handle its calls (otherwise the account's default endpoint application applies, if set). The username cannot be changed later; use update_sip_endpoint for everything else. Returns the endpoint_id and the SIP URI to configure on the device. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true. The password is write-only and never returned; every call creates another endpoint, so a retry after a timeout should first check list_sip_endpoints.

Input Schema

Name	Required	Description
`alias`	Yes	Friendly name shown for the endpoint, 1-100 characters, e.g. Front desk phone.
`confirm`	Yes	Must be true, set only after the user explicitly approved: creating this SIP endpoint.
`password`	Yes	SECRET: the endpoint'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.
`application_id`	No	Application (app_id from list_applications) that handles calls to and from this endpoint; sent to Vobiz as `application`. An unknown id is rejected.

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 to register the device and that the password is never shown again.
`created`	No	True when the record was created by this call.
`sip_uri`	No	SIP URI the device registers as: sip:username@registrar.vobiz.ai.
`endpoint`	No	The endpoint as Vobiz returned it (username, alias, endpoint_id).
`registrar`	No	Registrar host to configure on the device.
`endpoint_id`	No	ID of the new endpoint, or null if Vobiz did not return one.
`http_status`	No	HTTP status Vobiz answered with.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.4.2Oct 21, 2026

changedInput schema / properties / alias / description

Previous value: -"Friendly name, e.g. Front desk phone."New value: +"Friendly name shown for the endpoint, 1-100 characters, e.g. Front desk phone."

changedInput schema / properties / application_id / description

Previous value: -"Application that handles this endpoint's calls (sent as `application`)."New value: +"Application (app_id from list_applications) that handles calls to and from this endpoint; sent to Vobiz as `application`. An unknown id is rejected."

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"
+    },
+    "endpoint": {
+      "additionalProperties": {},
+      "description": "The endpoint as Vobiz returned it (username, alias, endpoint_id).",
+      "properties": {
+        "alias": {
+          "description": "Friendly name.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "allow_message": {
+          "description": "Messaging permitted.",
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "allow_video": {
+          "description": "Video calls permitted.",
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "allow_voice": {
+          "description": "Voice calls permitted.",
+          "type": [
+            "boolean",
+            "null"
+          ]
+        },
+        "application": {
+          "description": "Attached application: an app_id string in lists, an object with app_id, app_name and answer_url in get_sip_endpoint, or null."
+        },
+        "created_at": {
+          "description": "Creation timestamp.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "endpoint_id": {
+          "description": "Numeric endpoint ID.",
+          "type": [
+            "string",
+            "number",
+            "null"
+          ]
+        },
+        "resource_uri": {
+          "description": "API path of the endpoint.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "sip_registered": {
+          "description": "\"true\" while a device is registered, otherwise \"false\".",
+          "type": [
+            "string",
+            "boolean",
+            "null"
+          ]
+        },
+        "sip_registration": {
+          "anyOf": [
+            {
+              "additionalProperties": {},
+              "propertyNames": {
+                "type": "string"
+              },
+              "type": "object"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Present only while registered: contact, expires, user_agent, received."
+        },
+        "sip_uri": {
+          "description": "SIP URI of the endpoint (sip:username@registrar.vobiz.ai).",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "sub_account": {
+          "description": "Owning sub-account Auth ID, or null.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "updated_at": {
+          "description": "Last-change timestamp.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "username": {
+          "description": "SIP username the device registers with.",
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "endpoint_id": {
+      "description": "ID of the new endpoint, or null if Vobiz did not return one.",
+      "type": [
+        "string",
+        "number",
+        "null"
+      ]
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "note": {
+      "description": "How to register the device 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"
+    },
+    "registrar": {
+      "description": "Registrar host to configure on the device.",
+      "type": "string"
+    },
+    "sip_uri": {
+      "description": "SIP URI the device registers as: sip:username@registrar.vobiz.ai.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedv1.1.1Oct 19, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare destructive/non-idempotent/openWorld, and the description adds non-obvious behavior beyond that: the username is immutable after creation, the password is write-only and never returned, a feature-flag gate applies, and repeated calls create duplicate endpoints. This is exactly the mutation/irreversibility context an agent needs before invoking.

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?

Five tight sentences, front-loaded with purpose and use case, then attach behavior, immutability, return values, gating, and retry guidance. No filler or restatement of the tool name; every sentence carries actionable content.

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?

Covers the full picture for a gated, destructive, non-idempotent creation tool: prerequisites, immutability, secret handling, defaults, duplicate risk, and where to look on retry. With an output schema present it does not need to detail return values, yet still names them usefully.

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 real meaning the schema lacks: the immutability of username, the write-only nature of password, and the fallback semantics for application_id ('otherwise the account's default endpoint application applies, if set'). It does not, however, clarify the alias/confirm fields beyond what the schema already documents.

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 ('Create a Vobiz SIP endpoint') and immediately scopes it to the concrete use case (soft-phone, desk phone, WebRTC client registering at registrar.vobiz.ai). It explicitly names the sibling it is not (update_sip_endpoint) and distinguishes itself from list_sip_endpoints, so an agent can route without opening either schema.

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, when-not-to-use ('use update_sip_endpoint for everything else'), and a retry/duplicate hazard rule ('every call creates another endpoint, so a retry after a timeout should first check list_sip_endpoints'). Preconditions (VOBIZ_ENABLE_PROVISIONING, confirm: true) are stated inline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server