Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Release a phone number

release_phone_number
Destructive

Release a phone number from your Vobiz account, charging the release fee and stopping call service. Use immediate mode to skip the cancellable 24-hour cooldown.

Instructions

Release a phone number from this Vobiz account (DELETE /numbers/{e164}). This charges the account's number-release fee (returned as release_fee) and the number stops serving calls. By default it enters pending_release for a 24-hour cooldown, during which cancel_number_release restores it and refunds the fee; after that window the number leaves the account and may not be recoverable. immediate: true skips the cooldown and cannot be cancelled. To hand a number to a sub-account instead of giving it up, use assign_number_to_subaccount. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "phone_number": "<phone_number>",
      "confirm": "<confirm>"
    },
    "name": "release_phone_number"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true, set only after the user explicitly approved: releasing this number and paying the release fee. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved.
immediateNotrue skips the 24-hour cancellable cooldown; the release then cannot be cancelled. Default false.
phone_numberYesThe number to release, E.164, from list_phone_numbers.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
noteNoWhat to do next, in plain words.
statusNoThe number's new state, typically pending_release or released, or null.
cancellableNotrue when cancel_number_release can still restore the number.
http_statusNoHTTP status Vobiz answered with.
release_feeNoFee charged for the release, as Vobiz reports it, or null.
phone_numberNoThe number, E.164.
backend_messageNoMessage from Vobiz about the operation, or null.
cooldown_ends_atNoWhen the cancellable cooldown ends (ISO 8601), or null for an immediate release.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.2
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true, set only after the user explicitly approved: releasing this number and paying the release fee."New value: +"Must be true, set only after the user explicitly approved: releasing this number and paying the release fee. If your client supports MCP elicitation, the server asks the user to approve directly and this flag is not relied on; otherwise it is your attestation that the user approved."
    • changedInput schema / properties / immediate / description
      Previous value: -"Skip the 24-hour cancellable cooldown. The release then cannot be cancelled."New value: +"true skips the 24-hour cancellable cooldown; the release then cannot be cancelled. Default false."
    • addedInput schema / properties / phone_number / description
      Added value: +"The number to release, E.164, from list_phone_numbers."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "backend_message": {
+      "description": "Message from Vobiz about the operation, or null."
+    },
+    "cancellable": {
+      "description": "true when cancel_number_release can still restore the number.",
+      "type": "boolean"
+    },
+    "cooldown_ends_at": {
+      "description": "When the cancellable cooldown ends (ISO 8601), or null for an immediate release."
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "note": {
+      "description": "What to do next, in plain words."
+    },
+    "ok": {
+      "description": "true on success; false (with error and message) when the tool failed.",
+      "type": "boolean"
+    },
+    "phone_number": {
+      "description": "The number, E.164.",
+      "type": "string"
+    },
+    "release_fee": {
+      "description": "Fee charged for the release, as Vobiz reports it, or null."
+    },
+    "status": {
+      "description": "The number's new state, typically pending_release or released, or null."
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds substantial context beyond them: a release fee is charged and returned as release_fee, the number stops serving calls, a 24-hour pending_release cooldown applies during which cancel_number_release refunds the fee, and after which the number is unrecoverable. The immediate path is disclosed as non-cancellable. Strong disclosure; only minor gaps (no explicit permission model detail beyond the env gate).

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 core action and endpoint, then consequences, alternatives, and gating in a logical order. It is dense with clauses but each carries distinct information; a small amount of redundancy between the immediate discussion and the schema description costs it a point.

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, account-affecting tool the description covers fees, service impact, cooldown window, recovery path, irreversibility, alternatives, and gating flags. With an output schema present, return-value detail (release_fee) is mentioned but not required, so nothing an agent needs 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 coverage is 100%, so baseline is 3. The description goes slightly further by tying the confirm flag to the account-gating and approval requirement and linking immediate to irreversible loss of the cooldown, though it largely restates what the schema already documents for immediate.

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 ('Release a phone number from this Vobiz account') and even includes the underlying endpoint (DELETE /numbers/{e164}). It explicitly distinguishes itself from siblings cancel_number_release and assign_number_to_subaccount, so an agent can route correctly without opening schemas.

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 and when-to-use-something-else guidance: release vs. hand to a sub-account (assign_number_to_subaccount) vs. undo (cancel_number_release). It also spells out the preconditions (VOBIZ_ENABLE_PROVISIONING gate, confirm: true) and the immediate flag's trade-off.

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