queryCoinChainInfo

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond those annotations: the meaning of `chainDeposit`/`chainWithdraw` values (`"0"` and `"1"`), the interpretation of `remainAmount`, default behavior when `coin` is absent, and compliance whitelist filtering. No contradiction with annotations.

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 and well-structured: a lead sentence followed by focused bullet points. Every bullet conveys non-obvious, decision-relevant information (wildcard behavior, status encoding, max withdrawal amount, whitelist filtering) with no fluff or repetition.

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?

Despite having no output schema, the description covers the core return semantics: supported coins, chain list, deposit/withdraw statuses, `remainAmount` meaning, and compliance filtering. It lacks explicit response structure or pagination details, but for this simple query tool and with readOnly/openWorld annotations, the provided information is largely sufficient for correct invocation.

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?

With one optional string parameter and 0% schema description coverage, the description compensates well: it explicitly states that omitting `coin` returns all supported coins, and that each coin lists its supported chains. It does not specify the exact format or allowed values for `coin`, but the schema already provides the string type and the behavioral effect is clear.

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 verb ('Query'), a specific resource ('coin information'), and unique aspects ('chain configuration, deposit and withdrawal status'). The bullet points clearly differentiate it from sibling list-style tools like queryCoinList or CoinListQuery by emphasizing chain-level deposit/withdraw configuration and the optional coin filter behavior.

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 implies when to use this tool (when coin chain configuration or deposit/withdrawal status is needed) and explains the behavior when `coin` is omitted. However, it does not explicitly reference alternatives or state when not to use this tool versus other coin-related query tools, so usage guidance is only implied rather than explicit.

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