order_renew_ipv6Renews static residential IPv6 sub-accounts grouped by country, with duration options from 30 to 360 days, billing directly to account balance.
会从账户余额扣费。续费静态住宅 IPv6 时长 IP 子账号，content 按国家分组，每组写子账号 id 列表、国家、续费时长；IPv6 续费不支持优惠券。
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | 续费内容，按国家分组，每组写 ids、country、timelen | |
| confirm_token | No | 确认码。客户端不支持弹窗确认时，第一次调用只返回操作预览和确认码；把预览告诉用户并得到同意后，用相同参数带上确认码再调一次。支持弹窗确认的客户端不需要这个参数 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that '会从账户余额扣费' (will deduct from account balance), adding meaningful behavioral context beyond the annotations' destructiveHint. It also states the coupon restriction. It does not detail side effects beyond charging, but the most important consequence is disclosed.
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 front-loaded with the most critical information (account balance deduction). Every sentence earns its place: action, grouping structure, and coupon restriction are all covered without redundancy.
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 complete schema documentation for both parameters, including the confirm_token two-step flow, the description is adequate for calling the tool. It lacks an example or return-format note, but the absence of an output schema and the rich parameter descriptions make this a minor gap.
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 the structured fields already explain ids, country, and timelen thoroughly. The description adds the grouping rule 'content 按国家分组' but mostly reinforces what the schema already provides.
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 and resource: '续费静态住宅 IPv6 时长 IP 子账号' (renew static residential IPv6 duration IP sub-accounts). It also clearly distinguishes this from the sibling order_renew by explicitly referencing IPv6 and noting that coupons are not supported.
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 context is clear: use this tool when renewing IPv6 sub-accounts by country groups, and the note '不支持优惠券' is an explicit constraint. However, the description does not explicitly mention when not to use it or compare it to alternatives such as order_renew or order_buy_ipv6.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.