Skip to main content
Glama
vobiz-ai

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get sub-account KYC status

get_sub_account_kyc_status
Read-only

Retrieve a Vobiz sub-account's aggregated KYC status, including document checks and call-pause state, to track progress or explain blocked calls.

Instructions

Return a Vobiz sub-account's aggregated KYC state: overall status, per-document status (PAN, GST, CIN, Aadhaar), business type and whether calls are paused pending KYC. Use it to track progress after create_sub_account_kyc_session or to explain why a customer_use sub-account cannot place calls; for the sub-account's settings and contact details use get_sub_account instead. Makes one request and changes nothing; 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.
kycNoAggregated KYC record from Vobiz: overall status, per-document statuses, business_type and the calls-paused flag.

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": {
+    "kyc": {
+      "additionalProperties": {},
+      "description": "Aggregated KYC record from Vobiz: overall status, per-document statuses, business_type and the calls-paused flag.",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "ok": {
+      "description": "true on success; false (with error and message) when the tool failed.",
+      "type": "boolean"
+    }
+  },
+  "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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is partially covered. The description augments this with 'Makes one request and changes nothing' and the non-obvious operational constraint that main-account (MA_) credentials are required. It stops short of rate-limit or pagination notes, but for a single-request read this is solid.

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?

Front-loaded with the return shape, then usage, then the sibling exclusion and auth constraint in a compact sequence. It is dense but nearly every clause carries information; the enumeration of per-document types is slightly list-heavy but justified.

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 needn't be re-explained, yet the description still orients the agent on the aggregate shape. With the auth requirement, single-request/no-mutation note, and sibling routing all present, 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.

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 already documents its SA_ pattern and its source (list_sub_accounts). The description 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?

States a specific verb (Return) and resource (Vobiz sub-account's aggregated KYC state), then enumerates exactly what is returned: overall status, per-document status (PAN, GST, CIN, Aadhaar), business type, and calls-paused flag. It explicitly contrasts with the sibling get_sub_account, making selection unambiguous.

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 concrete when-to-use conditions: track progress after create_sub_account_kyc_session, or explain why a customer_use sub-account cannot place calls. It also names the alternative (get_sub_account) for settings/contact details, so both positive and negative routing are covered.

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