Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List sub-accounts

list_sub_accounts
Read-only

Retrieve paginated sub-accounts under a Vobiz main account to find the sub_auth_id other sub-account tools need. Returns names, Auth IDs, status, KYC mode, limits, and permissions, not credentials.

Instructions

List the sub-accounts under this Vobiz main account, one page at a time: name, Auth ID (SA_...), enabled state, KYC mode, rate limit and permissions, never credentials. Use it to find the sub_auth_id the other sub-account tools take; for one sub-account's full record use get_sub_account, and for its KYC progress use get_sub_account_kyc_status. Pagination is stateless: pass page and size on every call and follow pagination.next_page until has_more is false. Needs main-account (MA_) credentials: signed in as a sub-account it fails with forbidden before any request.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_sub_accounts"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number (default 1). Take the next value from pagination.next_page.
sizeNoResults per page, max 100. Defaults to the server's VOBIZ_DEFAULT_PAGE_SIZE (20).
active_onlyNotrue returns only active (enabled) sub-accounts; omitted or false returns disabled ones too.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
countNoNumber of sub-accounts in this page.
paginationNoStateless paging block for the next call.
sub_accountsNoThe sub-accounts in this page.
credentials_noteNoReminder that credentials are never returned here and where the user finds them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.4.2
    • changedInput schema / properties / active_only / description
      Previous value: -"true returns only active sub-accounts."New value: +"true returns only active (enabled) sub-accounts; omitted or false returns disabled ones too."
    • addedInput schema / properties / page / description
      Added value: +"1-based page number (default 1). Take the next value from pagination.next_page."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "count": {
+      "description": "Number of sub-accounts in this page.",
+      "type": "number"
+    },
+    "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"
+    },
+    "pagination": {
+      "additionalProperties": {},
+      "description": "Stateless paging block for the next call.",
+      "properties": {
+        "has_more": {
+          "description": "true when another page exists.",
+          "type": "boolean"
+        },
+        "next_page": {
+          "description": "Page to request next, or null on the last page.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "page": {
+          "description": "Page that was returned (1-based).",
+          "type": "number"
+        },
+        "per_page": {
+          "description": "Page size used for this request.",
+          "type": "number"
+        },
+        "returned": {
+          "description": "Number of items in this page.",
+          "type": "number"
+        },
+        "total": {
+          "description": "Total sub-accounts matching the filter, or null when Vobiz did not report it.",
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "sub_accounts": {
+      "description": "The sub-accounts in this page.",
+      "items": {
+        "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": "array"
+    }
+  },
+  "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 only declare readOnlyHint and openWorldHint; the description adds material context beyond them: pagination is stateless with an explicit follow-until-has_more=false loop, results never include credentials, and the call requires main-account (MA_) credentials and fails with forbidden before any request when signed in as a sub-account. That auth-failure mode and pagination contract are non-obvious and high value.

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 what is listed, then alternatives, then pagination mechanics, then the auth prerequisite. Every clause carries distinct, actionable information with no filler or restatement of the tool name.

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, and the description covers the remaining gaps: credential exclusion, stateless pagination loop, prerequisite main-account credentials, and the failure mode. Nothing an agent needs to call this correctly is missing.

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 the baseline is 3, and the schema already documents page, size and active_only. The description still adds cross-parameter meaning: pass page and size on every call and derive the next page value from pagination.next_page, which the field-level descriptions only imply.

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+resource ('List the sub-accounts under this Vobiz main account') and enumerates the fields returned (name, Auth ID, enabled state, KYC mode, rate limit, permissions). It explicitly excludes credentials and names the sibling tools it is not (get_sub_account, get_sub_account_kyc_status), so an agent can distinguish it without opening schemas.

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?

Gives an explicit use case ('find the sub_auth_id the other sub-account tools take') and routes to alternatives with conditions: get_sub_account for a single full record, get_sub_account_kyc_status for KYC progress. Nothing is left 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