Skip to main content
Glama
C0inFlips

binance-mcp-chainvector

by C0inFlips

BinanceWalletQueryUserUniversalTransferHistory

Retrieve Binance universal transfer history by type, date range, and pagination to track asset movements across accounts.

Instructions

Query universal transfer history.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sizeNoPage size
typeYesTransfer type
currentNoCurrent page
endTimeNoEnd time in milliseconds
toSymbolNoSymbol for spot/margin trade pair
startTimeNoStart time in milliseconds
fromSymbolNoSymbol for spot/margin trade pair
recvWindowNoThe value cannot be greater than 60000
Behavior1/5

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

No annotations are provided, so the description carries the full burden for behavioral transparency. It only says 'Query universal transfer history,' offering no details on read-only behavior, pagination, required parameters, time range handling, or response characteristics. It adds no behavioral traits beyond what the tool name implies.

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 a single short sentence that is front-loaded with the verb and object. It contains no fluff, but is a bit too terse; still, for conciseness, it is efficiently minimal.

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

Completeness2/5

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

This is an 8-parameter tool with a required 'type' field, no output schema, and no annotations. The description is just a short phrase, giving no context for parameter interactions, required conditions, or expected results. It is far from complete for a tool with this complexity.

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?

The input schema descriptions cover all 8 parameters (100% coverage), so the baseline is 3. The description itself adds no parameter information, but the schema already documents each parameter, including type requirements and time units, so no major gap exists.

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 tool queries universal transfer history, using a specific verb and resource. It does not explicitly differentiate from sibling tools like deposit/withdraw history queries or the transfer creation tool, but the name and description together make the purpose clear.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives. The description does not mention the required 'type' parameter, pagination, time filtering, or any context for choosing this over other wallet history tools. The task provides no usage context at all.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/C0inFlips/binance-mcp-chainvector'

If you have feedback or need assistance with the MCP directory API, please join our Discord server