购买 IPv6 时长 IP

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

Annotations already declare destructiveHint=true and readOnlyHint=false, indicating a mutating operation. The description adds valuable behavioral details: it explicitly states the balance deduction and the verification prerequisites. It doesn't contradict annotations and enriches the safety profile with cost and authentication requirements.

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 concise, a single sentence with a semicolon separating key points. It front-loads the critical cost implication and includes prerequisites and a coupon restriction. It avoids redundancy and is easy to parse, though it could benefit from slight structural separation.

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?

Given the tool has 11 parameters and 4 required, the description covers the essential prerequisites and cost but omits the two-step confirmation flow for clients without popup support (though this is detailed in the schema). The lack of an output schema means return values aren't expected. Overall, it's adequate but not exhaustive for a complex purchase operation.

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 100%, so all parameters have detailed descriptions. The description adds little beyond the schema; it mentions num is IP quantity, but the schema already says '需要购买的子账号数量'. No new meaning is provided for parameters. The baseline of 3 applies because the schema fully documents parameters.

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 purpose: purchasing static residential IPv6 time-based IP sub-accounts. It uses a specific verb '购买' (purchase) and resource '静态住宅 IPv6 时长 IP 子账号'. It also distinguishes itself from siblings like order_buy_dynamic and order_buy_time_ip by specifying IPv6 and static residential type, making it unambiguous.

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 clear usage context: it deducts from account balance, requires email/phone verification and real-name verification, and notes that IPv6 purchases don't support coupons. While it doesn't explicitly contrast with alternative purchase tools, the specific scope (IPv6 time-based) makes the appropriate usage evident.

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