Skip to main content
Glama
bybit-exchange

Bybit MCP Server

Official

queryFundingDetailApi

Read-only

Retrieve funding account transaction records with optional time range and cursor pagination. Use to review funding history within a 7-day window.

Instructions

Query transaction records of the funding account.

  • createTimeFrom and createTimeTo must be used together; the interval cannot exceed 7 days

  • If neither createTimeFrom nor createTimeTo is provided, defaults to the last 7 days

  • Supports cursor-based pagination; pass nextPageCursor from the previous response as cursor

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
cursorNo
createTimeToNo
createTimeFromNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.11

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds meaningful behavioral context: the 7-day interval constraint, the default time window, and cursor-based pagination using nextPageCursor. This goes beyond the annotations without contradicting them, though it omits details like response shape or rate limits.

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?

The description is concise and front-loaded with the core purpose, followed by three high-value bullet points. Every sentence adds necessary information and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the essential query behavior and pagination mechanism, but with no output schema and four optional parameters, the omission of limit semantics and any description of the returned fields leaves some uncertainty. It is adequate for a simple query but not fully complete.

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?

With 0% schema description coverage, the description carries the burden of explaining parameters. It explains createTimeFrom/createTimeTo pairing, the 7-day limit, default behavior, and cursor semantics. However, it does not describe the 'limit' parameter at all, nor does it specify timestamp formats or cursor lifecycle details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action and resource: 'Query transaction records of the funding account.' This is specific and maps well to the tool name. However, it does not explicitly differentiate the tool from similar siblings such as getTransactionLog or getWalletBalance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides useful operational guidance: createTimeFrom/createTimeTo must be paired, cannot exceed 7 days, and default to the last 7 days when omitted. However, it does not state when to prefer this tool over alternatives or when not to use it; usage is only implied by the query intent.

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