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

注释已提供readOnlyHint、idempotentHint等安全属性，但描述额外披露了“后端缓存120秒”这一行为特征，让代理意识到结果可能不是实时且需控制调用频率，这超出了注释提供的信息，增加了透明度。描述没有与注释矛盾。

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?

描述仅一句，长度适中，且将核心功能“查询详情”和关键限制“缓存120秒”都包含在内，没有冗余。虽然缺少结构化分点，但内容精炼，信息密度高，评分4。

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?

工具简单，仅两个参数且均必填，无输出模式，描述已涵盖功能范围、缓存行为，对于代理正确调用已足够。缺少返回格式说明，但鉴于工具简单，这不构成重大缺失，评分4。

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?

输入模式对两个参数（product、subAccount）的描述覆盖率100%，枚举值和子账号含义均已清晰说明。描述文本并未额外补充参数细节，但也没有遗漏，基线3分合适，因为模式已经承担了主要解释工作。

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?

描述明确指出“查询子账号剩余有效期内已购带宽的详情”，动词“查询”和资源“已购带宽”清晰，且限定“子账号剩余有效期”这一范围，与兄弟工具如bandwidth_package_list（套餐列表）和bandwidth_trend（趋势）有明显区别，能帮助代理准确判断功能边界。

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?

描述仅提到“后端缓存 120 秒，不要频繁调用”，这是频率限制而非使用场景指导，没有说明在何种情况下应选用此工具而非其他带宽相关工具。虽然缓存信息暗示了调用时机（不适合频繁查询），但缺少明确的正面使用条件或备选工具指引，因此得分较低。

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the '查询' (query) semantics are consistent with a safe, read-only operation. The description adds the operational note about filling bandwidth_num but does not disclose additional behavior such as pagination, rate limits, or pricing caveats.

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 a single compact sentence that front-loads the core action and resource, then adds the key downstream usage instruction. There is no filler, tautology, or wasted words.

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 simple two-parameter, read-only list tool with no output schema, the description is complete: it explains what is returned (bandwidth packages and prices), the filter criteria (product and country), and how to use the result (bandwidth_num for orders/upgrades). Nothing critical is missing for an agent to call it correctly.

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 parameters product and country are already fully documented in the input schema. The description only alludes to '某静态住宅产品在某国家' and the returned bandwidth value, adding no extra parameter-level meaning beyond what the schema 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 action ('查询') on a specific resource: bandwidth packages and prices for a static residential product in a given country. It also includes the downstream purpose ('下单或升级时把返回的带宽值填到 bandwidth_num'), which clearly distinguishes it from siblings like bandwidth_detail or bandwidth_trend.

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 explicitly tells the agent when the returned value matters: when placing an order or upgrading, put the bandwidth value into bandwidth_num. This gives clear usage context, though it does not explicitly name alternative tools or state when not to use the tool.

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

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

注释已声明readOnlyHint=true、idempotentHint=true等，描述未与注释矛盾，也未添加额外行为（如权限、返回格式）。描述仅解释trend_type参数行为，这属于参数语义而非工具行为，因此符合注释覆盖下的基线水平。

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?

描述为单句，直接点明核心功能，并快速嵌入两种模式及时间约束，无冗余信息，信息密度高且结构清晰。

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?

无输出schema，描述未说明返回内容（如返回趋势数据格式或单位）。对于调用，参数和约束已覆盖，但返回信息缺失可能影响代理对结果的解释，因此完整性不足。

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对参数描述覆盖100%，每个参数均有说明。描述额外添加了'跨度不超过31天'的约束，这是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?

描述明确说明查询子账号带宽趋势，并区分实时（trend_type=1）和历史（trend_type=2）两种模式，动词'查询'+资源清晰。但未与兄弟工具如bandwidth_detail做区分，可能产生混淆，因此不达满分。

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?

描述给出了两种trend_type的使用方式，并明确历史查询需传startTime、endTime且跨度不超过31天，提供了清晰的操作上下文。但未提及何时使用此工具而非其他兄弟工具（如bandwidth_detail），缺乏排除性指导。

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

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

注解已包含readOnlyHint=true、idempotentHint=true和destructiveHint=false，覆盖了安全性和幂等性。描述额外说明动态住宅产品需指定州/省，这属于参数约束而非行为特性。未披露返回格式或错误处理，但注解已提供足够安全背景，故评3分。

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?

描述仅一句话，简洁无冗余，且将关键约束（动态住宅需指定州/省）前置。虽未分条列出，但信息密度高，结构有效。

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?

工具简单且无输出schema，描述已覆盖核心调用要求（产品、国家、动态住宅需州）。虽然未提及返回结构，但查询城市列表的返回内容可自然推断，且参数均有schema说明，整体信息足够。

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描述覆盖率100%，每个参数（product、state_id、country_id等）都有详细说明，包括产品枚举值映射和必填条件。描述没有额外补充参数语义，但也没有冲突，基础分为3分。

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?

描述明确说明“查询某产品某国家下可选的城市”，动词“查询”配合资源“城市”，并给出条件（产品、国家），与兄弟工具country_list（查国家）和state_list（查州）明显区分。目的清晰且具有区分度。

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?

描述指出“动态住宅产品还要指定州或省”，提供了明确的调用条件，但未提及何时不使用此工具或替代方案（如需要州列表时用state_list）。虽然缺少排除性说明，但已给出关键的使用场景约束。

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

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

The annotations already establish read-only, idempotent, and non-destructive behavior. The description adds that the result is product-specific and includes country codes, but does not mention pagination, output shape, or any other runtime behavior; acceptable for a simple list but not rich.

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?

A single compact sentence that is front-loaded with the action and object and contains no filler. It is appropriately sized for a one-parameter read-only query tool.

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 one required parameter fully documented in the schema, read-only/idempotent annotations, and no output schema, the description's statement of what is returned (countries and codes for a product) is sufficient for an agent to invoke the tool correctly.

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 input schema covers 100% of the single parameter with a detailed enum and per-value explanations, so the description needs to add little. It only restates the product dependency ('某产品') and does not add semantic detail 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?

The description states a clear action ('查询' - query) and resource ('某产品可选的国家及编码' - countries and codes available for a product), so an agent knows exactly what the tool does. It does not explicitly contrast itself with sibling tools like state_list or city_list, relying on the resource term and name rather than an explicit differentiation.

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 implies the tool is for retrieving selectable countries for a product from the enumerated product values, but it gives no explicit when-to-use vs alternatives or exclusions. An agent can infer usage from context, but the description does not guide selection among the sibling listing tools.

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

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

Annotations already cover the safe read-only and idempotent nature of the tool. The description adds useful context beyond that: the query is scoped to the current account's available coupons and the returned id is meant to be passed to conpon_id. It does not mention pagination or full response shape, but that is minor given the annotations and low complexity.

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?

Two short sentences carry all the essential information: purpose, scope, usage, and filter dimensions. It is front-loaded and contains no filler.

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 read-only list endpoint with two fully documented enum parameters, the description provides enough to invoke it correctly: what it returns conceptually, how the result is used, and what filtering applies. The only omission is response shape details beyond the id, but the description still names the critical output field.

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% and both parameters have detailed enum descriptions. The description's phrase '按套餐类型与计费模式筛选' largely restates the schema rather than adding new semantic detail; the '不用 product' note is a small clarification but not essential because additionalProperties is false.

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 action (查询/query) against a specific resource (当前账号可用的优惠券), and clarifies that the returned id is used as conpon_id in orders or renewals. This clearly distinguishes it from the order_* sibling tools and avoids tautology.

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?

It explicitly says to use the tool when placing an order or renewing, and notes that filtering is done by package type and billing mode, with no product parameter needed. There are no coupon-related sibling tools to contrast against, so the clear context is sufficient, though no explicit alternative is named.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is covered. The description adds that the operation is paginated, which is useful, but it does not disclose details like response format limitations, data recency, or any product-specific constraints beyond what the schema provides.

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 a single, front-loaded sentence that directly conveys the verb, resource, and scope. Every word contributes meaning, with no filler or 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?

For a read-only paginated query with fully documented parameters and strong annotations, the description is nearly complete. It clearly says the result is a paginated list of purchased flow package records for dynamic residential products. The absence of an output schema is mitigated by the straightforward list semantics, though explicit return-shape details would make it fully complete.

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 schema fully documents page, pagesize, and the product enum. The description adds no parameter-level meaning beyond restating that the resource is a paginated list of purchased records, so the baseline of 3 applies.

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: '分页查询' (paginated query) of '已购买的流量套餐记录' (purchased traffic package records) for '动态住宅产品' (dynamic residential products). This clearly differentiates it from sibling tools like bandwidth_package_list or sub_account_flow by scope and object type.

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 usage context is implied through the product scope and '已购买' qualifier, but the description does not explicitly state when to use this tool versus alternatives such as bandwidth_package_list or main_account_flow. No exclusions or alternative routing are provided.

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

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

Annotations already mark this as non-read-only and non-idempotent, and the description adds genuinely useful behavior beyond that: fulfillment is asynchronous ('管理员审核后补货' — admin reviews before replenishing), and the operation has no financial or account-creation side effects. It does not mention the two-phase confirm_token flow, though that is covered in the schema.

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?

A single Chinese sentence packs the usage condition, the post-submission flow, and the two most important exclusions with zero waste. The trigger condition is front-loaded, which is exactly what an agent needs first to decide whether to call this tool.

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 4-parameter tool with no output schema and no nested objects, the combination of description and fully-documented schema covers purpose, precondition, side-effect boundaries, and even the first-call return behavior via confirm_token. The remaining gap is what happens after admin approval (timeline, notification, or whether the reservation converts to an order), which is not addressed anywhere.

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% — every parameter including product enum values and the confirmation-code mechanism is already documented in the schema. The description adds no parameter-specific meaning, so the baseline of 3 applies; the schema carries the heavy lifting.

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 uses a specific verb (submit a reservation), names the resource (IP), and gives the triggering condition (needed country/region has no stock). It also explicitly scopes what the tool does NOT do ('不扣费、不建子账号'), which cleanly distinguishes it from the order_buy_* and sub_account_* siblings without needing to open any schema.

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 an explicit when-to-use condition: '需要的国家或地区没有库存时' (when the needed country or region has no stock). It implies the when-not-to-use by stating it only registers demand and never charges or creates sub-accounts, which contrasts with the ordering tools, but it never names a specific alternative tool like order_buy_dynamic.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description doesn't need to restate safety. It adds value by mentioning pagination and inventory status, but does not disclose rate limits, default behaviors, or response shape beyond what the schema/annotations already imply.

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 one well-structured sentence that front-loads the primary action and adds the downstream ordering use without redundant restatement of the tool name or title.

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 read-only paginated query tool, the description combined with fully documented parameters and rich annotations is sufficiently complete. The only minor gap is the lack of an exact output shape, but the description already states the result contains IP segments and inventory status.

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 parameter documentation already explains each field. The description adds only the ordering handoff context for ip_str/specifyIps, which is useful but not necessary for understanding the 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?

Description states a specific verb ('分页查询'), a clear resource ('某静态住宅产品的 IP 段及库存状态'), and the context for use ('下单时可把有库存的段填到 ip_str 或 specifyIps'). This clearly differentiates it from sibling list/query tools like city_list or country_list.

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 implies the tool should be used when checking IP segment availability before placing an order, saying stock segments can be passed to ip_str or specifyIps. It gives clear context but does not explicitly state when not to use it or name an alternative tool for ordering/booking.

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

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

Annotations already establish readOnly, idempotent, non-destructive behavior. The word '汇总' adds that the result is a summary rather than detailed records, but the description does not disclose units, time range, or whether the two product options are combined.

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 efficient sentence with no filler; the verb and object are front-loaded. Nothing extraneous is present for such a simple tool.

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 a single required enum parameter, full schema coverage, and read-safe annotations, the description is nearly sufficient. Only the return format and units are unstated, which is a minor gap for a summary query.

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 covers the one parameter fully, including enum values and their meanings. The description adds no parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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 action and resource: query the aggregated traffic of the dynamic-residential main account. This makes it distinguishable from sibling tools such as sub_account_flow or bandwidth_detail, though it does not explicitly name the contrast.

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?

No when-to-use guidance is provided; the sentence only restates the query capability. There are no exclusions or pointers to sibling tools, so an agent must infer usage from the tool name and sibling list.

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

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

The description states '后端还没有时会生成一个' (if the backend doesn't have one, it will generate one), which implies a write/side effect. This directly contradicts the annotation readOnlyHint: true, which declares the operation does not modify state. This is a serious inconsistency that misleads the agent about the tool's behavioral profile.

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 two sentences, front-loaded with the main action ('获取...切换 token') and then explains the purpose and the generation fallback. It is concise without unnecessary words, though it could potentially be streamlined further. The structure is effective for quick comprehension.

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 simple tool with one parameter and no output schema, the description covers the core purpose and the edge case of token generation. However, the contradiction with the readOnlyHint annotation undermines trust and could cause the agent to mispredict side effects. The description is mostly complete but not fully reliable due to the inconsistency.

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 sole parameter 'product' is fully documented in the input schema with an enum and a Chinese description. The tool description adds no additional semantic information about parameters, so it relies entirely on the schema, which already covers 100% of the parameter semantics. This matches the baseline for high schema coverage.

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 a specific verb ('获取' / get) and resource ('动态住宅主账号的切换 token' / dynamic residential main account switch token) along with its purpose ('用于 api 子账号切换时的独立 token 验证' / for independent token verification when switching API sub-accounts). It distinguishes itself from sibling tools focused on sub-account operations, though it doesn't explicitly name an alternative.

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 implies when to use this tool: when a main-account switch token is needed for API sub-account switching. However, it provides no exclusions, no mention of when not to use it, and no reference to alternative tools. The context is clear but not explicit enough to guide an agent to select among siblings.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds a valuable behavioral detail beyond annotations: '后端缓存 5 分钟' (backend caches for 5 minutes), which informs the agent about potential staleness. No contradiction with annotations.

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 a single concise sentence that states the purpose and the key caching behavior. Every word earns its place, and the core action is front-loaded.

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 zero-parameter, read-only query tool, the description is complete: it states what is queried and the caching behavior. Annotations cover the safety profile, and no output schema is required for the agent to invoke the tool correctly.

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 tool has zero parameters, and the schema is empty with 100% coverage, so the baseline is 4. The description adds no parameter details, but none are needed since the tool takes no input.

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 ('各产品的官网标价'), making the tool's purpose immediately clear. It also distinguishes itself from the sibling tool 'user_price' by explicitly scoping to official website prices.

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 implies usage by naming the resource ('官网标价'), but it does not explicitly state when to use this tool versus alternatives like 'user_price'. No when-not-to-use guidance is provided, though the intended context is reasonably inferable.

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

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

Annotations indicate destructiveHint=true (mutating) and readOnlyHint=false, so the description appropriately adds billing details ('will deduct from account balance') and the prerequisite about expired sub-accounts. It also mentions the confirm_token flow in the schema, which is covered there. The description adds value beyond annotations by explaining the billing impact and renewal precondition.

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, front-loaded with the most critical fact (billing), and every sentence adds value. It covers billing, the action, how to find options, and a precondition in just three sentences 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?

Given the tool's complexity (4 params, no output schema, annotations present), the description is quite complete: it covers billing, the upgrade action, package lookup, and a precondition. The only minor omission is explicit information about the return value or preview behavior, but that is partially covered by the confirm_token schema description. Overall, sufficient for correct invocation.

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 coverage is 100%, so the schema already documents each parameter's meaning (product enum, sub_accounts list, bandwidth_num, confirm_token). The description adds minimal extra meaning for bandwidth_num (must be greater than current bandwidth) and mentions the confirm_token process, but most parameter details are in the schema. Baseline 3 is appropriate.

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: upgrading the bandwidth of static residential sub-accounts to a specified value, with explicit mention of billing from account balance. It distinguishes itself from siblings like order_renew and bandwidth_package_list by focusing on the upgrade action and referencing the package list for options.

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 context for when to use this tool: to upgrade bandwidth, and mentions using bandwidth_package_list to check available packages and prices. It also notes a precondition (must renew expired sub-accounts first), but doesn't explicitly mention alternatives for other actions like renewal, which is covered by order_renew.

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

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

The description adds meaningful behavioral context beyond annotations: it tells the agent that the operation will deduct from the account balance, that permanent packages never expire while term packages require bill_timelen, and that account verification is required. These details complement the destructiveHint already provided by annotations.

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 only two sentences, with the most important side effect (balance deduction) front-loaded, followed by essential package rules and prerequisites. Every sentence earns its place with no 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?

The description covers billing, package types, and prerequisites, but does not mention the two-call confirmation flow described under confirm_token. Since the schema explains that flow, the gap is partially mitigated, but the tool is complex (5 params, no output schema) and the description could be more self-sufficient.

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 baseline is 3. The description reinforces that num is in GB and explains the relationship between product type and bill_timelen, which adds slight clarity, but most parameter meaning is already captured in 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?

Description states a specific verb ('购买' / purchase) and resource ('动态住宅流量' / dynamic residential traffic), and clarifies the two product variants (permanent vs term). While it doesn't explicitly name sibling tools, the resource and product scope distinguish it from siblings like order_buy_ipv6 and order_buy_time_ip.

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?

No guidance is given on when to use this tool versus alternatives. The description only states preconditions (account verification) and package-type rules; it does not mention sibling tools or conditions that would select one over another.

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

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.

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds valuable behavioral context: it deducts balance, consumes monthly quota, has a default validity of 1 day, and is restricted to business testing. It also discloses the two-step confirmation flow via confirm_token, which is beyond what annotations provide. No contradiction with annotations.

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 a single paragraph of 4 sentences, front-loaded with the most critical behavioral facts (billing, quota, rejection conditions). It's concise and every sentence adds value. Slightly dense but appropriate for the complexity of the operation.

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 mutating purchase tool with 9 parameters and no output schema, the description covers the key operational constraints: billing, quota, validity, verification requirements, and the confirmation flow. It doesn't describe the return value or what happens after a successful purchase, but the confirm_token flow is explained. Given the complexity, this is reasonably complete, though it could mention what the response contains.

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 schema already documents all 9 parameters. The description adds context about the confirm_token flow (first call returns preview and token, second call with token confirms), which is valuable. However, it doesn't add much beyond the schema for other parameters like num, country, product, etc. Baseline 3 is appropriate since the schema does the heavy lifting.

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 test IPs for static residential or datacenter products, with billing and quota implications. It distinguishes itself from siblings like order_buy_dynamic and order_buy_ipv6 by specifying '测试 IP' and the product types. However, it doesn't explicitly name sibling alternatives, so it's clear but not fully differentiated.

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 explicit context: it deducts from account balance, consumes monthly test quota, and requires prior email/phone and real-name verification. It also states when purchases will be rejected (quota exhausted or exceeding remaining quota). It doesn't explicitly say 'use this instead of order_buy_dynamic when...' but the context is clear enough for an agent to select it for test IP purchases.

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

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

Annotations already flag this as non-read-only and destructive, but the description adds concrete operational consequences: it charges account balance, rejects duplicate same-parameter requests within 5 seconds, and imposes order-level caps such as datacenter max 50 and no 7-day option. This context about cost, rate limiting, and prerequisite verification goes beyond the annotation hints. None of this contradicts the annotations.

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 three tightly packed sentences with the most important warning (balance deduction) placed first. Every sentence adds distinct information: what is purchased, backend constraints, and account prerequisites. There is no filler, and the length is appropriate for the tool's complexity.

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 purchase tool with 16 parameters and no output schema, the description covers the essential context: billing, product scope, quantity/timelen constraints, duplicate-request rejection, and verification prerequisites. It does not restate the confirm_token two-step flow or specifyIps sum rule, but those are fully described in the input schema, so the description remains sufficient for agent decision-making.

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 parameter coverage is 100%, so the baseline is 3. The description adds value by reaffirming that `num` is the IP count and backend limits, and it contributes a new constraint not present in the schema: datacenter purchases cannot use the 7-day `timelen` value. This extra constraint pushes it above baseline, though most parameter detail still lives in 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?

The description states a specific action: purchasing time-based IP sub-accounts for static residential or datacenter products, with `num` as the IP quantity. This clearly differentiates it from sibling buy tools such as order_buy_dynamic and order_buy_ipv6 by explicitly scoping the product type. It is not a tautology and includes concrete resource context.

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 implies usage context (for static residential/datacenter timed IP purchases) and states prerequisites such as email/phone and real-name verification before purchase. However, it never explicitly tells the agent when to choose this tool over siblings like order_buy_dynamic, order_buy_ipv6, or order_buy_test_ip, nor does it mention alternatives. Thus usage guidance is present but only implied.

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

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

The description adds meaningful behavioral context beyond the annotations: submission triggers manual review, refunds are not immediate, and duplicate applications are rejected. It also discloses backend eligibility restrictions. These traits are not inferable from readOnlyHint=false, openWorldHint=true, or idempotentHint=false, and there is no 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 dense sentence front-loads the action and the manual-review consequence, then packs the backend restrictions into a compact, scannable list. There is no filler or 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?

Combined with the rich schema, which already explains the confirm_token two-step confirmation flow, the description covers purpose, eligibility, timing, and post-submission outcome. Nothing an agent needs to decide whether to invoke this tool 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?

Schema description coverage is 100%, so the schema already documents id, remark, product enum, and confirm_token in detail. The description adds no parameter-level meaning beyond referencing the static-residential product scope, so the baseline 3 is appropriate.

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 action ('申请退单' – apply for refund) targeting a static-residential subaccount, and clearly distinguishes this tool from sibling order/subaccount tools by its refund purpose and manual-review caveat. The verb and resource are 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 explicitly states when the tool can be used ('只能在下单后 1 天内申请') and lists disqualifying conditions: renewed subaccounts, ongoing bandwidth upgrade orders, invoiced consumption records, and duplicate applications. This gives an agent clear go/no-go criteria, and no refund-specific sibling tool exists to confuse it with.

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

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

The description discloses two important behaviors beyond the annotations: it charges the account balance ('会从账户余额扣费') and caps a single call at 200 sub-accounts. The destructiveHint annotation already flags risk, so the added billing and limit context is valuable. It does not mention the confirm_token preview flow, but that is documented in the parameter schema.

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 a single dense sentence that front-loads the most important operational fact (balance deduction) before explaining input structure and limits. Every clause adds useful information with no filler.

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 tool with 4 parameters, full schema coverage, and no output schema, the description covers the essential invocation details: product scope, grouping requirement, per-group fields, and the batch limit. The confirm_token two-step flow is only in the schema, but since the schema fully documents it, the description remains adequately complete.

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 baseline is 3. The description adds extra meaning by specifying that content must be grouped by country, that each group should contain id list, country, and duration, and that the total is limited to 200 sub-accounts. This goes beyond the raw schema field descriptions.

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 action and resource: renewing time-based IP sub-accounts for static residential or datacenter products. This clearly distinguishes it from siblings like order_renew_ipv6, order_buy_time_ip, or order_buy_dynamic, and the product scope is explicit.

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 intended use is implied by the verb '续费' and the resource scope, but there is no explicit guidance about when to prefer this tool over alternatives such as order_renew_ipv6 or order_buy_time_ip. No when-not-to-use conditions or exclusions are stated.

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

Does 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.

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds downstream usage context but no additional behavioral traits such as pagination, ordering, or rate limits. With strong annotation coverage, a mid score is appropriate.

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 sentence that front-loads the core query action, then explains the value of the returned id. Every word earns its place and there is no redundant or filler content.

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 one-required-param read-only list tool with no output schema, the description is complete: it specifies the input domain, what is returned, and how the returned id is consumed downstream. An agent has enough information to call it correctly.

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%: the single required product parameter has an enum and a per-value description. The description's mention of 动态住宅产品 aligns with the schema but adds no extra semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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 opens with a specific verb and resource: '查询动态住宅产品可用的供应商（资源池）'. It also clarifies the practical use of the returned id as a spec for adding sub-accounts or querying traffic. Although it doesn't name sibling tools explicitly, the resource scope clearly distinguishes it from list tools like city_list or country_list.

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?

It states when the result matters: the returned id can be used as spec when adding sub-accounts or querying traffic. This gives an agent a clear usage context. It doesn't mention exclusions or alternatives, but for a simple read-only list tool this level of guidance is adequate.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond the annotations, such as the scope ('某国家下') and the notion of '可选的' (selectable options), but it does not disclose pagination, ordering, or the behavior when country_code is omitted.

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 a single concise sentence that front-loads the core action and resource. It contains no redundant phrases and every word contributes to understanding the tool's purpose.

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 simple read-only lookup with full parameter documentation and explicit annotations, the description is nearly complete. The main gap is that it does not describe the return shape (e.g., list of state IDs and names) since there is no output schema, but this is a minor omission for such a straightforward list tool.

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 are already documented in the input schema. The description does not add meaning beyond what the schema provides, such as the source of country_id or the product enum values, keeping it at the baseline for high coverage.

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 action ('查询...可选的州或省'), identifies the resource (states/provinces), and scopes it to a product and country. This unambiguously differentiates it from sibling tools like country_list and city_list without needing to inspect the schema.

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 implies the tool is used when a list of states/provinces for a specific country and product is needed, but it does not explicitly state when to use it instead of alternatives or mention prerequisites. The parameter description for country_id references country_list, but that guidance lives in the schema rather than the main description.

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

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

The description discloses an important behavior beyond the annotations: the operation consumes already-purchased main-account traffic and does not incur extra charges, and it returns the new sub-account credentials. However, it omits the confirm_token two-step confirmation behavior: on clients without popup support, the first call returns a preview and confirm code rather than the created accounts, which would qualify the statement about returning account/password.

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?

Two short sentences deliver the action, the target product, the billing implication, and the return value with zero filler. The most essential information is front-loaded, making the description easy for an agent to parse quickly.

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 complex tool with 12 parameters and no output schema, the description is reasonably efficient but leaves significant behavioral gaps: the two-step confirmation flow, the exact response structure beyond account/password, and error/failure conditions are not covered. The schema compensates for parameter details, but the description alone is only minimally viable.

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 input schema has 100% parameter coverage with detailed descriptions, including enums for product, protocol, and use_random_username. The description itself only restates num and adds no new parameter-level meaning, so the baseline score of 3 is appropriate.

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 names a specific verb ('新增'), a resource ('动态住宅产品子账号'), and a quantity ('num 个子账号'), clearly differentiating it from siblings like sub_account_delete, sub_account_update, and sub_account_list. It also adds billing context, so an agent can immediately identify the operation as a paid-resource add rather than a generic create.

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 intended use is implied: call this when adding dynamic residential sub-accounts. However, there is no explicit guidance about when not to use it or which alternative sibling might be preferable for other sub-account operations. The naming and sibling list make the role fairly obvious, but the description itself doesn't state exclusions or alternatives.

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

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

Annotations already declare destructiveHint=true, so the description's addition of '不可恢复' (irreversible) provides extra specificity beyond the annotation. However, it does not mention the confirm_token flow or any other side effects, which is a notable behavioral aspect left to the schema. The description adds some value but not rich behavioral context.

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 two short sentences with the crucial warning (irreversible) front-loaded, and no redundant information. It is appropriately sized for a simple deletion tool.

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 description is adequate for a straightforward deletion tool, but it omits mentioning the confirm_token behavior (e.g., whether a confirmation step may be required) and does not explicitly note the single-item scope versus batch alternatives. However, the schema covers these details, so the description is not critically incomplete.

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 (id, product, confirm_token) are already documented. The description does not add any parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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 action ('删除动态住宅的一个子账号' - delete a sub-account of dynamic residential) and explicitly notes irreversibility, distinguishing it from batch operations like sub_account_delete_batch. It is specific with verb and resource.

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?

There is no guidance on when to use this tool versus alternatives, such as sub_account_delete_batch, or any prerequisites or conditions. The description only states the basic function, leaving the agent to infer usage context from the tool name and schema.

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

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

The description explicitly warns '不可恢复' (irreversible), which goes beyond the destructiveHint annotation. It does not mention the two-step confirm_token preview flow, but that is already documented in the input schema, and the description does not contradict the annotations.

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 two short sentences with no filler. The irreversible warning is front-loaded, followed immediately by the action and id format.

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 combination of description and schema covers the product enum, id format, destructive nature, and confirm_token workflow. Without an output schema, it could describe the preview result more directly, but the schema's confirm_token parameter provides the needed context.

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 baseline is 3. The description adds little beyond the schema: '动态住宅' loosely ties to the product enum, and the ids comma-separated rule repeats 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?

The description uses a specific action ('批量删除') and resource ('动态住宅的多个子账号'), and it explains that ids are comma-separated sub-account IDs. This clearly differentiates it from single-delete sibling tools such as sub_account_delete.

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 implies the batch use case by saying it deletes multiple sub-accounts at once, but it does not explicitly state when to prefer this over sub_account_delete or mention any exclusions. Usage is inferred rather than spelled out.

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

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

Annotations already establish the safe read-only, idempotent nature. The description usefully adds behavioral constraints beyond annotations: results are daily, in MB, interval max 30 days, and end date must not be later than today. This is valuable operational context without contradicting annotations.

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?

Two concise, front-loaded sentences cover the action, resource, key output unit, and the two most important constraints. Every phrase earns its place with no repetition of schema details.

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 simple read-only query with fully documented parameters, the description is nearly complete: it states daily granularity, units, and date constraints. The only minor gap is not detailing the exact response shape, but with no output schema this is acceptable given the clear daily-flow summary.

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 coverage is 100%, so each parameter is already documented. The description adds a cross-parameter constraint not present in the schema—the 30-day maximum interval—and clarifies output units, which helps an agent construct valid date ranges.

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 clear action ('查询'), the exact resource (动态住宅子账号的每日流量), and a meaningful output detail (flow 单位 MB). This distinguishes it from sibling tools like main_account_flow and bandwidth_trend by explicitly scoping to a sub-account.

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 clear context: it is for querying a specific sub-account's daily traffic in a date range. It does not explicitly name alternatives or say when not to use this tool, but the sub-account versus main-account focus provides enough practical guidance for selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's job is light. It adds that the tool returns both the limit setting and the used amount, but it does not explain edge behaviors such as what happens when no limit is configured or whether usage is real-time.

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?

A single, dense Chinese sentence that is front-loaded with the query action and the resource, with no redundant words or preamble.

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 two-parameter read-only query with rich annotations, the description covers the essential intent and result contents. It is slightly incomplete in not distinguishing from the batch variant or describing the response shape, but the simplicity and annotations make the tool callable.

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%, with both 'account' and 'product' already documented, including enum values. The description adds only the framing '动态住宅子账号' and does not materially enrich parameter meaning 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?

Description states a specific query action ('查询') on a clearly identified resource ('动态住宅某个子账号的流量上限设置与已用量'), which is distinct from setting/updating limits. It does not explicitly contrast with sub_account_flow or sub_account_limit_flow_batch, so sibling differentiation is only partial.

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?

No guidance on when to use this tool instead of the sibling sub_account_limit_flow_batch, sub_account_flow, or set_limit_flow tools. The product enum implies the supported products, but no when/when-not conditions or alternatives are mentioned.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description only adds the paginated multi-account query behavior and does not disclose response format, pagination semantics, or edge cases.

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 one tight, front-loaded sentence with no filler or redundancy. It communicates the verb, resource, and scope immediately and every word earns its 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?

For a simple read-only query tool, the description plus schema and annotations is adequate for invoking the tool correctly. However, there is no output schema and the description does not describe the response shape or explicitly route among the closely related sibling tools, leaving clear gaps.

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 schema already documents all four parameters including the product enum and accounts format. The description does not add meaningful parameter-level information beyond the schema, so the baseline score of 3 applies.

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 uses the specific verb '分页查询' (paged query) and names a precise resource: the traffic limit settings of multiple dynamic residential sub-accounts. '多个' and '查询' clearly distinguish it from single-account queries and from batch set operations such as sub_account_set_limit_flow_batch.

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 use case is implied: query the traffic limit settings for multiple sub-accounts with pagination. However, the description does not explicitly state when to choose this over the sibling sub_account_limit_flow (single account) or when to use the set_* variants instead.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive hints. The description adds pagination behavior, the returned field set, and the tool's role as an id source. No contradictions exist; the behavioral context is appropriate, though it does not disclose response format details.

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?

A single, front-loaded sentence states the core function and return fields, followed by an essential workflow instruction. Every phrase earns its place; no redundancy or filler.

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 read-only list tool, the description plus 100% schema coverage covers the essentials: purpose, output scope, and the tool's role in the broader sub-account workflow. The absence of an output schema is not critical, though a short note on output format would round it out.

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%, with all 9 parameters documented in detail, so the baseline is 3. The description itself adds no per-parameter semantics beyond noting the output includes id and that the query targets a product; it does not compensate further.

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 uses a specific verb and resource: '分页查询某产品的子账号' (paginated query of sub-accounts for a product), and lists concrete return fields (id, password, port, country, expiry). It also differentiates itself from the many sub_account_* mutation siblings by explicitly stating it is the source for sub-account ids used by all later operations.

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 a clear when-to-use signal: '后面所有按子账号操作的工具都从这里取 id' (all subsequent sub-account tools get ids from here), establishing this as the prerequisite lookup before any sub-account mutation. It does not explicitly name alternatives or exclusions, but the workflow role is unambiguous given the sibling list.

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

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

The description explicitly discloses that the operation overwrites the username and password for each sub-account in content, which is a key behavioral trait beyond the annotations. It also conveys batch processing. No contradiction with the annotations; readOnlyHint=false is consistent with a write operation.

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 a single concise sentence that front-loads the core action and key constraints. Every phrase adds information, with no filler or repetition.

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 tool with a two-step confirmation flow via confirm_token, the description does not mention this interaction pattern, though the schema parameter description covers it. The tool is also a batch write with overwrite semantics, and the description captures that. Overall adequate but with a gap around the confirmation process.

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 baseline is 3. The description adds only a minor clarification that multiple accounts can be passed at once, which is already implied by the array type. It does not enrich the meaning of product or confirm_token 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?

The description clearly states the action: setting custom usernames and passwords for sub-accounts, supporting batch input, and overwriting existing credentials. It is specific and unambiguous, but it does not explicitly differentiate from siblings like sub_account_set_password_batch or sub_account_update_batch, so it falls short of a 5.

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?

No guidance is provided on when to use this tool versus alternatives such as sub_account_set_password_batch or sub_account_update_batch. The description mentions batch capability but does not state when this tool is preferred or when another tool should be used instead.

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

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

Annotations only indicate that the operation is not read-only and is not idempotent. The description adds meaningful behavioral context: reaching the limit disconnects the connection, the limit resets next cycle, and only one cycle can be set per sub-account. It stops short of describing the preview/confirm behavior, which is left to the schema.

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 a single, focused sentence that front-loads the core operation and then adds the key behavioral constraints. Every clause earns its place and there is no filler.

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 that the schema fully documents all parameters, including the confirm_token preview flow, the description provides the missing operational context: disconnection on limit and per-cycle uniqueness. The main gap is sibling routing, which prevents a perfect score.

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 description is not required to restate parameter meanings. It adds no extra meaning beyond the schema, which is acceptable but not exceptional.

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 sets a traffic limit for a dynamic-residential sub-account within a cycle, and describes the limit enforcement and reset behavior. It is clear about the single-account scope, though it does not explicitly differentiate itself from sibling tools like sub_account_set_limit_flow_batch.

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 no guidance on when to use this tool versus its siblings, such as the batch variant or the read-only sub_account_limit_flow. It also does not mention the confirmation-token flow or when limit_flow=0 should be used to remove a limit.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the constraint that one account can only have one cycle set, which is useful behavioral context. However, it does not disclose what happens on partial failure, whether existing limits are overwritten, or how the confirm_token two-call flow behaves beyond the parameter description.

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 a single, front-loaded sentence that states the action, scope, and a key constraint. It is concise and readable, though it could be slightly more structured by separating the constraint into its own sentence.

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 batch mutation tool with no output schema, the description plus schema covers the core inputs well. However, it lacks guidance on the confirm_token two-step confirmation flow in the main description, and does not explain failure semantics or whether the operation is atomic. Given the tool's complexity (batch, confirmation token, multiple enums), a bit more context would be needed for full completeness.

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 schema already documents all parameters thoroughly, including enums and the meaning of limit_flow=0. The description adds the batch-level constraint ('同一个子账号只允许设置一个周期') but does not add much beyond the schema. Baseline 3 is appropriate.

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 ('批量设置' = batch set) and resource ('多个动态住宅子账号...流量上限'), and adds a key constraint ('同一个子账号只允许设置一个周期'). It is clear enough to distinguish from the single-account sibling sub_account_set_limit_flow, though it does not explicitly name that sibling.

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 implies batch usage and the one-cycle-per-account constraint, but it does not explicitly state when to prefer this tool over sub_account_limit_flow_batch or sub_account_set_limit_flow, nor does it mention the confirm_token flow as a usage condition. The confirm_token parameter description provides some usage guidance, but the main description lacks explicit when-to-use/alternatives guidance.

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

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

Annotations only state readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds useful behavioral context beyond those hints: it does not modify usernames, only supports letter/digit passwords of length 8–30, and rejects system-default credentials. This meaningfully clarifies operational constraints, though it does not cover result or confirmation behavior.

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 two concise sentences with no filler. It front-loads the main purpose, immediately states constraints, and then gives the prerequisite and alternative tool. Every sentence earns its 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 description provides the core information needed for invocation: target scope, required constraints, and the prerequisite credential setup. The confirm_token flow is left to the schema, where it is fully explained. Without an output schema, a brief note on result/preview behavior could help, but this is a minor gap rather than a blocking omission.

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 baseline is 3. The description's password rule ('密码只能是字母和数字，长度 8 到 30') duplicates the customPassword schema description, and '只改密码不改用户名' is effect clarification rather than new parameter semantics. No substantial parameter meaning beyond the schema is added.

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: '批量修改时长类子账号的密码' (batch modify passwords of duration-type sub-accounts), and explicitly scopes the operation with '只改密码不改用户名' (only change password, not username). It distinguishes itself from the sibling sub_account_set_credentials by naming it as the prerequisite tool.

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 explicit when-to-use guidance and an exclusion: it can only change passwords when custom username/password already exist, and '系统默认的账密不能用它改' (default credentials cannot be changed with it), directing the agent to use sub_account_set_credentials first. This clearly separates the tool from the setup flow.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds the concrete state-changing behavior: enabling or disabling port connections. This is consistent with the annotations, but it does not disclose potential side effects such as active connections being dropped when the port is disabled, nor does it mention the two-call confirmation behavior beyond what the confirm_token schema description already provides.

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 a single, front-loaded, information-dense sentence. It states the action, scope, and resource with no filler or repetition. Every word contributes to understanding the tool's purpose.

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 that the schema fully explains all parameters, including the confirm_token preview flow, and annotations cover the safety and idempotency profile, the description is largely complete for invocation. The main missing element is usage positioning relative to sibling tools, but that is partially captured by the unique purpose statement and is more of a usage-guideline 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 parameters are already fully documented (ids, product enum meanings, use_ip_port toggle, and confirm_token flow). The description adds no additional parameter-level meaning. With complete schema coverage, the baseline of 3 is appropriate.

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 uses a specific verb-resource pairing: '批量开启或关闭' (batch enable/disable) '静态住宅子账号的 IP 端口连接状态' (static residential sub-account IP port connection status). This clearly identifies the action and resource. It does not explicitly name sibling alternatives, but the unique port-toggle action is sufficiently distinct among the sub_account_* siblings.

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 no guidance on when to use this tool versus alternatives like sub_account_whitelist, sub_account_set_credentials, or sub_account_update. There is no mention of prerequisites, exclusions, or the confirm_token flow as a usage consideration. The intended context is only implied by the tool name and description.

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

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

Annotations already convey readOnlyHint=false and destructiveHint=false, and the description is consistent with them. The description adds no extra behavioral context, such as the two-step confirm_token flow or effect scope, but the basic safety profile is covered by annotations.

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 a single front-loaded sentence with no filler or redundant information. It is appropriately sized for the simplicity of the operation.

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 tool has a conditional confirm_token two-step behavior and no output schema, yet the description is very thin and relies on the schema to convey that nuance. It also does not mention when to prefer the batch sibling, though the rich schema and annotations cover most operational details.

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?

All four parameters are fully described in the input schema, so the description does not need to repeat them. It adds no additional parameter semantics beyond what the schema already provides, which is acceptable but not above baseline.

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 action (修改备注) and resource (动态住宅的某个子账号), which clearly identifies what the tool does. It distinguishes itself from add/delete/credentials siblings by being singular, but it does not explicitly differentiate from sub_account_update_batch.

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?

There is no guidance about when to use this tool versus alternatives such as sub_account_update_batch or sub_account_set_credentials. The only hint is the singular '某个子账号', which is implicit rather than explicit.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is known. The description accurately identifies what gets modified, but it does not disclose side effects such as the two-step confirm_token flow; that detail appears only in the parameter schema.

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 a single sentence that front-loads the action and resource, then clarifies the key format requirement for ids. Every word earns its place with no filler or repetition of schema details.

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 that the schema thoroughly explains all five parameters, including the two-step confirm_token behavioraine, and annotations cover the safety profile, the description is nearly complete. The only gap is the absence of an output-schema note, but the operation itself is fully specified for an agent to invoke correctly.

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%, with per-parameter descriptions, an enum expansion for product, and a range for changeInterval. The description only restates that ids are comma-separated and that remark/changeInterval are editable; it adds no meaning 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?

The description names the action ('批量修改' = batch modify), the resource ('多个动态住宅子账号' = multiple dynamic residential sub-accounts), and the exact fields affected ('备注或 IP 切换间隔'). It is clearly distinct from sub_account_update in its batch nature, though it does not explicitly name the singular sibling alternative.

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 word '批量' and the comma-separated ids parameter imply this is for updating multiple sub-accounts at once, but the description gives no explicit when-to-use or when-not-to-use guidance, and does not reference alternatives such as sub_account_update for single updates. Usage context is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond stating the read operation, offering no details on return format or potential edge cases. It is consistent with annotations but adds little extra value.

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 a single, short sentence that directly states the action and target. It contains no filler or redundant information, and the key verb is front-loaded.

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 simple read-only operation with annotations covering safety and a schema covering both parameters, the description is largely sufficient. It lacks explicit mention of the return format (e.g., a list of IPs), but this is implied by the tool name and description, and the absence of an output schema makes 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 schema already documents both parameters (id and product) with descriptions. The tool description does not add any additional parameter details, meeting the baseline for high coverage without extra elaboration.

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 '读取动态住宅某个子账号的 IP 白名单' clearly states the action (read), the resource (IP whitelist of a sub-account), and the scope (dynamic residential). It is specific and distinguishable from siblings like sub_account_list or sub_account_update, as no other tool mentions whitelist functionality.

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 no guidance on when to use this tool versus alternatives, nor any context about prerequisites or typical use cases. It only states what it does, leaving the agent to infer usage from the tool name alone.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, lowering the burden. The description adds valuable return-shape detail: data is a direct amount string in yuan, and points out that the balance breakdown lives elsewhere. This goes beyond annotation coverage without contradicting it.

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?

Two short sentences, front-loaded with the core purpose, followed by the return format and the cross-reference to user_info. Every clause earns its 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?

For a parameterless, annotation-covered read operation, the description is complete: it defines what is returned, the unit, the data shape, and where to find related breakdown information. No output schema exists, so the in-description return details are appropriately sufficient.

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?

There are zero parameters and the schema is already 100% covered, so the description has no parameter semantics to add. Baseline 4 applies because no parameter documentation is needed at all.

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?

States a specific action and resource: '查询当前账号余额' (query current account balance). It also distinguishes itself from sibling user_info by pointing there for the recharge/gift balance split, so an agent can tell what this tool returns versus user_info.

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 clearly implies use when you need the current account balance and explicitly routes the agent to user_info when a recharge/gift split is needed. It lacks a broader when-not-to-use statement, but for a parameterless balance query the routing cue is strong.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description does not need to restate safety. The description adds concrete detail about the returned fields, which is beyond the annotations and helps the agent understand the exact output semantics. It does not contradict annotations and adds useful context regarding what data is returned.

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 a single, short sentence that front-loads the purpose ('query current account basic info and balance') and then enumerates the specific fields with labels. Every word earns its place, and there is no fluff. It is highly concise and well-structured.

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 simple read-only tool with no parameters, the description is largely complete: it explains the purpose and the key return fields. However, it mentions 'basic information' but only details balance fields, leaving some ambiguity about whether other basic info fields exist. Without an output schema, a bit more clarity on the full return set would improve completeness, but the current level is adequate.

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?

There are zero parameters, so the schema is trivially 100% covered. The description adds meaning by explaining the returned fields, which is the only semantic content that matters. With no parameters, the baseline is 4, and the description fulfills that by enumerating the output fields, making the tool's behavior predictable without needing parameter documentation.

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 queries the current account's basic information and balance, and enumerates the specific return fields (money, origin_money, give_money). This is a specific verb+resource, and the field list distinguishes it from sibling tools like user_balance, which likely returns a different view. It is immediately clear what this tool does.

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 states what the tool does but gives no explicit guidance on when to use it versus alternatives such as user_balance or user_price. The purpose is clear enough that an agent might infer usage, but there is no direct statement about when this tool is the right choice (e.g., when you need the full balance breakdown vs. a single field). This is a minor gap given the tool's simplicity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: results are scoped to the current account and include admin-customized prices, which is useful beyond the annotations.

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?

Two short sentences: the first defines what the tool returns, the second gives the practical use case. No redundant wording, and the key distinction (custom prices) is front-loaded.

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 parameterless, read-only query tool, the description covers what is queried, the account scope, the inclusion of custom prices, and when to use it. No output schema exists, but the semantic result is clear enough for an agent to invoke it correctly.

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 tool has zero parameters and the schema is empty, so the baseline is 4. The description correctly implies no user input is needed by referring to '当前账号', making the parameterless nature self-evident.

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?

Description states a specific verb ('查询') and resource ('当前账号各产品的实际价格'), adding that custom admin prices are included. This clearly distinguishes it from sibling tools like official_price, which presumably returns standard pricing.

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 a clear use case: '下单前用它估算费用' (use it to estimate costs before placing an order). It does not explicitly name official_price as an alternative or state when not to use it, but the actual-price vs official-price contrast is strongly implied.

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