Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get sub-account

get_sub_account
Read-only

Retrieve one Vobiz sub-account's full settings by SA_ Auth ID, including contact info, enabled state, KYC mode, rate limit, permissions, and timestamps with credentials removed.

Instructions

Return one Vobiz sub-account's full record by Auth ID: name, contact email and phone, description, enabled state, KYC mode, rate limit, permissions and timestamps, with credentials removed. Use it when you already have a sub_auth_id and need its settings; to find Auth IDs use list_sub_accounts, and for the sub-account's KYC verification state use get_sub_account_kyc_status instead. An Auth ID that is not a sub-account of this main account fails with not_found. Needs main-account (MA_) credentials.

Input Schema

NameRequiredDescriptionDefault
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.
sub_accountNoThe sub-account as Vobiz returns it: name, auth_id, email, phone, enabled, kyc_mode, rate_limit, permissions and timestamps. Credentials are removed.
credentials_noteNoReminder that credentials are never returned here and where the user finds them.

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": {
+    "credentials_note": {
+      "description": "Reminder that credentials are never returned here and where the user finds them.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "true on success; false (with error and message) when the tool failed.",
+      "type": "boolean"
+    },
+    "sub_account": {
+      "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": "object"
+}
  2. First observedv1.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the read-only and open-world profile, and the description adds substantive context on top: credentials are stripped from the response, only MA_ main-account credentials are accepted, and a foreign Auth ID yields not_found. It stops short of noting pagination or rate limits, but for a single-record read that gap is minor.

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?

The purpose and lookup key come first, then usage routing, then the failure/auth caveats – good front-loading. The field enumeration is long but informative rather than filler; the only slight cost is sentence density.

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 one-parameter read with an output schema, the description covers everything an agent needs: what is returned, that credentials are excluded, which credentials are required, which sibling to use instead, and the not_found edge case. 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 coverage is 100% and the single parameter's pattern (^SA_[A-Za-z0-9]+$) and provenance (from list_sub_accounts) are fully documented in the schema itself. The description reinforces the Auth ID key and the not_found failure mode for wrong IDs, but adds no syntax or format detail beyond the schema. 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?

States a specific verb (Return), resource (one Vobiz sub-account's full record), and lookup key (by Auth ID), then enumerates the returned fields. An agent can immediately distinguish this from get_account_details, list_sub_accounts, and get_sub_account_kyc_status.

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?

Explicitly gives the precondition ('when you already have a sub_auth_id and need its settings') and names both alternatives with their selecting conditions: list_sub_accounts to find Auth IDs, get_sub_account_kyc_status for KYC verification state. It even states the negative case (non-sub-account ID fails with not_found).

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