get_orderbook

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does surface the conceptual outputs per mode (e.g., spread, buy/sell pressure, liquidity zones, wall-zone estimation), which adds real information. But it omits practical concerns such as response shape, formatting, ordering of bids/asks, or any rate/limits context.

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?

The description is compact: one purpose sentence followed by a tight mode breakdown, with the primary purpose front-loaded. The colon-separated mode list is scannable and uses no filler. It could be slightly clearer about parameter semantics but earns a high conciseness score for efficient structure.

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?

With 6 parameters, 0% schema coverage, and no output schema, the description must carry heavy weight. The mode explanations help materially, but gaps remain: no indication of the return format/fields, no clarification of pair domain, and no guidance distinguishing ranges from bandsPct. Adequate but not complete for a multi-mode tool.

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 coverage is 0%, so the description must compensate. It partially does: 上位N層 maps to topN, 帯域別/買い・売り圧力 maps to ranges/bandsPct, 流動性ゾーン maps to priceZones, and the mode enum is meaningfully expanded. However, the pair parameter is entirely undescribed, and the semantic difference between ranges and bandsPct is left ambiguous despite both being 'range' arrays.

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?

The description clearly identifies this as the integrated tool for order book/depth/bid-ask spread data (板情報), distinguishing it from siblings like get_ticker, get_candles, and the various analyze_* tools. The specific verb-resource pairing is unambiguous, and the four named modes (summary/pressure/statistics/raw) further pin down what it does.

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 description explains what each mode computes (top N + spread, pressure by band, liquidity zones + large orders, raw bids/asks + wall zones), which guides mode selection. However, it gives no explicit guidance on when to choose this tool over alternatives such as get_ticker, get_flow_metrics, or the analyze_* siblings, and no stated exclusions.

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