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

With no annotations, the description itself discloses key behavior: the operation SPENDS NOTHING, returns a single-use confirm_token with ~5 minute validity, and is a prerequisite for the purchase step. This meaningfully covers side-effect transparency beyond what the schema shows.

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 and front-loaded with the purpose, returns, and safety guarantee. The bilingual Vietnamese repetition adds length without new information, but the core message remains clear and scannable.

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 quote tool with no output schema, the description fully covers what the caller needs: the business step, the result fields, the no-charge behavior, token expiry, required parameters, and the follow-up action. No critical usage 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?

Input schema coverage is 100% and already documents api_key, product_id, and quantity with defaults. The description adds only a restatement that api_key and product_id are required, so it adds limited new semantic value beyond the 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?

Explicitly identifies this as 'STEP 1 of buying' and names the operation as retrieving a price quote before purchase. It lists the returned artifacts (unit price, discount, total, balance, stock, confirm_token) and clearly distinguishes itself from buy_product and other related tools.

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?

Provides an explicit WHEN TO USE rule: always call this first, show the total to the user, get approval, then call buy_product. It also names alternatives for other needs: get_my_balance for balance-only checks and check_order_status for existing orders.

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