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

Annotations indicate readOnlyHint=true and openWorldHint=true, so safety profile is already covered. The description goes beyond by detailing the two-fetch latency penalty, the exact wall definition (consistent with the wall_tracking cron), and the spoofing detection logic (wall disappears/shrinks >70% without price crossing). It also explains the summary/full output modes. This is valuable behavioral context not present in annotations or schema.

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 yet information-dense, front-loading the core action and then adding essential caveats. It avoids redundancy with the schema. The warning about latency is placed at the end, which is appropriate since it's a secondary concern. It could be slightly more structured (e.g., breaking into paragraphs), but it is effective.

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 tool with no output schema, the description gives a useful preview of return types (summary: derived metrics + ≤10 points; full: raw arrays) and references a documentation file for deeper details. It also clarifies the symbol requirement (perpetual futures) and the internal dependency. Missing details on exact metrics names or error handling are minor given the reference to docs. Overall, it is sufficient for an agent to call it correctly.

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 four parameters (symbol, limit, detail, delayMs) are already documented with types, defaults, and ranges. The description adds no substantive parameter semantics beyond what the schema provides—it only references the summary/full distinction already in the 'detail' enum. With high coverage, the baseline of 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 clearly states the tool's core function: it takes two orderbook snapshots ~1-2 seconds apart, compares walls (qty >= 2x median), and flags vanishing walls as a real spoofing indicator. It explicitly distinguishes itself from binance_get_order_book_depth (single snapshot) and names the tool it serves internally (binance_detect_mm_activity). The verb 'ambil... bandingkan' and the resource 'orderbook delta' are specific.

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 provides usage context: mentions it is used internally by another tool, notes the difference from the single-snapshot depth tool, and warns about added latency (~1-2s). However, it does not explicitly state when to use this over other orderbook analysis siblings like binance_get_orderbook_wall_persistence or binance_get_order_book_imbalance, leaving some ambiguity for an agent picking the best tool.

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