binance_exchange_info

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns about real-time updates, strict precision requirements, order size limits, API rate limits, and system maintenance periods. It also provides a detailed output example showing server time, system status, trading pair details, and API limits, which gives the agent a strong expectation of the data returned.

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 long but well-structured with clear sections (功能说明, 重要提醒, 适用场景, 输出示例) and uses bullet points and emojis for readability. It is front-loaded with the core purpose. The detailed output example is somewhat verbose but serves to set expectations for the return format, which is valuable given there is no output schema. Each section earns its place, though trimming the example could improve conciseness.

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?

This is a relatively simple read-only info tool with one optional parameter and no output schema. The description fully compensates by providing a comprehensive output example covering exchange base info, trading pair details, trading restrictions, other rules, API limits, and important notes. It also addresses key operational concerns like real-time updates and rate limits, making it complete for an agent to understand and invoke the tool 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?

The input schema already has 100% coverage of the single parameter 'market', including an enum and a description explaining the difference between spot and futures. The description itself does not add further parameter-level detail, so the baseline score of 3 is appropriate. The output example implicitly illustrates spot market information, but this is not tied directly to the parameter semantics.

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: querying Binance exchange information and trading rules, including supported trading pairs, minimum order sizes, price/quantity precision, fee rules, and API limits. It is explicitly positioned as a foundational reference for programmatic trading and risk control, and the focus on exchange-wide rules clearly distinguishes it from sibling tools like account balances, orders, and market data.

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 a dedicated '适用场景' (applicable scenarios) section listing four specific use cases: programmatic trading systems, risk control verification, learning new trading pair restrictions, and compliance confirmation. This gives clear context for when to use the tool, though it does not explicitly mention alternatives or exclude scenarios that are better served by sibling tools.

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