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

With annotations already declaring readOnlyHint and idempotentHint, the description adds context about the pre-registered threshold and the fact that detection rules were declared before episodes accrued. This methodological transparency goes beyond the annotations, though it doesn't detail edge cases or output format.

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 four sentences, each earning its place: it defines the content, notes the methodological assurance, gives usage guidance, and adds a scope caveat. It's front-loaded and free of fluff.

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 zero-parameter tool with no output schema, the description sufficiently explains what the tool returns and when to use it. However, it omits details like the time range covered or number of episodes, leaving some ambiguity about the dataset's extent.

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?

The tool has zero parameters, so the description needn't add parameter details. The schema is empty, and the description focuses on the output and use case, which is entirely appropriate for a parameterless tool. Baseline 4 is justified.

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 states the tool's function: reporting realized depth-collapse episodes in BTC ±1% aggregate depth with specific metrics (onset, trough, drawdown fraction, recovery time). It distinguishes itself from current-state tools like liquidity_tiers by focusing on historical, threshold-crossing episodes, making the purpose unambiguous.

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 explicitly provides a usage criterion: 'Use when asked whether crypto liquidity has actually broken lately, as opposed to how it looks right now.' It also contrasts with current-liquidity tools and notes that `exit_desk_full` covers ETH, guiding users away from this tool when ETH is the focus.

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