Grant or revoke QQ group administrator rights for a member. Requires group owner permissions; provide group ID, target user ID, and enable flag to set or remove admin status.
设置或取消群管理员 (OneBot 11: set_group_admin)。需群主权限。 :param group_id: 群号 :param user_id: 目标成员 QQ 号 :param enable: True 设为管理员，False 取消管理员
| Name | Required | Description | Default |
|---|---|---|---|
| enable | No | True 设为管理员，False 取消管理员 | |
| user_id | Yes | 目标成员 QQ 号 | |
| group_id | Yes | 群号 |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It usefully discloses the group-owner authorization requirement, but for a mutating tool it says nothing about reversibility, effect on the target member, failure modes, or whether the target must already be in the group.
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 purpose and permission requirement are front-loaded in the first two sentences, and the whole definition is short. The trailing ':param' lines duplicate the schema, which is mild waste, but nothing is padded or meandering.
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?
There is no output schema and no annotations, so the description must carry the behavioral load. It covers identity, permission, and the enable flag, but omits return/failure behavior and edge cases for a mutation tool — adequate but with 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%, and the description's param lines ('群号', '目标成员 QQ 号', 'True 设为管理员，False 取消管理员') merely restate what the schema already documents verbatim. With the schema doing the heavy lifting, 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 pair and resource — set or revoke group administrator — plus the OneBot 11 action name, so the agent knows exactly what it does. It does not explicitly contrast itself with nearby siblings such as set_group_special_title or set_group_ban, but the overlap risk is low, so 4 rather than 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?
'需群主权限' gives a real precondition (group-owner permission) that helps the agent decide whether the call can succeed. However, there is no explicit when-to-use vs alternatives guidance or exclusion conditions, so this lands at implied rather than stated usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.