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

With no annotations, the description carries the full behavioral burden. It does disclose the key trait that this mutates state and erases the message ('会改变会话状态：消息会被抹掉'), which is genuine destructive-operation context. However it omits permission/auth requirements, irreversibility or failure behavior, and rate limits, so it is only partially complete.

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 with zero padding; the action is stated first and the state-changing consequence second. 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 one-parameter destructive tool with no output schema and no annotations, the description covers the action and the destructive effect but says nothing about failure conditions, required permissions, or what the caller gets back. It is adequate but leaves meaningful gaps for a state-mutating 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?

There is a single parameter and schema coverage is 100%, with the schema itself documenting the message_id and the two-minute eligibility window. The description adds no meaning beyond the schema, so the baseline 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 ('撤回一条已发出去的消息' / recall an already-sent message), which clearly separates it from the read-oriented get_msg sibling. It does not name any sibling or state how it differs from other 'set_' mutation tools, so it stops 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?

There is no when-to-use or when-not-to-use guidance, no mention of the two-minute recall window (that constraint lives only in the schema), and no routing to alternatives such as get_msg for reading or other message operations. The agent must infer usage entirely from the name.

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?

No annotations are supplied, so the description carries the full burden. It discloses the single most important behavioral trait: the return value is equivalent to login credentials and must not be shared or logged. It omits finer details (read-only nature is only implied by 取, no mention of permissions, storage location, or rate limits), but for a one-parameter read tool this is substantial added 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?

Two short sentences, zero padding: the action and scope come first, and the safety warning follows. 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?

For a single-parameter, no-annotation, no-output-schema tool, the definition covers what it returns (a Cookie), for which domain, and the critical sensitivity caveat. Only minor gaps remain, such as return format or how a missing/expired cookie is surfaced.

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 domain parameter is already documented with its default. The description only restates '指定域名' without adding format, validation, or defaulting behavior beyond the schema, so the baseline 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 names a specific verb+resource and scope: retrieve the Cookie for a specified domain. The resource is unambiguous and clearly distinct from siblings like get_csrf_token or get_login_info. However, it never explicitly routes the agent against those adjacent tools, so it stops short of the top band.

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 the other credential-adjacent siblings (get_csrf_token, get_login_info) or on preconditions. The only guidance given is a handling warning about not pasting the result into chats or logs, which is a caution rather than a selection rule.

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?

With no annotations, the description carries the full burden. It usefully discloses that the returned token is a login credential that must not be leaked, which is genuine behavioral context. However, it says nothing about authentication requirements, expiry/reuse behavior, or when the token becomes invalid.

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 resource and followed by the one behavioral caveat that matters. 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 zero-parameter, no-output-schema getter the definition is minimally workable, but the agent is left guessing what the token is for, how long it lives, and where it is consumed. The sensitive-credential note is the only completeness-relevant content provided.

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 takes zero parameters, so there is nothing for the description to document; the baseline for a no-argument tool applies. The description correctly adds no parameter noise.

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 verb and resource ('取 CSRF Token（bkn）'), which is unambiguous. It is distinguishable from siblings like get_login_info and get_cookies because the resource is named precisely, though it does not explicitly contrast itself against those closely related credential tools.

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 call this tool, what it is needed for, or which alternatives (get_cookies, get_login_info) exist. The only instruction is a security warning, not a usage condition, so an agent must infer the context entirely.

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?

No annotations are provided, so the description carries the full burden. It does disclose the behavioral trait ''只读'' (read-only), which is meaningful context, but says nothing about permissions, rate limits, error behavior when neither id is given, or the shape of returned content.

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?

Three compact clauses with the purpose front-loaded, the parameter rule second, and the read-only note last. 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?

With no output schema and no annotations, the description should say more about what is returned (the merged forward content structure) and what happens when neither identifier is provided. It covers purpose, parameter alternation, and read-only status, but leaves the return behavior unspecified.

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 baseline is 3, but the description adds genuine meaning by clarifying that either id or message_id may be supplied (an either/or acceptance rule the schema does not state). It stops short of explaining what each identifier represents when they differ.

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 verb+resource (取合并转发中的内容 – retrieve content from a merged forward message), which clearly separates it from get_msg for ordinary messages. It does not name the sibling explicitly, so an agent must infer the distinction between forward-message content and regular message content.

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 useful in-tool guidance (''id 或 message_id 传一个即可'' – pass either one), but offers no explicit when-to-use vs the closest sibling get_msg, nor any preconditions. Usage 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?

With no annotations provided, the description carries the full burden, and it does disclose that the operation is read-only and that the result can be very long when there are many friends. However, it omits other behavioral facts an agent would want: no return format, no pagination or truncation behavior, and no mention of auth or permission 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?

Two short sentences, zero filler, with the core action front-loaded and the safety/length caveat secondary.

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, parameterless, read-only list tool with no output schema, the description covers the essentials: what it fetches, that it is read-only, and that the payload can be large. Only the lack of any return-shape or pagination hint keeps it short of perfect.

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 takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool is 4.

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 ('拉取全部好友列表' – fetch the complete friend list) and makes the scope explicit with '全部' (all). It is clear what the tool returns, though it does not name the sibling get_group_list or otherwise distinguish itself from the other list tools.

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 get_group_list, nor any note on prerequisites. 'Pull the full list' implies there is no filtering option, but that is left for the agent to infer.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully declares the operation is read-only ('只读'), but does not explain authentication needs, rate limits, cache behavior, or response completeness beyond the brief field hints.

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 clauses and is front-loaded with the core action. Every element earns its place by naming the lookup key, the resource, and the read-only nature.

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 tool with a fully described schema and no output schema, the description gives enough context to invoke it correctly. It could be stronger by naming sibling alternatives or cache behavior, but it is largely complete for the tool's complexity.

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 fully documents group_id and no_cache. The description adds no parameter-level details beyond implying that group_id is the lookup key, making the baseline 3 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 and resource: query group profile by group ID, with examples of returned fields (group name, member count, etc.). It distinguishes broadly from list-style siblings, but does not explicitly contrast with tools like get_group_member_info or get_group_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 gives no when-to-use or when-not-to-use guidance beyond the implied action of looking up a group by ID. It does not mention alternatives such as get_group_list for discovering IDs or get_group_member_info for member data.

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?

No annotations are provided, so the description carries the full burden. It does disclose the key trait that this is a read-only (只读) operation, and notes the cache-refresh behavior. However it says nothing about return format, pagination, or ordering, and read-only alone is a thin 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?

Two short, front-loaded clauses with no filler: the operation is stated first, then the safety trait and the cache toggle. 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 zero-required-parameter read tool with no output schema and full schema coverage, the description is nearly sufficient. It leaves only minor gaps around result ordering/pagination that an agent might want.

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 single parameter's meaning is fully documented in the schema. The description's 'no_cache=true 强制刷新' largely restates that definition, adding little beyond it, 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?

States a specific verb+resource: fetch the list of groups the account has joined (拉取已加入的群列表). This is clearly distinguishable from single-group siblings like get_group_info and get_group_member_list, though it never names an alternative explicitly.

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?

'只读' plus the no_cache hint implies usage context, but there is no explicit when-to-use vs alternatives guidance (e.g., when to prefer this over get_group_info, or when a cache refresh is warranted beyond the parameter's own definition).

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?

With no annotations, the description carries the full behavioral burden. It discloses the key trait that the operation is read-only (只读), which is valuable, but says nothing about permissions, rate limits, or the shape of the returned profile data.

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 resource and scoping, with the read-only flag placed last. Nothing is wasted, though it is terse enough to leave gaps.

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, so the description is the only place return content could be described, and it only gestures at it with 名片、角色等. Combined with the missing usage guidance against siblings, it is adequate but leaves real gaps for a lookup 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 three parameters are already documented, including the useful cache hint on no_cache. The description adds no parameter-level detail beyond the schema, 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 names a specific verb and resource (query a given QQ's profile within a group) and lists example fields (名片/角色). It is clear about what it returns, though it never distinguishes itself from the sibling get_group_member_list, which an agent could easily confuse it with.

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 when-to-use guidance, no prerequisites, and no mention of the obvious alternative get_group_member_list. The agent must infer that this is the single-member lookup versus the list tool on its own.

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?

With no annotations, the description carries full behavioral burden. It usefully adds that the tool is read-only ('只读') and that large groups return hundreds to thousands of records at once, which informs output volume. However, it omits behavioral aspects such as pagination, permissions, or how caching interacts with the no_cache parameter (left to the schema), so it only partially discharges the burden.

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 clauses separated by a semicolon, front-loading the resource and then adding two critical behavioral flags. Every word 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?

For a read-only tool with no output schema, the description covers purpose, read-only nature, and output volume, but it does not mention whether the list is paginated, if there is a maximum return size, or any permission requirements. The no_cache parameter (which controls cache behavior) is not explained in the description, leaving a gap that the schema partially fills.

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 fully documents both parameters (group_id and no_cache) including usage notes and defaults. The description adds no additional parameter semantics beyond implying a group target, so 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 clear verb ('拉' = fetch) and resource ('某个群的成员列表' = a group's member list), which distinguishes it from get_group_list and get_group_member_info by resource scope. However, it does not explicitly name or contrast with sibling tools, so it remains a clear but non-differentiating restatement of the tool name.

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 explicit guidance on when to use this tool versus alternatives like get_group_member_info (for a single member). The clause '大群一次几百上千条' hints at a size caveat but does not state when to prefer or avoid this tool, leaving the agent without routing instructions.

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?

With no annotations provided, the description carries the full behavioral burden. It does declare the operation is read-only ("只读"), which is a meaningful trait, but says nothing about rate limits, auth, caching behavior, or what the returned download address looks like or how long it is valid.

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 plus two short clauses: purpose, parameter constraint, and safety profile, with zero filler. Nothing is wasted.

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 tool with 100% param coverage and no output schema, the description covers what it returns (image info and download URL), how to call it, and that it is read-only. The main residual gap is that the format/lifetime of the returned download address is not addressed.

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 baseline is 3, but the description adds real value beyond the schema: it clarifies the either/or relationship ("传一个") that the schema alone does not convey, since both properties are optional with no required fields. It does not restate the schema's own hint that file_id is preferred.

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: retrieve image info and a download address ("取图片信息与下载地址"). It is the only image-oriented tool among the siblings, so it is naturally distinguishable, though it does not explicitly contrast itself with any 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?

It gives invocation guidance ("file 或 file_id 传一个" — supply one of the two), which is useful since no parameter is marked required. However, it offers no when-to-use context, no prerequisites, and no mention of any alternative tool or condition under which to prefer one identifier over the other.

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?

No annotations are provided, so the description carries the full burden. It does disclose the safety profile ('只读，不改任何状态'), which is the most important trait for an agent deciding whether to call it, but omits auth prerequisites, behavior when no session exists, and failure modes.

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, tightly front-loaded: what it returns first, safety profile second. Every clause earns its place 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 trivial, parameterless read tool with no output schema, the description compensates by naming the returned fields (nickname and QQ number) and the read-only nature. Only the not-logged-in / error case is left unstated, 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?

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies; the description adds no parameter detail because none is needed.

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 verb (查询) and the exact resource and return fields (当前登录 QQ 的昵称与 QQ 号). An agent can immediately distinguish this from get_version_info, get_status, or get_friend_list without opening 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 phrase '当前登录 QQ' implies the context in which it applies (an authenticated session), but there is no explicit when-to-use guidance, no exclusions, and no mention of an alternative sibling for identity data. Usage is inferable 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?

With no annotations supplied, the description carries the full burden, and it usefully declares the safety profile itself (只读 / read-only), which is the key trait an agent needs. It does not disclose error behavior for a missing/invalid message_id or any rate/scope constraints, so it is adequate but incomplete.

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 very short clauses, front-loaded with the action and key, and nothing redundant. It is efficient; it could be marginally richer without losing its compactness.

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 single-parameter read tool with 100% schema coverage and no output schema, the description goes slightly beyond the minimum by naming the return payload (original message text and sender). The remaining gap — what happens when the message is absent — is minor at this complexity level.

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 message_id parameter is fully documented in the schema (integer, non-zero, sourced from an event). The description only restates that the lookup is by message_id, adding no format or constraint information beyond the schema, so the baseline 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 (取/fetch) and resource (一条消息/a single message), plus the retrieval key (按 message_id) and the returned fields (原文与发送者). This clearly separates it from write siblings like delete_msg and from list-style siblings, though it never names the closest alternative (get_forward_msg) explicitly.

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 get_forward_msg or the get_*_list tools, and no prerequisites or prerequisites noted beyond the key name. Usage is only weakly implied by the parameter mention.

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?

No annotations are provided, so the description carries the full burden; it usefully declares '只读' (read-only) and that omitting out_format skips transcoding. However it says nothing about permissions, error behavior, or the nature of the returned data, so meaningful behavioral gaps remain.

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?

Four telegraphic clauses, front-loaded with the core action, with zero filler. Everything stated earns its place for 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?

For a 3-optional-param tool with no output schema and no annotations, the description covers purpose, parameter exclusivity, transcoding, and read-only status. But with no output schema, what '语音信息' actually returns (path, URL, base64, metadata) is left unexplained.

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 already 100%, so the baseline is 3, but the description adds semantics the schema does not encode: file and file_id are mutually exclusive alternatives ('传一个') and out_format is purely optional/transcoding. That mutual-exclusivity hint is genuine added value.

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 verb and resource — retrieving voice/audio records — plus an optional transcode capability via out_format. It is clearly distinguishable by resource from siblings like get_image and get_msg, though it never names an alternative tool explicitly.

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 real parameter guidance ('pass one of file/file_id') but no when-to-use versus when-not, no conditions for preferring this over get_msg or get_image, and no prerequisites. Usage is only implied by the resource name.

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?

With no annotations provided, the description carries the behavioral disclosure burden and does state '只读' (read-only), which is a useful key trait beyond the empty schema. However, it does not cover other behavioral aspects such as permissions, rate limits, or output characteristics.

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 phrases, front-loaded with the core purpose and ending with the read-only note. Every word 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?

For a no-argument, read-only status query with no output schema or annotations, the description says what it does and that it is read-only, which is largely sufficient. It could specify what statistics are returned, but the complexity is low enough that this is 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?

The tool takes zero parameters, so the baseline is 4. There is no parameter information to add, and none is needed.

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 (查询/query) and resource (OneBot 运行状态与收发统计 / running status and send/receive statistics). This is clear, but it does not explicitly distinguish itself from siblings such as get_version_info or get_login_info, 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?

The description offers no guidance on when to use this tool versus alternatives. '只读' signals the operation is read-only but does not explain context, prerequisites, or include/exclude conditions relative to the many sibling get_* 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?

No annotations are supplied, so the description carries the full burden; it does add the useful safety signal 只读 (read-only), which rules out mutation. However it says nothing about the response shape, timing, or whether the protocol-side version can differ from the client version, so behavioral disclosure remains thin.

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, zero waste, with the queried resource front-loaded and the read-only property stated last. Nothing could be removed without losing information.

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 trivial zero-parameter read tool with no output schema, the description identifies both the act and the content of the result (version and application name). It is nearly complete, missing only detail on how the returned values are shaped.

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 takes zero parameters, so there is nothing for the description to disambiguate; the schema is fully closed (additionalProperties: false). Baseline 4 applies for a param-free tool.

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 verb (查询) and a specific resource pair (协议端版本与应用名), which an agent can separate from siblings like get_status (runtime status) and get_login_info (account identity). It is clear but does not explicitly differentiate itself from those siblings in prose.

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 statement of when to call this versus the nearby read tools (get_status, get_login_info), nor any prerequisites or exclusions. The agent must infer usage from the 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?

No annotations are provided, so the description carries the full burden. It does disclose the key side effect (it changes the recipient's like count) and the schema adds a QQ daily cap, but it omits permission/friend requirements, failure modes, and mutability 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?

Two short clauses, front-loaded with purpose and default, and no wasted wording. Every sentence contributes either the action or the side effect.

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 mutation tool with no annotations and no output schema, the description covers the action and side effect adequately. However, it says nothing about authorization prerequisites or what happens on failure/daily-limit exhaustion, leaving meaningful gaps for a write 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 both parameters are already documented, including the default and the daily limit. The description restates the default (1 time) without adding syntax or constraint detail beyond the schema, making the baseline 3 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?

States a specific verb (点赞/like) and resource (好友/friend), plus the default behavior (default 1 time). It distinguishes itself from the sibling get_/set_ tools, which are all reads or settings mutations, so an agent can identify this as the 'like a friend' action.

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 explicit when-to-use or when-not-to-use guidance and no named alternatives (there are none among the siblings). The only contextual hint is the default count and an implied 'usually a friend' requirement, which is not framed as 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?

No annotations are provided, so the description carries the full burden. It discloses a key behavioral effect—that approving or rejecting changes the friend relationship for both parties—but it does not cover permissions, reversibility, notifications, or other side effects expected for a mutation tool.

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, front-loaded sentences with no wasted text. It states the action first and then the primary consequence.

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 low-complexity mutation tool with a fully covered schema and no output schema, the description is nearly complete: it identifies the action and its relationship-changing effect. It stops short of describing permissions or return behavior, but those gaps are minor given the schema's parameter documentation.

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 fully documents both the one-time flag handle and the approve boolean. The description adds no parameter-level detail beyond what the schema provides, making the baseline score of 3 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 pair (同意或拒绝) and resource (好友申请), making the tool's purpose immediately clear. It also distinguishes itself from the sibling set_group_add_request by explicitly scoping to friend requests rather than group requests.

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?

Usage is implied by the purpose: handle an incoming friend request by approving or rejecting it. However, it does not explicitly state when to use this tool versus the sibling set_group_add_request, nor does it mention any prerequisites beyond what the schema already provides.

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?

No annotations provided, so the description must carry the full behavioral burden. It discloses that the tool 'will change group member composition' (会改变群的成员构成), but this is partially inaccurate for rejection and omits permission requirements, rate limits, and other side effects.

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 action and a side-effect note. No 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 mutation tool with no annotations, no output schema, and five parameters, the description is thin. While parameters are covered by the schema, the description lacks usage context, prerequisites, and detailed behavioral disclosure.

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 five parameters are documented in the schema. The description adds no parameter-level details, so 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?

States a specific action 'approve or reject group join requests' (同意或拒绝加群申请), clearly identifying verb and resource. It does not explicitly reference siblings like set_friend_add_request, but the resource 'group join request' implicitly distinguishes it from other request tools.

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 versus alternatives, nor on prerequisites or event context. The description only states the action, leaving the agent to infer usage 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?

With no annotations, the description carries the full burden. '会改变对方在该群的权限' does disclose that this is a mutation of another user's privileges, but nothing is said about required permissions, reversibility, or failure modes for a privileged 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?

Two short sentences, front-loaded with the action, with no filler. It is efficient, though extremely terse for a privileged mutation.

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?

A mutation tool with no annotations and no output schema should at minimum state the authorization prerequisite and any side effects on the target; the description only notes that permissions change, leaving an agent unable to predict errors or requirements.

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 schema itself documents all three parameters, including the enable default and the get_group_list hint for group_id. The description adds no parameter meaning beyond that, so the baseline 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?

States a specific verb+resource pair: setting or unsetting group administrator, plus the effect (the target's permissions in that group change). It is clearly distinguishable from siblings like set_group_card or set_group_kick, though it never names or contrasts 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?

Usage is only implied by the purpose; there is no statement of when to prefer this over set_group_special_title or other role tools, and no prerequisites (e.g. the caller must be group owner) are given.

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?

With no annotations provided, the description carries the full burden. It discloses that the operation changes the target's state ('会改变对方的状态'), which is useful mutation context, but says nothing about permissions required, reversibility, rate limits, or whether the actor needs admin rights.

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?

Extremely short and front-loaded: it names the action, the unit, and the 0 special case in one compact sentence. Nothing is wasted, though it is terse to the point of under-specification.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the core semantics but omits permission requirements, consequences, and return behavior. It is minimally viable but not 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 coverage is 100%, with each parameter documented including the duration default and the 0=unmute semantics. The description reinforces the 0=unmute rule and the seconds unit, but adds little beyond what the schema already states, so 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?

States a specific verb+resource: mute a group member, with duration in seconds and 0 meaning unmute. Sibling tools like set_group_whole_ban and set_group_kick exist, but the description does not explicitly distinguish this per-member mute from those, so it is clear without being sibling-differentiating.

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 through the 0=unmute convention, which signals both muting and unmuting. However, it gives no explicit when-to-use guidance or named alternatives (e.g., set_group_whole_ban for all members), leaving the agent to infer from the tool name.

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?

With no annotations, the description carries the full behavioral burden. It discloses the empty-string clear behavior and that the member's display changes, but says nothing about required permissions/rank, whether a bot may modify other members' cards, or reversibility of the change.

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 tight sentences with no filler; the core action is front-loaded and the clear-behavior detail follows immediately.

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 stand alone. It covers the mutation and its clearing behavior but omits permission/authorization context that matters for a tool modifying another member's visible identity.

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 three parameters are already documented, including the empty-string semantics for card and the guidance to source group_id from get_group_list. The description's 'empty string clears' line merely duplicates the schema, so baseline 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?

States a specific verb and resource (change a member's group card) plus the effect (changes their display in that group), which separates it from set_group_name and set_group_special_title. It does not explicitly name a sibling, so it stops 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?

The description never says when to use this tool versus alternatives such as set_group_admin or set_group_special_title, nor whether it applies only to the caller's own card or any member. Usage is only implied by the tool name and purpose statement.

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?

With no annotations, the description carries the full behavioral burden and does disclose the two most important traits: it mutates the target's state and cannot be undone. It omits prerequisites that matter a lot here — e.g. that the bot must be an admin/owner and cannot kick the owner — so the destructive profile is only partly covered.

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, zero filler, with the action stated first and the destructive consequence second. Nothing to trim and nothing buried.

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 mutation tool with no annotations and no output schema, the description covers the action and its irreversibility but leaves out permission prerequisites and side effects (e.g. whether the user can re-join, which partly overlaps with reject_add_request). Adequate but not 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 all three parameters are already documented in the schema (including the useful hint to source group_id from get_group_list). The description adds no parameter-level meaning beyond that, 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?

States a specific verb and resource — '把成员踢出群' (kick a member out of the group) — which is unambiguous on its own. It does not, however, distinguish itself from the nearby sibling set_group_ban, which is also a member-level punitive action; the agent gets no cue about which one to pick.

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 offers no when-to-use / when-not-to-use guidance and names no alternative. For a tool sitting next to set_group_ban, set_group_leave, and set_group_admin, the absence of routing guidance is a real gap, though the 'irreversible' note implicitly warns that this is the permanent option.

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?

With no annotations, the description carries the full burden. It does disclose two useful traits: the call mutates group state, and the exit is not trivially free because the bot must rejoin afterwards. It omits permission requirements, what happens if the bot is the sole owner, and whether the call succeeds silently — real gaps for an unannotated mutation.

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 with the action front-loaded and the consequence immediately after. '会改变群的状态' is mildly redundant for a set_* mutation tool, keeping it from a full 5, but nothing is padded or repetitive.

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 flat single-parameter tool with no output schema, the description supplies the essentials: what it does, that it mutates state, and that the change is costly to reverse. Missing permission/edge-case behavior (e.g. owner leaving) is a minor gap given the tool's low complexity.

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?

Only one parameter, and schema description coverage is 100% — the schema already says group_id is the target and instructs the agent to source it from get_group_list rather than memory. The description adds nothing about the parameter, so the baseline 3 for high schema coverage is correct.

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 verb+resource: '退出指定群' (leave the specified group), which is immediately distinguishable from the mutating siblings like set_group_kick (removing someone else) or set_group_ban. It is clear but does not explicitly name an alternative for contrast, so it stops just short of 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?

Usage is only implied by the verb itself — an agent infers this is the tool to call when the bot should leave a group. There is no statement of when NOT to use it, no prerequisites (e.g. membership/owner status), and no routing to a sibling such as set_group_kick. The '退了得重新加' clause hints at consequence but is not actionable 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，描述需承担全部行为披露责任。它说明了操作会改变整个群的状态且所有人可见，这是有价值的副作用提示；但未说明所需权限、是否可逆、调用后的响应或错误情况，披露不够完整。

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?

这是一个无 annotations、无 output 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%，group_id 和 group_name 的语义已在 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?

明确使用了具体动词「改」和资源「群名」，与同级工具如 set_group_card、set_group_admin 等能清晰区分。作用对象和操作类型一目了然。

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?

描述没有说明何时应使用本工具、何时应改用其他工具，也没有提及前置条件（如权限要求）。只有一句效果说明，缺少使用场景指引。

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?

No annotations are provided, so the description carries the full burden. It does disclose one behavioral trait beyond the schema: '会留下你的签到记录' tells the agent a persistent sign-in record is created. However, it omits idempotency/repeat-sign behavior, error conditions (e.g., already signed), and auth requirements, which matters for a mutation tool.

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 with zero filler, and the core action is front-loaded in the first sentence. The second sentence adds a side-effect note that 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 one-parameter, no-output-schema mutation, the description covers purpose and the notable side effect (a sign-in record is left behind). It is nearly complete; only repeat-sign behavior and failure modes are unaddressed.

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 schema already documents group_id thoroughly (including 'use get_group_list, don't fill from memory'). The description adds no additional parameter meaning, so the baseline 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?

States a specific verb+resource: check in / sign in (打卡签到) to a specified group. Among the sibling set, it is the only signing tool, so an agent can identify it without ambiguity. It stops short of explicitly contrasting with related set_group_* siblings, but the action itself is 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 implies the usage context (signing in to a group chat) but gives no explicit when-to-use/when-not guidance, prerequisites, or alternatives. For a single-purpose tool this is minimally adequate, but the agent must infer that this is a daily check-in style action rather than an arbitrary write.

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?

With no annotations, the description carries the full burden. It does disclose two useful behaviors: an empty string clears the title, and the change affects how the member is addressed in the group. However, it omits permission requirements, whether the change is visible/notified to the member, and error conditions for a mutation tool.

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 with no filler, leading with the action and the clearing rule. Nothing is buried or wasted.

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 3-parameter mutation with no annotations and no output schema, the description covers the core action and the clear-case but says nothing about permissions, side effects on other members, or failure modes. Adequate, but there are visible 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 all three parameters are already documented, including the empty-string-clears rule and the 18-char limit. The description's '空串清除' merely repeats the schema, adding no new parameter semantics; baseline 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?

States a specific verb (设置) plus resource (成员专属头衔) and the clear semantic (空串清除). It is identifiable, but it does not name or contrast with the nearby sibling set_group_card, which also changes how a member appears in a group, so sibling differentiation is incomplete.

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 when-to-use guidance, no mention of the alternative set_group_card, and no stated prerequisites (e.g. whether the caller must be owner/admin or whether the target must already be in the group). The agent must infer all of this.

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?

No annotations are provided, so the description carries the full burden. It does warn that the whole group's state changes, which is useful scope context, but it omits permission requirements, whether the change is reversible, and who is affected by existing muted members.

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, front-loaded sentences describing action and impact with zero filler. Nothing is redundant.

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 mutation with no output schema, the description is adequate but thin: it lacks auth/permission notes and any indication of the result of the operation, which unannotated mutation tools should supply.

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 are already documented in Chinese (enable defaults to true; group_id warns against guessing). The description adds nothing beyond the schema, so the baseline 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+resource: toggle the whole-group mute (开或关全员禁言). '全员' (all members) implicitly distinguishes it from the per-member sibling set_group_ban, but no sibling is named explicitly.

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?

Usage is implied by the tool's effect rather than stated. There is no guidance on when to prefer this over set_group_ban or set_group_admin, and no prerequisites (e.g. requiring bot admin rights) are mentioned.

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