Retrieve current bids and asks with price and size for one market to assess liquidity. Public endpoint; deprecated, use fetch_order_book instead.
Deprecated: use fetch_order_book. Get the current order book (bids/asks with price + size) for one market. Public — no credentials needed.
| Name | Required | Description | Default |
|---|---|---|---|
| market_id | Yes | Market id, e.g. "BTC-USDX-PERP". |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden; it discloses that the endpoint is public with no credentials required and describes the shape of the returned data (bids/asks with price + size), which is valuable given there is no output schema. It stops short of covering rate limits, depth/level caps, or whether the deprecated endpoint still functions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short clauses with the deprecation warning front-loaded ahead of the functional description, which is the right priority order for a deprecated tool. No filler sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter public read tool with a fully covered schema, the description supplies the migration target, the access model, and the return shape. Nothing an agent needs to avoid or correctly call this endpoint is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter is fully documented with an example id, so the schema already does the work. The description only implies the market scope ("for one market") without adding format or validity details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Get the current order book") and specifies both scope ("for one market") and payload ("bids/asks with price + size"). It also explicitly names the sibling that supersedes it, so an agent can discriminate it from `fetch_order_book` 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening clause "Deprecated: use `fetch_order_book`" gives an explicit when-not-to-use and names the correct alternative, which is exactly the routing decision an agent needs. Nothing is left to inference about whether this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.