Vobiz MCP Server

Official

by vobiz-ai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Update SIP endpoint

update_sip_endpoint

DestructiveIdempotent

Change a Vobiz SIP endpoint's alias, password, attached application, or voice/message/video permissions; only supplied fields change and the username stays fixed.

Instructions

Change a Vobiz SIP endpoint's alias, password, attached application or voice/message/video permissions. Only the fields you pass change; the username is permanent (create a new endpoint to rename). A new password signs out every registered device until it re-registers with it. Vobiz answers 202 with no body, so the result lists the fields sent rather than the new state; read it back with get_sip_endpoint. An unknown endpoint_id raises not_found. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true.

Input Schema

Name	Required	Description
`alias`	No	New friendly name, 1-100 characters.
`confirm`	Yes	Must be true, set only after the user explicitly approved: changing this SIP endpoint.
`password`	No	SECRET: the endpoint's new SIP password (8+ characters; 12+ with mixed case, digits and symbols recommended). It is sent to Vobiz once and never shown again.
`allow_video`	No	Permit video calls on this endpoint (Vobiz default false).
`allow_voice`	No	Permit voice calls on this endpoint (Vobiz default true).
`endpoint_id`	Yes	Numeric SIP endpoint ID (4-25 digits): endpoint_id from list_sip_endpoints or create_sip_endpoint. Unknown ids raise not_found.
`allow_message`	No	Permit messaging on this endpoint (Vobiz default true).
`application_id`	No	Application (app_id from list_applications) that should handle this endpoint's calls from now on; 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	Present after a password change: devices must re-register.
`changed`	No	Names of the fields sent to Vobiz (application_id appears as application).
`updated`	No	True when the change was applied by this call.
`endpoint_id`	No	The endpoint that was changed.
`http_status`	No	HTTP status Vobiz answered with.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.4.2Oct 21, 2026

addedInput schema / properties / alias / description

Added value: +"New friendly name, 1-100 characters."

addedInput schema / properties / allow_message / description

Added value: +"Permit messaging on this endpoint (Vobiz default true)."

addedInput schema / properties / allow_video / description

Added value: +"Permit video calls on this endpoint (Vobiz default false)."

addedInput schema / properties / allow_voice / description

Added value: +"Permit voice calls on this endpoint (Vobiz default true)."

changedInput schema / properties / application_id / description

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

addedInput schema / properties / endpoint_id / description

Added value: +"Numeric SIP endpoint ID (4-25 digits): endpoint_id from list_sip_endpoints or create_sip_endpoint. Unknown ids raise not_found."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "changed": {
+      "description": "Names of the fields sent to Vobiz (application_id appears as application).",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "endpoint_id": {
+      "description": "The endpoint that was changed.",
+      "type": "string"
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "note": {
+      "description": "Present after a password change: devices must re-register.",
+      "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"
+    },
+    "updated": {
+      "const": true,
+      "description": "True when the change was applied by this call.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}

First observedv1.1.1Oct 19, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: PATCH semantics (only passed fields change), the destructive side effect that a new password signs out every registered device, the 202-with-no-body response that echoes fields sent rather than new state, and the not_found error on unknown ids. These are exactly the traits an agent needs and go well past destructiveHint/idempotentHint.

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-loads the core action, then layers constraints, side effects, response shape, and gating in tight sentences. Every sentence carries distinct, load-bearing 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 an 8-parameter mutation tool with an output schema and annotation coverage, the description fills every remaining gap: patch semantics, credential side effects, error behavior, response format, and the confirm/env prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already documented in the schema; the baseline is 3. The description enumerates the mutable field categories but adds no syntax or format detail (patterns, length rules) beyond what the schema provides, though password-rotation consequences are noted.

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 (Change) and resource (a Vobiz SIP endpoint) plus the exact mutable facets: alias, password, attached application, and voice/message/video permissions. It also differentiates from create_sip_endpoint by noting the username is permanent and renaming requires a new endpoint.

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: use create_sip_endpoint to rename, use get_sip_endpoint to read back the new state, and notes the VOBIZ_ENABLE_PROVISIONING gate plus confirm: true. The when-to-use versus alternative tools is fully spelled out.

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

Deploy Server