Skip to main content
Glama

自定义子账号账密

sub_account_set_credentials

Update credentials for multiple proxy sub-accounts at once by specifying product and a list of IDs with custom username and password.

Instructions

为子账号设置自定义用户名和密码,一次可传多个;覆盖 content 里每个子账号的账号与密码。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentYes要修改的子账号列表,每项写子账号 id、自定义用户名、自定义密码
productYes产品:dynamic-no-expiry=动态住宅流量(永久),dynamic-monthly=动态住宅流量(期限),static-standard=静态住宅(非原生),static-native=静态住宅(原生),static-isp-native=静态住宅(运营商原生),static-ipv6=静态住宅(IPv6),datacenter=数据中心
confirm_tokenNo确认码。客户端不支持弹窗确认时,第一次调用只返回操作预览和确认码;把预览告诉用户并得到同意后,用相同参数带上确认码再调一次。支持弹窗确认的客户端不需要这个参数

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.