get_orderbook

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

With no annotations present, the description carries the full burden and does well: it discloses credential-driven adapter routing, the keyless public fallback, read-only behavior, and a venue-specific limitation (Hyperliquid native perps only, HIP-3 dexes via the CLI --dex flag). It does not mention rate limits or the structure of what comes back, but the failure-mode disclosure is unusually strong for a read tool.

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?

One dense front-loaded sentence states the core purpose first, then appends routing and venue caveats as clauses. Nothing is filler, though the trailing Hyperliquid/--dex note is cryptic and packed into the same sentence.

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 multi-exchange tool with no annotations and no output schema, the description covers routing and availability risks well, but it never characterizes the returned book (level structure, depth, price/size format). The agent knows whether the call will work but not what it gets back.

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%, so both parameters are already documented in the schema (symbol examples, exchange name list). The description adds only venue-specific semantics around exchange, not syntax or format beyond the schema. Baseline 3 applies.

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 states a specific verb and resource — retrieve the bids-and-asks order book for a given symbol/exchange — which is unambiguous on its own. It does not explicitly contrast itself with near siblings like get_prices, get_outcome_book, or get_option_chain, so an agent must infer the differentiation from the exchange/symbol scope.

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?

It gives real usage context: works keyless on any venue with an account API, routes to the account adapter when credentials exist, and returns nothing on market-data-only venues. That is a clear when-it-works/when-it-fails statement. It stops short of naming an alternative tool for the cases it cannot serve.

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