Skip to main content
Glama
vobiz-ai

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Assign a number to a sub-account

assign_number_to_subaccount
DestructiveIdempotent

Move a phone number from a Vobiz main account to a sub-account, so the sub-account uses it for calls and the main account no longer does.

Instructions

Move a number from this Vobiz account's pool to one of its sub-accounts (POST /account/{id}/numbers/{e164}/assign-subaccount). The sub-account then uses the number for its calls and the main account no longer does. The undo is unassign_number_from_subaccount. To find sub-account Auth IDs use list_sub_accounts; to give the number up entirely use release_phone_number. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true.

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true, set only after the user explicitly approved: assigning this number to this sub-account. 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 to move, E.164; it must belong to this main account.
sub_account_idYesAuth ID (SA_...) of the sub-account that will own the number, from list_sub_accounts.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
assignedNotrue once the move is done.
http_statusNoHTTP status Vobiz answered with.
phone_numberNoThe number, E.164.
sub_account_idNoThe sub-account that now owns the number.
backend_messageNoMessage from Vobiz about the operation, or null.

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: assigning this number to this sub-account."New value: +"Must be true, set only after the user explicitly approved: assigning this number to this sub-account. 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 to move, E.164; it must belong to this main account."
    • addedInput schema / properties / sub_account_id / description
      Added value: +"Auth ID (SA_...) of the sub-account that will own the number, from list_sub_accounts."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "assigned": {
+      "description": "true once the move is done.",
+      "type": "boolean"
+    },
+    "backend_message": {
+      "description": "Message from Vobiz about the operation, or null."
+    },
+    "http_status": {
+      "description": "HTTP status Vobiz answered with.",
+      "type": "number"
+    },
+    "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"
+    },
+    "sub_account_id": {
+      "description": "The sub-account that now owns the number.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare destructive=true and idempotent=true, so the safety profile is covered; the description adds real value beyond that by disclosing the ownership-transfer semantics, the environmental gate (VOBIZ_ENABLE_PROVISIONING), and the confirmation requirement. It does not restate any annotation, but it also doesn't detail the return payload (which the output schema handles).

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 action and its consequence in the first sentence, then layers the undo, the lookup helper, the alternative, and the gating condition. Every clause earns its place 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 a destructive, gated mutation with full parameter coverage and an output schema, the description supplies everything an agent needs: what changes, the gate, the confirmation requirement, the undo, and the sibling alternatives. Nothing material 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 baseline is 3. The description reinforces the confirm gating and points to list_sub_accounts as the source for sub_account_id, but these largely duplicate what the detailed schema descriptions already state, so it adds only marginal meaning.

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?

Uses a specific verb ('Move a number') with the resource and destination ('to one of its sub-accounts'), and explicitly frames the effect on both parties: the sub-account uses it, the main account no longer does. It clearly differentiates itself from the two nearest siblings, unassign_number_from_subaccount and 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?

Names the exact undo (unassign_number_from_subaccount), the lookup tool for the required Auth ID (list_sub_accounts), and the alternative for a different intent (release_phone_number to give up the number entirely). This is explicit when-to-use / when-to-use-alternative guidance.

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