binance_get_system_status

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

The description adds substantial behavioral context beyond annotations: it states that no key or signature is needed, reports the IP weight, explains the error semantics ('a failure here means Binance itself is unreachable, not a key or signature problem'), and documents the return values. The readOnly and idempotent hints are consistent and reinforced.

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 well-structured with clear sections, front-loaded purpose, and no wasted sentences. The endpoint, authentication requirement, usage guidance, return values, example, and error handling all earn their place.

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 status-check tool, the description covers everything an agent needs: what to use it for, what not to use it for, authentication, return shape, and failure interpretation. The output schema covers the response_format parameter, so no essential context is missing.

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?

Even with only one parameter and a clear schema description, the tool description clarifies that the endpoint takes no real params, explains the response_format behavior ('raw JSON with response_format="json"'), and gives an example of an empty params object. This meaningfully supplements the schema, though the schema already covers the enum details.

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 leads with a specific verb and resource: 'Report whether the Binance system is up or under maintenance.' It also names the exact endpoint, and the 'When NOT to Use' section explicitly differentiates this from binance_health_check, so an agent can distinguish it from siblings.

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 provides explicit 'When to Use' and 'When NOT to Use' sections, including the concrete alternative binance_health_check for checking key connectivity. This leaves no ambiguity about the tool's appropriate context.

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