Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Delete sub-account

delete_sub_account
DestructiveIdempotent

Permanently deletes a Vobiz sub-account and revokes its credentials, disabling anything that uses its Auth ID. This action cannot be undone; use deactivation instead to keep the sub-account.

Instructions

Permanently delete a Vobiz sub-account and revoke its credentials. This removes the sub-account and cannot be undone: anything using its Auth ID stops working. To take a sub-account out of use while keeping it, use update_sub_account with enabled: false instead. Gated by VOBIZ_ENABLE_PROVISIONING and confirm: true; needs main-account (MA_) credentials.

Input Schema

NameRequiredDescriptionDefault
confirmYesMust be true, set only after the user explicitly approved: permanently deleting this sub-account and revoking its credentials.
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.
deletedNotrue once Vobiz removed the sub-account.
http_statusNoHTTP status Vobiz answered with.
sub_auth_idNoThe Auth ID that was deleted.
backend_messageNoMessage from Vobiz about the operation, or null.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.2
    • 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.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "deleted": {
+      "description": "true once Vobiz removed the sub-account.",
+      "type": "boolean"
+    },
+    "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_auth_id": {
+      "description": "The Auth ID that was deleted.",
+      "type": "string"
+    }
+  },
+  "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 flag destructiveHint=true, but the description goes further by spelling out what is actually destroyed ('anything using its Auth ID stops working') and that the action cannot be undone. It additionally discloses two operational gates (environment flag and explicit confirm) that annotations do not convey.

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?

Three sentences, front-loaded with the destructive action and its irreversibility, then routing to the alternative, then prerequisites. No sentence is filler and each carries distinct 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?

An output schema exists, so return values need no explanation, and the description covers the safety profile, the alternative route, and the auth/gating prerequisites for a two-parameter destructive tool. Nothing an agent needs to decide or execute the call correctly 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 both parameters are already fully documented in the schema, including the SA_ pattern and the confirm semantics. The description reiterates the confirm/credential requirements but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

The description states a specific verb and resource ('Permanently delete a Vobiz sub-account') plus the consequential side effect ('revoke its credentials'). It clearly distinguishes itself from the sibling mutation update_sub_account, which is named explicitly.

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?

It names the non-destructive alternative and the exact condition that selects it ('To take a sub-account out of use while keeping it, use update_sub_account with enabled: false instead'). It also states the preconditions for use: the VOBIZ_ENABLE_PROVISIONING gate, confirm: true, and MA_ credentials.

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