Skip to main content
Glama
kydlikebtc

binance-mcp-server

by kydlikebtc

binance_spot_order_history

Retrieve spot market historical orders by symbol, time range, and limit. Get order status, execution details, and pagination for analysis.

Instructions

【现货历史订单】查询现货市场的历史订单记录

📋 功能说明

  • 查询所有历史订单:已成交、已取消、被拒绝、已过期

  • 支持时间范围筛选(最大24小时)

  • 支持分页查询和数量限制

  • 包含订单详细状态和成交信息

⚠️ 重要提醒

  • 每次查询只能指定一个交易对

  • 时间范围不能超过24小时

  • 默认按时间倒序返回(最新的在前)

  • 数据量大时建议使用limit参数限制

🎯 适用场景

  • 查看历史交易记录和成交情况

  • 分析订单执行效果和策略表现

  • 核对账户交易明细

  • 导出交易数据进行分析

📊 输出示例 查询成功后将返回:

📈 现货历史订单查询结果

📊 查询概况
查询期间:2022-01-01 至 2022-01-02 (24小时)
交易对:BTCUSDT (BTC/USDT现货)
找到订单:5 个历史记录

📈 执行统计
✅ 成交订单:3 个 (60%)
❌ 撤销订单:2 个 (40%)
📊 整体成功率:60%

📋 订单详情

✅ 订单 #12345678 [已完成]
交易方向:买入 (做多)
订单类型:限价单
委托数量:0.001 BTC
委托价格:45,000 USDT
实际成交:0.001 BTC (100%)
成交金额:45 USDT
下单时间:2022-01-01 08:00:00
完成时间:2022-01-01 08:05:30
执行时长:5分30秒

❌ 订单 #12345679 [已撤销]
交易方向:卖出 (做空)
订单类型:限价单
委托数量:0.001 BTC
委托价格:46,000 USDT
撤销原因:用户主动撤销
下单时间:2022-01-01 09:00:00
撤销时间:2022-01-01 10:30:00

💡 交易总结
本期间交易较为活跃,成交率适中。
建议关注市场波动,优化委托价格策略。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo返回订单数量限制(可选,默认500) • 取值范围:1-1000 • 默认值:500 • 较小值响应更快 • 较大值减少分页次数 💡 数量选择: - 快速查询:使用100-200 - 批量获取:使用500-1000 - 网络较慢时建议使用小值
symbolYes交易对符号(必填) • 每次查询只能指定一个交易对 • 格式:基础资产+计价资产,如BTCUSDT、ETHUSDT • 区分大小写,必须完全匹配 • 可通过binance_exchange_info查看支持的交易对 💡 查询技巧: - 优先查询近期活跃的交易对 - 不同交易对需要分别查询
endTimeNo查询结束时间(可选,13位毫秒时间戳) • 必须大于startTime • 与startTime的差值不能超过24小时 • 格式:1640995200000 • 建议设置为当前时间 💡 注意事项: - endTime - startTime ≤ 24小时 - 建议留出时间缓冲,避免刚好24小时
orderIdNo起始订单ID(可选,用于分页) • 返回该订单ID及之后的订单 • 用于分页查询大量历史数据 • 可从之前查询结果的最后一个订单获取 • 与时间参数可以组合使用 💡 分页使用: - 首次查询不填写,获取最新订单 - 后续查询使用上次结果的最小orderId
startTimeNo查询开始时间(可选,13位毫秒时间戳) • 格式:1640995200000(对应2022-01-01 00:00:00 UTC) • 必须与endTime配合使用 • 查询范围最大24小时 • 不填写默认查询最近的订单 💡 时间设置: - 使用 Date.now() 获取当前时间戳 - 建议查询最近几小时的数据
Behavior5/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses key behaviors: each query is limited to one symbol, time range cannot exceed 24 hours, results are sorted descending by default, and the limit parameter is recommended for large datasets. The provided output example also illustrates the response structure and content, giving agents a clear picture of what to expect.

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 well-structured with clear sections and front-loaded purpose and reminders. The output example is extensive but justified since there is no output schema, yet it makes the description longer than strictly necessary. Overall it is organized and readable, but slightly verbose.

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?

Given that there is no output schema, the description compensates with a detailed output example showing query summary, execution stats, and per-order details. Combined with the thorough schema, all parameters and behavioral constraints are adequately covered. The description also includes practical tips for pagination and time-range usage, making it complete for an agent to invoke the tool correctly.

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 description coverage is 100%, and each parameter already has detailed explanations with examples and tips. The main description adds general reminders (e.g., single symbol, 24-hour limit) and an output example, but it does not significantly enhance the parameter-level semantics beyond what the schema already provides. Thus the baseline score of 3 is appropriate.

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 clear verb and resource: '查询现货市场的历史订单记录' (query spot market historical order records). It explicitly lists the order states covered (filled, canceled, rejected, expired) and distinguishes itself from sibling tools like binance_spot_trade_history by focusing on order records rather than trade records.

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

Usage Guidelines4/5

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

The description provides a '🎯 适用场景' (applicable scenarios) section listing concrete use cases such as viewing historical records, analyzing execution, and verifying account details. It also gives '⚠️ 重要提醒' (critical reminders) with constraints like single trading pair and 24-hour limit. However, it does not explicitly mention alternatives or exclusion scenarios, so it stops short of a 5.

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/kydlikebtc/binance-mcp-server'

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