Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Update sub-account

update_sub_account
DestructiveIdempotent

Update an existing Vobiz sub-account's name, contact details, description, rate limit, permissions, enabled flag, or KYC mode. Only provided fields change; others remain unchanged.

Instructions

Change an existing Vobiz sub-account's name, contact details, description, rate limit, permissions, enabled flag or kyc_mode. Only the fields you pass change; omitted fields keep their values, and a call with no fields fails with invalid_input. Moving to customer_use needs an email on the sub-account and can pause its calls until its KYC is verified. Returns the updated record with credentials removed. To make a new sub-account use create_sub_account; to remove one use delete_sub_account. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true; needs main-account (MA_) credentials.

Input Schema

NameRequiredDescriptionDefault
nameNoHuman-readable name for the sub-account.
emailNoContact email. Required for kyc_mode customer_use.
phoneNoContact phone number for the sub-account's owner: digits with an optional leading + and spaces, dashes or brackets, 6 to 20 characters. Not a caller ID.
confirmYesMust be true, set only after the user explicitly approved: changing this sub-account.
enabledNoWhether the sub-account can be used (default true).
kyc_modeNopersonal_use (default) uses the parent's KYC; customer_use means the sub-account completes its own KYC before placing calls (needs email).
rate_limitNoAPI rate limit for the sub-account (Vobiz default 1000).
descriptionNoFree-text note about the sub-account (what or whom it is for), up to 1000 characters.
permissionsNoAccess flags. Omitted on create: the sub-account inherits the parent's default access.
sub_auth_idYesThe sub-account's Auth ID (SA_...), from list_sub_accounts.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
updatedNotrue once Vobiz applied the change.
http_statusNoHTTP status Vobiz answered with.
sub_accountNo
sub_auth_idNoThe sub-account that was changed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.2
    • addedInput schema / properties / description / description
      Added value: +"Free-text note about the sub-account (what or whom it is for), up to 1000 characters."
    • addedInput schema / properties / phone / description
      Added value: +"Contact phone number for the sub-account's owner: digits with an optional leading + and spaces, dashes or brackets, 6 to 20 characters. Not a caller ID."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "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"
+    },
+    "sub_account": {
+      "anyOf": [
+        {
+          "additionalProperties": {},
+          "description": "The sub-account as Vobiz returns it: name, auth_id, email, phone, enabled, kyc_mode, rate_limit, permissions and timestamps. Credentials are removed.",
+          "propertyNames": {
+            "type": "string"
+          },
+          "type": "object"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "sub_auth_id": {
+      "description": "The sub-account that was changed.",
+      "type": "string"
+    },
+    "updated": {
+      "description": "true once Vobiz applied the change.",
+      "type": "boolean"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint true and idempotentHint true, but the description adds real value beyond them: partial-update semantics (omitted fields keep values, an empty call fails with invalid_input), the KYC-verification side effect that can pause calls, credential stripping in the response, and the feature-flag/auth gating. This is unusually rich behavioral disclosure.

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 the mutation scope, then conditions, then alternatives. Every clause carries a distinct fact (partial update, failure mode, side effect, return shape, routing, gating) 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 10-parameter mutation tool with nested objects, an output schema, and destructive annotations, the description covers the gaps that matter: partial-update contract, environment gating, explicit confirmation, side effects, and sibling routing.

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 earns an extra point for cross-parameter logic the schema cannot express — that moving to customer_use requires an email on the sub-account and that a no-field call fails. Most individual field meaning is still left to the schema.

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 (Change) and resource (existing Vobiz sub-account) and enumerates the mutable field groups. It also explicitly disambiguates from create_sub_account and delete_sub_account, so an agent can place it precisely among its siblings.

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 alternatives and the condition selecting each: create_sub_account for new records, delete_sub_account for removal. It also states prerequisites (VOBIZ_ENABLE_PROVISIONING, confirm: true, MA_ credentials) and the customer_use precondition, leaving nothing to inference.

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