CoinConvertLimitQuery

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

Annotations already declare readOnlyHint=true, so the description's main contribution is operational context: API Key authentication, the specific ACL permission (RESOURCE_GROUP_EXCHANGE_HISTORY + PERMISSION_READ), and a global rate limit (100/path/s). These are exactly the kind of behavioral traits that help an agent invoke the tool correctly and match the read-only annotation without 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?

One purpose sentence front-loaded, followed by three tightly scoped operational bullets (auth, ACL, rate limit). Every line earns its place, and there is zero filler or repetition of the input schema.

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?

With 5 parameters at 0% schema coverage, no output schema, and two unexplained enum parameters, the description leaves meaningful gaps: the semantics of fromCoinType/toCoinType, valid accountType values, and the response shape are all absent. The operational details are strong, but an agent would still struggle to construct a fully correct request or interpret the result.

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 0%, so the description carries the burden of parameter explanation. It names the coin pair (fromCoin, toCoin) and accountType semantics, but leaves the two enum parameters (fromCoinType, toCoinType) completely unexplained — an agent cannot determine the meaning of '0' versus '1', and no valid values are given for accountType. Partial compensation for a low-coverage schema.

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 precise resource ('single conversion min/max limit'), and scope ('specified coin pair under specified account type'). This clearly differentiates it from sibling tools like ConvertExecute, ConvertHistoryQuery, and QuoteApply, which an agent could otherwise confuse it with.

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 makes the usage context clear: an agent needing conversion limit/range information for a coin pair under an account type would select this tool. However, it does not explicitly name alternatives or state when not to use it, leaving the exclusion logic to inference from the sibling names.

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