Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List SIP trunks

list_sip_trunks
Read-only

Retrieve SIP trunks on an account with names, domains, status, direction, and call limits; filter by direction and page through results.

Instructions

List the SIP trunks on this account (GET /trunks): name, domain, status, direction, CPS and concurrent-call limits. SIP username and password are replaced by "[redacted]". Paging is stateless: pass limit and offset on every call and follow pagination.next_offset until has_more is false. For one trunk's full configuration use get_sip_trunk.

Input Schema

NameRequiredDescriptionDefault
limitNoTrunks per page, 1-100. Defaults to the server's VOBIZ_DEFAULT_PAGE_SIZE (20).
offsetNoNumber of trunks to skip before the page starts (default 0). Pass pagination.next_offset from the previous page.
directionNoOnly trunks of this direction: inbound, outbound, or both. Omit to list every trunk.

Output Schema

NameRequiredDescriptionDefault
okNoTrue on success; false when the result is an error (then error, message and retryable are set).
countNoNumber of trunks on this page.
trunksNoTrunks on this page.
paginationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.2
    • addedInput schema / properties / direction / description
      Added value: +"Only trunks of this direction: inbound, outbound, or both. Omit to list every trunk."
    • changedInput schema / properties / limit / description
      Previous value: -"Max 100. Defaults to the server's VOBIZ_DEFAULT_PAGE_SIZE (20)."New value: +"Trunks per page, 1-100. Defaults to the server's VOBIZ_DEFAULT_PAGE_SIZE (20)."
    • addedInput schema / properties / offset / description
      Added value: +"Number of trunks to skip before the page starts (default 0). Pass pagination.next_offset from the previous page."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "count": {
+      "description": "Number of trunks on this page.",
+      "type": "number"
+    },
+    "ok": {
+      "description": "True on success; false when the result is an error (then error, message and retryable are set).",
+      "type": "boolean"
+    },
+    "pagination": {
+      "additionalProperties": {},
+      "properties": {
+        "has_more": {
+          "description": "True when another page exists.",
+          "type": "boolean"
+        },
+        "limit": {
+          "description": "Page size that was applied.",
+          "type": "number"
+        },
+        "next_offset": {
+          "description": "Offset to pass for the next page, or null on the last page.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "offset": {
+          "description": "Offset that was applied.",
+          "type": "number"
+        },
+        "total": {
+          "description": "Total trunks on the account, or null when Vobiz did not report it.",
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "trunks": {
+      "description": "Trunks on this page.",
+      "items": {
+        "description": "One SIP trunk: id, name, domain, status, direction, CPS and concurrent-call limits, transport, recording settings; username and password are \"[redacted]\"."
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: that SIP username and password are redacted as '[redacted]' in results, and that paging is stateless with a defined termination loop. It omits auth/rate-limit details, so it stops short of a 5.

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-loaded with purpose, then returned fields, redaction caveat, paging mechanics, and the routing hint to the sibling. Four tight sentences with no filler; every clause carries information.

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 filtered, paginated read tool with an output schema, the description covers everything an agent needs: scope, returned fields, redaction of sensitive values, pagination protocol, and when to prefer the sibling tool. Nothing material 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 description coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by framing the whole paging model as stateless and specifying the loop-termination condition via has_more, which is essential to using limit/offset 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?

States a specific verb and resource ('List the SIP trunks on this account'), names the underlying endpoint, enumerates the returned fields, and explicitly contrasts with the sibling get_sip_trunk. An agent can distinguish this from get_sip_trunk 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?

Names the alternative for a different need ('For one trunk's full configuration use get_sip_trunk') and gives the exact calling protocol for paging ('pass limit and offset on every call and follow pagination.next_offset until has_more is false'). The condition selecting each path 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