Skip to main content
Glama
bybit-exchange

Bybit MCP Server

Official
by bybit-exchange
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

querySubMembers

Read-only

Retrieve all sub-accounts under a master account, including account type, status, account mode, and remarks, in one un-paginated response.

Instructions

Get a complete list of all sub-accounts under the master account. Use master account's API key.

Important notes (from official Bybit V5 documentation):

  • Only master account can call this endpoint

  • Sub-accounts CANNOT use this endpoint

  • Returns ALL sub-accounts in a single response (no pagination)

  • Includes comprehensive account information and UTA status

What information is returned:

  1. ✅ Sub-account UID and username

  2. ✅ Account type (normal, custodial, demo, escrow fund)

  3. ✅ Account status (normal, banned, frozen, deleted)

  4. ✅ Account mode (Classic, UTA 1.0/2.0, UTA Pro, Unified)

  5. ✅ Remark/notes for each sub-account

Supported Sub-account Types: This endpoint returns ALL types of sub-accounts:

  • Normal sub-accounts (type=1, MEMBER_RELATION_TYPE_OWN)

  • Custodial sub-accounts (type=6, MEMBER_RELATION_TYPE_ENTRUST_TRADE)

  • Demo sub-accounts (type=2, MEMBER_RELATION_TYPE_DEMO)

  • Escrow fund sub-accounts (for trading teams)

Process Flow:

  1. Parse metadata from request context to get master account ID

  2. Query normal + demo + trading custodial sub-accounts via ListSubMemberForOpenAPI

    • Queries member_relation table with decrypted login names

    • Includes types: OWN (1), DEMO (2), ENTRUST_TRADE (6)

  3. Query escrow fund sub-accounts for trading teams via GetEscrowFundSubMember

    • Queries escrow_fund_member_relation table

    • Specific for trading team escrow accounts

  4. Merge both lists of sub-accounts

  5. If no sub-accounts found, return empty list

  6. Extract all sub-account IDs for batch queries

  7. Fetch UTA tags (UTA, UNIFIED, UTAPRO, UTAINVERSE) from member_tags table

  8. For each sub-account:

    • Get basic info (UID, username, type, status, remark)

    • Calculate accountMode based on UTA tags

    • Default accountMode = 1 if no tags found

  9. Return complete sub-account list

Account Mode Determination Logic: The account mode is determined by checking member tags in the following priority:

  1. If both UTAPRO=SUCCESS and UTAINVERSE=SUCCESS → UTA 2.0 Pro (6)

  2. If UTAINVERSE=SUCCESS → UTA 2.0 (5)

  3. If UTAPRO=SUCCESS → UTA 1.0 Pro (4)

  4. If UTA=SUCCESS → UTA 1.0 (3)

  5. If UNIFIED=SUCCESS → Unified (7)

  6. Otherwise → Classic/Default (1)

Difference from V5 Query:

  • This endpoint (V3): Returns ALL sub-accounts in single response, no pagination

  • /v5/user/submembers (V5): Uses cursor-based pagination with pageSize limit

Use Cases:

  • Get complete overview of all sub-accounts

  • Check sub-account statuses and configurations

  • Audit UTA upgrade status across all sub-accounts

  • Small to medium-sized sub-account lists (no pagination)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.11

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses master-account-only auth, no-pagination behavior, returned account fields, supported sub-account types, and the full account-mode determination logic. This is substantial behavioral context that annotations alone do not provide.

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 description is front-loaded with a clear purpose and uses well-organized sections, lists, and headers. It is verbose and has some redundancy between supported sub-account types, process-flow steps, and returned information, but the structure makes the detail navigable.

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?

With no output schema, the description compensates thoroughly by documenting the returned information, UTA tag logic, merging process, auth requirements, and differences from the V5 endpoint. An agent has enough context to invoke the tool and interpret its results correctly.

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?

The tool has zero parameters, so the empty schema fully covers parameter semantics and the baseline is 4. The description adds relevant context about using the master account's API key, which is the closest thing to invocation guidance for this parameterless tool.

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 opens with a specific verb and resource: 'Get a complete list of all sub-accounts under the master account.' It also distinguishes itself from the V5 sibling endpoint by explicitly stating this version returns all sub-accounts in a single response without pagination, unlike /v5/user/submembers.

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?

The tool states explicit when-to-use conditions: only the master account can call it, sub-accounts cannot, and it is suited for complete overviews, status checks, and UTA audits. It also contrasts with the V5 cursor-paginated endpoint, implying when an alternative should be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools