Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Cancel a pending number release

cancel_number_release
DestructiveIdempotent

Cancel a pending phone number release to restore it to active and refund the release fee within the 24-hour cooldown. Undo a number release.

Instructions

Keep a number that is in pending_release (POST /account/{id}/numbers/{e164}/cancel-release): Vobiz restores it to active and refunds the release fee to the balance. It is the undo of release_phone_number and works only during the 24-hour cooldown. Any trunk or application the release detached must be re-linked with update_phone_number. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true.

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true, set only after the user explicitly approved: cancelling the release of this number. 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.
phone_numberYesThe number in pending_release, E.164.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
noteNoReminder to re-link the trunk or application.
statusNoThe number's state after the cancel, typically active, or null.
currencyNoCurrency of the refund, or null.
http_statusNoHTTP status Vobiz answered with.
phone_numberNoThe number, E.164.
refund_errorNoWhy the refund failed, if it did, else null.
refund_amountNoRelease fee refunded, or null.
refund_statusNoState of the refund as Vobiz reports it, or null.
backend_messageNoMessage from Vobiz about the operation, or null.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.2
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true, set only after the user explicitly approved: cancelling the release of this number."New value: +"Must be true, set only after the user explicitly approved: cancelling the release of this number. 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."
    • addedInput schema / properties / phone_number / description
      Added value: +"The number in pending_release, E.164."
    • 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."
+    },
+    "currency": {
+      "description": "Currency of the refund, or null."
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "note": {
+      "description": "Reminder to re-link the trunk or application.",
+      "type": "string"
+    },
+    "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"
+    },
+    "refund_amount": {
+      "description": "Release fee refunded, or null."
+    },
+    "refund_error": {
+      "description": "Why the refund failed, if it did, else null."
+    },
+    "refund_status": {
+      "description": "State of the refund as Vobiz reports it, or null."
+    },
+    "status": {
+      "description": "The number's state after the cancel, typically active, or null."
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already disclose readOnly=false, idempotent=true, destructive=true, and openWorld=true. The description adds substantial context beyond those hints: it restores the number to active, refunds the release fee, has a 24-hour validity window, requires re-linking of any detached trunk or application, and is gated by an environment flag and confirm flag. This is exactly the kind of side-effect and prerequisite disclosure that annotations cannot provide.

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?

Four sentences, front-loaded with the core action and endpoint. Each subsequent sentence adds a distinct operational fact—undo relationship, cooldown window, re-linking requirement, and gating—with no redundancy or 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?

An output schema exists, so return values need not be explained. The description covers prerequisites, side effects, alternative tool, and required follow-up actions, making it complete for a complex provisioning operation that involves refunds and re-linking.

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 both parameters are fully documented in the schema. The description mentions the confirm gate and the environment flag, but adds no new syntax or format detail for phone_number beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Keep a number that is in pending_release'), gives the exact endpoint, and explicitly distinguishes itself from the sibling tool by calling itself 'the undo of release_phone_number.' An agent can immediately tell what it does and how it differs from release_phone_number.

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?

Provides clear when-to-use context: the number must be in pending_release, the operation only works during the 24-hour cooldown, and it is gated by VOBIZ_ENABLE_PROVISIONING and confirm: true. It also names the follow-up action (re-link detached trunks/applications with update_phone_number), leaving no ambiguity about prerequisites or post-conditions.

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