Skip to main content
Glama

A股数据 API (A-Share Data API)

ashare_orderbook

五档盘口:买一买五 / 卖一卖五的价格与挂单量(手) + 现价/涨跌/数据时间。用户问'封单多少/买盘卖盘/盘口/挂单/支撑压力位/有没有大单托着'用这个。字段:b1_p/b1_vb5_p/b5_v 买档价格/量 · a1_p/a1_va5_p/a5_v 卖档。⚠️ 本工具是秒级快照(每 10 秒刷新),盘中才有意义(收盘后为当日最后快照)——要实时成交价用 ashare_quote(免费,字段少更轻)。⚠️ 量单位是手(×100 = 股);跌停买档全 0 / 涨停卖档全 0(正常)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYes股票代码:sh600667 / sz000001

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses refresh cadence (每 10 秒刷新), timing semantics (盘中才有意义, 收盘后为当日最后快照), the volume unit (手, ×100 = 股), and limit-up/limit-down edge cases (跌停买档全 0 / 涨停卖档全 0). It stops short of auth/permission or failure behavior, but the disclosed operational traits are substantial.

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 core purpose and routing are front-loaded, and the warning symbols make the caveats scannable. It is somewhat dense with field enumeration that overlaps the output schema, but every element (unit, timing, edge cases) earns its place.

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 a present output schema, the description needn't explain return values yet it covers the non-obvious ones anyway, and it fully covers timing, units, edge cases, and the sibling alternative. Nothing an agent needs to invoke 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?

There is one parameter (code) with 100% schema description coverage, including the format example sh600667/sz000001, so the schema already does the heavy lifting. The description's field listing (b1_p/b1_v etc.) describes outputs, not the input parameter, so it adds nothing to input semantics. Baseline 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 names a specific resource (五档盘口) and enumerates exactly what it returns: buy1–buy5/sell1–sell5 price and volume plus current price/change/data time. It also explicitly distinguishes itself from the sibling ashare_quote, so an agent can tell them apart without opening either schema.

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?

It gives explicit user-intent triggers ('封单多少/买盘卖盘/盘口/挂单/支撑压力位/有没有大单托着') and names the alternative for a different need (实时成交价用 ashare_quote), including why (免费,字段少更轻). This is a clear when-to-use / when-to-use-something-else routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources