新增动态子账号

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.