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

Annotations already declare readOnlyHint=true, and the description is consistent with it (status-change reads). The description adds useful behavioral context beyond annotations: the data originates from a !contractInfo stream buffered in a gateway VPS, and there is a 30-day window buffer that constrains data availability. It does not disclose what happens on empty results or how pagination beyond 'limit' works, though no output schema exists to cover this. No contradiction.

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 — a couple of parenthetical-laden sentences in Indonesian — and front-loads the core purpose. But it packs in technical noise (the VPS gateway buffering detail) alongside the key facts, making it slightly dense. Adequate but not elegant; every sentence earns its place roughly.

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 simple tool (2 optional params, no output schema), the description explains the event types and the source stream, and partially disambiguates from exchangeInfo polling. However, with no output schema present, it does not describe the return shape, does not define what 'bracket changes' or 'jadwal settlement' produce, and does not clarify how the 30-day window affects query behavior. Reasonable but with clear gaps.

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 only 50% — symbol has a description but limit does not, and its semantics (maximum returned events) are implied only by name/default. The tool description itself mentions no parameters and does not compensate for the undocumented limit field. For a parameter-poor tool with partial schema coverage, the description should at least clarify the limit behavior; it adds nothing.

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 function: tracking USDS-M contract status changes from the !contractInfo stream, and enumerates the event types (listing, delisting, settlement schedule, bracket changes). It differentiates itself by naming the alternative mechanism (polling onboardDate in exchangeInfo) and the advantage (faster). It does not explicitly name the closest siblings (e.g. binance_get_quarterly_settlement_price, binance_get_trading_schedule), leaving some differentiation to inference, so not a 5.

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 gives implicit guidance: it is better than polling exchangeInfo for spotting new pairs, and notes 'Event jarang' (events are rare) with a 30-day buffer window, implying this is a sparse-output tool. However, it never explicitly states when to use this tool versus related siblings (settlement price tool, trading schedule tool) or lists when-not-to-use conditions. Guidance is contextual rather than explicit.

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