Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get SIP endpoint

get_sip_endpoint
Read-only

Retrieve a Vobiz SIP endpoint by endpoint_id to view its SIP URI, permissions, attached application, and registration status, so you can check whether a soft-phone or WebRTC client is online.

Instructions

Return one Vobiz SIP endpoint by endpoint_id: username, alias, SIP URI, voice/message/video permissions, the attached application (app_id, name, answer_url) and, while a device is registered, a sip_registration block with contact, expiry and user agent. Use it to check whether a soft-phone or WebRTC client is online; to find the id or browse many endpoints use list_sip_endpoints. An unknown endpoint_id raises not_found. Passwords are never shown here. The user can view or reset them in the Vobiz console.

Input Schema

NameRequiredDescriptionDefault
endpoint_idYesNumeric SIP endpoint ID (4-25 digits): endpoint_id from list_sip_endpoints or create_sip_endpoint. Unknown ids raise not_found.

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`.
noteNoReminder that passwords are never returned here.
endpointNoThe endpoint as Vobiz returned it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.2
    • 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": {
+    "endpoint": {
+      "anyOf": [
+        {
+          "additionalProperties": {},
+          "description": "Endpoint object as Vobiz returned it; any password field is replaced with [redacted].",
+          "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"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "The endpoint as Vobiz returned it."
+    },
+    "note": {
+      "description": "Reminder that passwords are never returned here.",
+      "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"
+}
  2. First observedv1.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description still adds real behavioral context: the sip_registration block only appears while a device is registered, an unknown id raises not_found, and passwords are never returned (with a pointer to the console for viewing/resetting them).

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?

Front-loaded with the action, then the return shape, then routing and error behavior; every sentence carries information. The first sentence is long with a field laundry list, but it is not padded.

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?

An output schema exists, yet the description still summarizes the return payload and the conditional sip_registration block, plus the error case and the password omission. Nothing an agent needs 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.

Parameters3/5

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

Schema description coverage is 100%, so the single endpoint_id parameter (pattern, provenance, not_found behavior) is already fully documented in the schema. The description repeats the not_found behavior but adds no syntax or format detail beyond it, so the baseline 3 applies.

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?

The description states a specific verb and resource ('Return one Vobiz SIP endpoint by endpoint_id') and immediately enumerates the payload, so an agent knows exactly what comes back. It explicitly distinguishes itself from the sibling list_sip_endpoints.

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?

It gives a concrete use case ('check whether a soft-phone or WebRTC client is online') and names the alternative with the condition that selects it ('to find the id or browse many endpoints use list_sip_endpoints'). When-not guidance is implicit in that routing statement but the alternative is explicit.

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