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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description then adds genuinely new behavior: the call reads existing evidence rather than sampling live venues, it is scoped to a specific ticket size, and it can return a partial 'Being measured' state with a stated reason. Those partial-result semantics are the kind of detail an agent cannot infer from the schema. It stops short of stating cost, rate limits, or what a Rate Receipt reference implies.

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?

It is a single compact sentence with no filler, which is appropriate. However it leads with versioning/alias metadata that is the least actionable part, and packs jargon ('a Rate Receipt', 'Being measured', 'the evidence read') into one dense clause, making the return-shape harder to parse than necessary.

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 no output schema, the description carries the return-value burden and does so reasonably: it enumerates the three outcome shapes (depth at size, slippage/landing cost with a Rate Receipt, or Being measured with a reason). Combined with fully documented parameters and read-only annotations, an agent has enough to invoke it correctly; gaps are secondary detail such as how many venues are returned or ordering.

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 all six parameters including amount, from/to, pair and access_key are already documented in the schema, and the baseline of 3 applies. The description reinforces that amount is the ticket size the depth verdict is evaluated at and that arguments mirror liquidity_map, but adds no syntax or constraint detail 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?

The description names the resource precisely: per venue type, whether evidence shows depth at the ticket size, plus slippage and landing cost with a Rate Receipt, or a 'Being measured' state with a reason. That is a concrete, checkable purpose rather than a restatement of the name. It does not meaningfully differentiate itself from the sibling liquidity_map, which it explicitly declares itself to be the renamed version of.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no routing against alternatives. 'Same arguments as liquidity_map' tells the agent the two are interchangeable but gives no basis for choosing one over the other, nor any prerequisites (e.g. an access key or corridor setup) required before calling.

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