Get QUAI <-> Qi Conversion Rate

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

Annotations already mark readOnlyHint, and the description reinforces 'read-only and doesn't move anything' while adding behavior beyond the annotation: the rate is current as of the latest block in the zone, it is on-chain, and the reverse direction is quote-only. This is valuable context even though the discussion of QI-to-QUAI support is questionable given the sibling list.

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 front-loaded with the core purpose and each sentence adds substantive context: what is quoted, how to actually convert, and the reverse-direction limitation. It is slightly long, but the extra clauses about the built-in swap and wallet differences 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?

The definition covers the tool's domain, zone/network behavior, read-only nature, and conversion limitations. However, it does not describe the response shape or numeric rate format, and with no output schema that gap matters; it also overlooks the convert_qi_to_quai sibling when discussing QI-to-QUAI support.

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 schema already documents all four parameters with descriptions and enums, so the baseline is 3. The description adds useful meaning by clarifying that amounts are in the source currency's human units and that quai_to_qi is executable via send_transaction while qi_to_quai is quote-only, going beyond the enum values.

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 first sentence clearly names the operation ('Quote a conversion') and identifies the two native ledgers (QUAI and Qi), and the rest scopes it to an on-chain rate at the latest block in a zone. It also distinguishes this from a third-party DEX and from send_transaction, so an agent can tell what this tool is for.

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 useful routing: use send_transaction to actually convert QUAI to Qi, and treat qi_to_quai as quote-only. However, it claims QI-to-QUAI conversion is not supported by this server, even though a sibling tool named convert_qi_to_quai exists; it should mention that sibling as the alternative instead of declaring the operation impossible. That makes the guidance partially misleading.

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