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

With no annotations, the description carries the full burden. It discloses that this is a low-level passthrough with a default 30s timeout, but it does not state that safety and side effects depend entirely on the chosen action, nor does it describe auth requirements or error behavior for invalid actions. For a generic, potentially mutating passthrough, this is a moderate gap.

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?

Front-loaded: the identity of the tool comes first, then the when-to-use rule with examples. The trailing :param block duplicates the schema and is slightly redundant, but the overall size is appropriate and every core 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?

No output schema exists, but for a passthrough the return shape is action-dependent and arguably needn't be enumerated. The description covers role, usage condition, and parameters adequately; the main omission is how to discover valid action names, which a sibling provides.

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 action, params, and timeout are already documented. The description's :param lines largely restate the schema, and its examples overlap with the schema's examples, so baseline 3 applies — it adds little beyond the structured fields.

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: a 'universal low-level passthrough' that directly invokes any OneBot 11 standard or extended Action supported by NapCatQQ, covering 144+ features. It explicitly carves out its niche relative to the named siblings — the fallback for obscure actions those tools don't cover — so an agent can tell it apart without opening a 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?

Gives an explicit condition for use: when high-level named tools do not cover a specific obscure interface, with concrete examples (group album, group sign-in, fetch_ptt_text, send_group_ai_record, clean_cache). It does not name a discovery sibling such as list_supported_napcat_actions for finding valid action names, so guidance is clear but not exhaustive.

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 succeeds in disclosing what is inspected (environment, ports, accounts, remote version), which implies a non-destructive read, but it never explicitly states that it is read-only, that it makes a network call to GitHub, or how quickly it returns. Adequate 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?

Two sentences, front-loaded with the concrete checks and followed by the trigger condition. No filler, no repetition of the name, and each clause adds actionable 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 parameterless, annotation-free, output-schema-free tool, the description covers what is inspected and when to use it, which is most of the agent's decision path. It would be stronger if it hinted at the shape of the returned diagnostic (e.g., deployment/version verdicts) or that it may take longer due to the GitHub request.

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 and the schema description coverage is 100%, so there is nothing for the description to clarify on input semantics. The baseline for a parameterless tool 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 gives a specific verb ('检查' / check) plus a clearly enumerated resource set: local NapCatQQ runtime environment, service port status, saved account list, and a version comparison against the GitHub latest Release. The only gap is that it never distinguishes itself from close siblings like get_napcat_status or list_qq_accounts, which appear to overlap on the same subject matter.

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 an explicit trigger condition ('当不确定 NapCat 是否已部署、是否正在运行或是否有新版本可更新时'), giving the agent clear context for when to reach for it. However, it neither names alternatives nor gives a when-not-to-use boundary, so it stops short of full routing guidance among siblings such as get_napcat_status or deploy_or_update_napcat.

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, and it does disclose something meaningful: the buffer is local and in-memory, so this is not a server-side deletion and is likely transient. However it never states that the operation is destructive/irreversible, whether the cleared messages become unrecoverable or can be re-fetched from the server, or whether it requires an active login/session state.

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 short sentence with the scope qualifiers (本地内存 / 近期实时) front-loaded before the object. No filler, though its brevity contributes to the gaps noted elsewhere.

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, simple tool this covers the basics, but with no annotations and no output schema the description is the only source of behavioral context and it omits whether the clear is destructive, what state it affects, and how it interacts with get_recent_messages. 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?

The tool takes zero parameters, so the schema has nothing to describe and the description is not expected to compensate. Baseline 4 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 gives a specific verb (清空/clear) and a specific resource (本地内存中的近期实时消息缓存池 — the local in-memory recent real-time message buffer), so the agent can tell it is not a read like the sibling get_recent_messages. It stops short of explicitly naming that sibling or contrasting itself with it, so differentiation is inferable rather than stated.

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 sibling get_recent_messages or when a caller would want to clear the buffer rather than read it. The agent must guess the operational 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?

With no annotations, the description carries the full behavioral burden. It implies a destructive mutation (removing an essence marker) but discloses nothing about required permissions, reversibility, failure modes, or scope limits. Tagging it a "NapCat 扩展接口" is the only 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?

Very terse and front-loaded, but the trailing ":param message_id" line duplicates the schema description verbatim, adding no information. Efficient in size but slightly wasteful in 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 mutating single-parameter tool with no annotations and no output schema, the description omits permission requirements, group context, and failure behavior that an agent would need to invoke it safely.

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. The description merely restates the schema's own parameter text ("要移出精华的消息 ID") with no added format, range, or sourcing guidance, so it does not exceed 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?

States a specific verb and resource ("移出...群精华消息" = remove a group essence message), which is distinct from its natural siblings set_essence_msg (add) and get_essence_msg_list (read). It does not, however, explicitly name or contrast those siblings, so the agent must infer the distinction.

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 use this tool, no prerequisites (e.g. group-admin rights, whether the message must already be an essence message), and no mention of alternatives like set_essence_msg. Usage is only implied by the verb.

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. '删除' signals a destructive mutation, but the description never states that the deletion is likely irreversible, whether it removes the friendship bilaterally, what permissions/auth are needed, or what happens if the user_id is not a friend. For a destructive tool with zero annotation coverage this is a notable gap.

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 core purpose is front-loaded in one short sentence. The trailing ':param' docstring fragment is redundant with the schema but takes only a few words, so the description stays tight overall.

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 destructive, annotation-free, single-parameter mutation with no output schema, the description should disclose irreversibility, success/failure behavior, and auth requirements. None of that is present, leaving an agent unable to predict the consequences of calling it.

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 single parameter is already fully documented in the schema. The ':param user_id:' line merely restates the schema text verbatim, adding no format, range, or validation guidance (e.g., whether the QQ number must already be a friend). 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 ('删除指定 QQ 好友') and identifies the underlying OneBot 11 action, so the agent knows exactly what mutation occurs. It does not differentiate itself from neighboring destructive siblings such as delete_group_file or delete_msg, but the target resource (friend) 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?

There is no guidance on when to use this tool versus alternatives (e.g., set_friend_remark for editing rather than removing, or set_friend_add_request for handling requests). No prerequisites, no note about needing the friend to exist, and no mention of confirmation requirements for a destructive act.

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 discloses the mutation only through the verb '删除' and names the backend action, but says nothing about required permissions, whether deletion is reversible, what happens to the file after removal, or error conditions.

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 one-line purpose is front-loaded and clear, but the :param block duplicates information already present in the input schema, so those lines do not fully earn their place. Still compact and not bloated.

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 destructive mutation tool with no annotations and no output schema, the definition should explain permissions, irreversibility, and how to obtain a valid file_id. None of that is present, leaving the agent under-equipped beyond the raw parameter list.

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 :param lines merely restate the schema descriptions verbatim ('群号', '群文件 ID', '文件类型 busid，默认 102') without adding format, source, or valid-value guidance beyond 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?

States a specific verb+resource ('删除指定的 QQ 群文件' / delete the specified QQ group file) and identifies the underlying OneBot 11 action. It is distinguishable from the delete_group_folder sibling by name and object type, but the description never explicitly contrasts them.

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 delete_group_folder, get_group_root_files, or get_group_files_by_folder — an agent needing a file_id has no hint that it must first enumerate files. No prerequisites or constraints 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?

No annotations are provided, so the description carries the full burden for a clearly destructive operation. It does not state whether deletion is permanent, whether contained files are also removed, what permissions are needed, or what happens on a missing folder_id.

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 plus two parameter lines, front-loading the action and resource with no filler. The docstring-style ':param' formatting is mechanical but harmless.

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 destructive tool with no annotations and no output schema, the description should disclose irreversibility, permission needs, and side effects. None of that appears, leaving the agent unable to judge risk or outcomes.

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 as 群号 and 群文件夹 ID. The description only repeats those same two lines, adding no format examples or constraints, 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 (QQ 群文件夹), plus the underlying NapCat OneBot 11 action name, so the agent knows exactly what is removed. It is distinguishable from the sibling delete_group_file (file vs folder), though it never explicitly contrasts them.

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 versus delete_group_file or other folder operations, and no prerequisites (e.g. admin rights or folder being empty). 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 provided, so the description carries the full burden. It usefully discloses the authorization model (own messages, or group-admin recall of member messages), but omits key mutation traits such as irreversibility, the platform recall time limit, and error behavior on failure.

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 sentence is front-loaded and efficient, but the trailing ':param message_id: 目标消息 ID' line duplicates the schema verbatim and does not earn 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 destructive operation with no annotations and no output schema, the description covers purpose and permissions but leaves gaps around irreversibility and platform recall constraints that an agent would want before invoking.

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 single parameter is fully documented in the schema. The description merely repeats the identical param text (':param message_id: 目标消息 ID') and adds no syntax or meaning beyond it; 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 ('撤回指定消息') and maps to the underlying OneBot 11 API, so the agent knows it withdraws/recalls a message. The resource ('消息') is distinct enough from sibling deleters like delete_friend and delete_group_file, though 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?

The description gives the permission condition ('可撤回自己发出的消息，或作为群管理员撤回群成员消息'), which is genuine when-to-use context. However it does not name alternatives (e.g., delete_essence_msg) or state exclusions, so the routing guidance is 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?

With no annotations, the description carries the full burden and does well: it discloses the two-phase confirmation gate, that confirmed=False is preview-only and confirmed=True actually downloads/extracts, and that sources are either a GitHub Release or a local offline package. It omits failure behavior, permissions, and side effects on an existing installation.

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 core purpose and the safety rule are front-loaded, with the warning marker drawing attention to the confirmation protocol. It is somewhat redundant because the :param block duplicates schema descriptions, but nothing is confusing or 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 purpose, source options, and the execution gate well, and it hints at the preview return. It stops short of describing what the preview contains or what success/failure reporting looks like, which is the remaining 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 all four parameters. The description's :param block essentially restates the schema text (action, confirmed, use_local_zip_if_available, target_uin) without adding format, default, or interaction 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 compound verb (deploy/update) and resource (NapCat runtime environment), plus scope details: GitHub Release download or local offline zip extraction and OneBot port auto-configuration. This clearly separates it from start_napcat_service / restart_napcat_service / check_napcat_environment, though it never names a sibling 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 an explicit workflow: first call with confirmed=False to get a preview plan, present it to the user, then re-call with confirmed=True. That is real when-to-use guidance. It does not, however, clarify deploy vs update selection or when this tool is preferable to the adjacent environment/service management 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?

With no annotations provided, the description carries the full burden. It does disclose the destination (local cache directory) and the return value (local absolute path), which is meaningful behavior. However, it says nothing about permissions, size/rate limits, failure modes, or whether downloads overwrite cached files, leaving notable behavioral gaps.

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 leading purpose sentence is efficient and front-loaded, but the following ':param' block redundantly repeats information already present in the input schema, adding length without new meaning.

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 download tool with no output schema, the description minimally covers purpose, destination, and return value. It lacks detail on error behavior, caching semantics, and constraints, so it is adequate but leaves clear gaps an agent may need.

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 ':param' lines in the description simply restate the schema descriptions verbatim (url, thread_count default 3, headers format). Because the schema already documents all three parameters, the description adds no semantic value; 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 (下载/download) and resource (网络文件/network file) and states the destination (本地缓存目录) and return (本地绝对路径), which is concrete and actionable. It does not, however, explicitly differentiate itself from sibling file tools like upload_private_file/upload_group_file, so an agent must infer the distinction from the verb alone.

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 statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The phrase '下载网络文件到本地缓存目录' implies a context but never says when this is preferable to, e.g., get_group_file_url or other file utilities.

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 delivers little: it never states whether admin/bot permissions are required, whether results are paginated or capped, or what the response contains. Only the 'NapCat 扩展接口' note hints at the underlying implementation.

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?

It is short and front-loads the purpose. The trailing ':param group_id: 目标群号' is redundant with the schema, but the overall size is appropriate for a one-parameter read 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 no output schema and no annotations, the description should at minimum sketch the return value or access constraints; it does neither. For an agent deciding whether it can call this and what to expect back, the definition is 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% for the single required parameter, so the baseline is 3. The description merely repeats the schema text ('目标群号') without adding format or constraint detail (e.g., how to obtain a group_id, whether it must be one the account has joined).

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 ('获取指定 QQ 群的精华消息列表') and identifies the backing interface (NapCat extension: get_essence_msg_list). It is clearly a read of a group's pinned/essence messages, though it does not explicitly contrast itself with the sibling mutators set_essence_msg and delete_essence_msg.

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 versus the related siblings set_essence_msg or delete_essence_msg, nor any prerequisite such as needing to be a group admin. Usage is only inferable from the verb '获取'.

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 disclosure burden. It reveals that the return is a list of content nodes, but does not state that this is a read-only operation, whether the message_id must originate from an existing forward message, or any failure behavior for invalid IDs.

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?

Very short and front-loaded with the purpose. The trailing ':param message_id' line is a leaked docstring fragment that duplicates the schema, but the overall payload is compact.

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 read tool with no output schema, the description gives a rough sense of the return (a content node list) but omits behavioral context such as read-only nature and how the message_id is obtained. Adequate but with 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 the single parameter is already fully documented in the schema, and the description only restates it. The '(id / message_id)' alias hint adds minor value but no real semantics 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?

States a specific verb (get) and resource (the content nodes of a merged/combined forward message), and names the OneBot 11 action it maps to. It is clear what the tool retrieves, though it does not explicitly contrast itself with the related send_forward_msg or get_msg 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?

No when-to-use guidance is provided. The description does not say when an agent should call this instead of get_msg, or under what conditions a forward message is involved; the use case 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?

No annotations are provided, so the description carries the full burden. It does disclose that it targets the currently logged-in account and that no_cache forces a cache refresh, but it says nothing about permissions, response format, pagination, or whether the operation is read-only.

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 short and front-loads the core purpose, but the trailing ":param no_cache:" docstring fragment is a stylistic artifact that simply repeats the schema text, slightly diluting the structure.

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 usefully compensates by naming the fields returned (user_id, nickname, remark) and the target account scope. Missing only return-format/pagination details, which are minor for a simple list call.

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 no_cache parameter is documented identically in the schema and the description, so the description adds no meaning beyond the schema. 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 names a specific verb+resource: it fetches the complete friend list of the currently logged-in QQ account, and it enumerates returned fields (user_id, nickname, remark). It does not explicitly differentiate itself from the sibling get_friends_with_category, 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 and no reference to alternatives, even though the sibling get_friends_with_category returns a similar resource and would need disambiguation. The word "全部" (all) only weakly implies a contrast.

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 disclosure burden. It adds real behavioral context around the pagination cursor and the reverse_order flag, but says nothing about permissions, friend-relationship prerequisites, rate limits, or the shape of returned records.

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 is front-loaded in the first clause, which is good. But the four inline :param lines restate the schema descriptions almost verbatim, adding redundancy rather than new 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 paginated history tool with no output schema and no annotations, the description covers the cursor mechanics adequately but omits the return structure and any prerequisites, leaving an agent to infer how to interpret the fetched records.

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 defaults for count and reverse_order. The description's parameter notes largely duplicate the schema text, adding only the framing that message_seq is not the returned message_id.

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: fetching historical private-chat messages with a specified friend from NapCat. The 'friend' (私聊) scope implicitly separates it from the sibling get_group_msg_history, but it never explicitly names or contrasts any alternative, 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?

It explains how to paginate (fill message_seq with the oldest message_id from the previous page, set reverse_order=True to go older), which is genuine usage guidance. However, it gives no guidance on when this tool is preferable to siblings like get_recent_messages, get_msg, or get_group_msg_history.

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, and it does disclose one useful behavioral fact: this is a NapCat extended interface ('NapCat 扩展接口'), signaling it may not exist on every OneBot implementation. Beyond that it says nothing about read-only nature, return shape, or pagination, though for a zero-parameter read tool the omission cost is modest.

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 with no wasted text and the core purpose front-loaded. It is arguably under-specified rather than over-long, but structurally it is clean.

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?

No output schema exists, so the description would ideally hint at the return structure (categories containing friends), which it does not. For a simple no-arg read tool this is a gap but not a severe one, since the agent can invoke it without additional risk.

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, which is the baseline-4 case; there are no argument names or formats that the description could clarify or that it leaves ambiguous.

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: retrieving a friend list organized by friend categories ('按好友分组归类的好友列表'). The grouping qualifier implicitly distinguishes it from the sibling get_friend_list, but it never names that sibling explicitly, so the differentiation is left to inference.

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 and no mention of the obvious alternative get_friend_list. The agent must deduce from the word '分组归类' that this is the grouped variant rather than the flat list, but nothing in the text says when one should be chosen 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?

With no annotations, the description must carry the behavioral load. It conveys that this is a read query with a 'today' temporal scope, but says nothing about permissions, rate limits, or the shape of the returned count.

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 core purpose is front-loaded in one short sentence. The trailing ':param group_id: 群号' is redundant docstring residue but costs little.

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 read tool this covers the intent adequately, but with no output schema the description should explain the return value (e.g. a numeric count) and it does not, leaving a modest 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% and there is a single required parameter, so the schema already documents group_id fully. The ':param group_id: 群号' line merely repeats the schema and adds no new meaning, matching the baseline of 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?

States a specific verb (查询) and a precise resource (remaining @全体成员 count for a given group today), so the agent knows exactly what is retrieved. It does not explicitly name a sibling or contrast with one, but no sibling overlaps this resource, keeping it clearly distinguishable.

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, when-not-to-use, or alternative guidance. For a single-purpose read query the usage is largely implied, which lands at minimum-viable rather than misleading.

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 conveys only that this is a list operation; it says nothing about pagination, result caps, whether the folder_id must come from a prior call, or permission requirements for 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 is front-loaded in a single compact sentence. The trailing ':param' lines are redundant with the schema but cost little, so the overall definition stays short and scannable.

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 return values need not be explained, but with no annotations and a crowded sibling namespace (get_group_root_files, get_group_file_url, delete_group_folder) the description leaves the agent without enough to route correctly or anticipate results.

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 documented there, so the ':param' lines in the description merely restate '群号' and '文件夹 ID' without adding format, source, or constraint details. Baseline 3 applies when the schema does all the work.

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: retrieve the list of files and subfolders inside a designated folder of a QQ group. The phrase '指定文件夹内' (inside the specified folder) implicitly distinguishes it from get_group_root_files, but it never names that sibling, so an agent must infer the root-vs-folder distinction.

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, when-not-to-use, or prerequisite guidance. Nothing tells an agent when to pick this over get_group_root_files or get_group_file_system_info, which are the obvious alternatives in 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?

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral trait of a read-only info query by naming the returned metrics (total space, used space, file count limit), but says nothing about permissions, side effects, or rate limits.

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 is front-loaded, but the trailing ':param group_id: 群号' is a docstring artifact that duplicates the schema, and the parenthetical '(NapCat OneBot 11: get_group_file_system_info)' largely restates the tool name.

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-only info tool with no output schema, the description conveys what the call returns and requires nothing further to invoke correctly. Only a note on permissions or error cases would add value.

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% — group_id is already documented as '群号' in the schema. The description merely repeats this in the ':param group_id: 群号' line, adding no syntax or format 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?

States a specific verb+resource: retrieving the QQ group file system's space usage, and enumerates what that includes (total space, used space, file count limit). This clearly separates it from sibling listing tools like get_group_root_files, though it does not 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?

No guidance on when to call this versus alternatives such as get_group_root_files or get_group_files_by_folder. Usage is only inferable from the tool name and the described return content.

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 does convey that the result is an HTTP download URL, which is useful, but says nothing about permission requirements, whether the bot must be a group member, failure behavior for invalid file_id, or link expiry.

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 is front-loaded in the first line, which is good, but the trailing ':param' block merely restates the three parameters that the schema already documents, so those lines do not fully earn their place. Overall short and readable.

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 annotations and no output schema, the description is the only source of behavioral context. It correctly identifies the returned artifact (a download URL) and covers all parameters, but omits usage routing, permissions, and error/link-validity details that an agent would need to invoke it confidently.

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 each parameter carries its own description identical to the text in the description (group_id, file_id, busid with default 102). The description adds the default value, but that is already in the schema, so it adds little beyond the schema's own documentation. 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: '获取指定群文件的直接 HTTP 下载链接' (get the direct HTTP download link for a specified group file), and cites the underlying NapCat action. It implicitly distinguishes group files from the sibling get_private_file_url and from download_file, but 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?

There is no when-to-use or when-not-to-use guidance. It neither contrasts with get_private_file_url / download_file / get_group_root_files, nor states prerequisites such as needing the group/file identifiers obtained from a prior listing call.

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 entire behavioral burden. The verb '获取' weakly implies a read-only query, but there is no explicit statement about permissions, whether a bot must be a group member, rate limits, or what the response contains. The enumeration of honor types is behavioral-adjacent, but permissions/side-effect context is absent.

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, purpose front-loaded, no filler. Mild redundancy in restating the schema's honor_type enumeration, but nothing that wastes the agent's attention.

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?

No output schema, so the description ideally would hint at the return shape (ranking lists per honor type) and any access requirements. Both parameters and the honor-type taxonomy are fully covered, making it minimally adequate for a simple read tool, but return/permission context 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% and the description's param notes are a near-verbatim copy of the schema text for both group_id and honor_type (including the same enumerated values). Per the coverage rule this is the baseline 3 – no added 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?

States a specific verb and resource ('获取指定 QQ 群的群荣誉信息' – get honor info for a given QQ group) and identifies the underlying OneBot 11 action. It is unambiguous, though it never references any sibling tool, so the differentiation is left implicit (no sibling covers group honors anyway).

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?

Only implies usage by naming the resource; there is no statement of when to call this versus related tools such as get_group_info or get_group_member_info, nor any prerequisites (e.g. bot must be in the group). Pure 'what', no 'when'.

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, and it falls short. It implies a read but never states it is read-only, nor does it describe caching implications beyond the raw no_cache flag, permissions required, rate limits, or error behavior. The caching hint is a small plus but is redundant with 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 short and front-loads the purpose before the field list. It is somewhat padded by restating the two parameter descriptions verbatim from the schema, which adds no information, but the total size is appropriate.

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 tool with no output schema and no annotations, the description is minimally adequate: it names the concept and the returned fields but says nothing about response shape, caching semantics, or failure modes. Enough to call it, not enough to call it confidently.

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 group_id and no_cache with the same wording the description repeats. The description adds no syntax, format, or edge-case meaning (e.g., what no_cache=false returns when stale), 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 (获取指定 QQ 群的详细信息) and enumerates the returned fields (群名称、人数、群主、群备注), plus the underlying OneBot 11 action name. It is clearly a per-group detail lookup, though it never explicitly contrasts itself with close siblings like get_group_list or get_group_member_info, so the differentiation is left to inference.

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 versus the many sibling read tools (get_group_list, get_group_member_info, get_group_honor_info, etc.). The description only states what the tool does and the OneBot action it maps to; an agent gets no conditions for selection or exclusion.

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 discloses caching behavior via no_cache and lists the returned fields, but it does not discuss permissions, rate limits, or any other operational traits beyond that.

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 core list description is front-loaded and efficient, but the appended ':param no_cache' line redundantly repeats schema content. It is still compact overall, with minor structural awkwardness rather than bloat.

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 list operation with one fully documented parameter and no output schema, the description is largely sufficient: it names the resource, returned fields, and caching behavior. The main gap is the absence of explicit usage routing, but nothing critical is missing for 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 description coverage is 100%, so the single parameter is already fully documented. The description repeats the no_cache explanation but adds no syntax, constraints, or meaning beyond what the schema provides, 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 uses a specific verb and resource: it retrieves the full list of QQ groups the current account has joined, and it names returned fields and the OneBot 11 action. It clearly separates itself from single-group siblings like get_group_info, but it does not explicitly name any alternative, so it falls just short of full sibling 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?

Usage is implied by the phrase 'all QQ groups the current account has joined,' which tells an agent when this tool is relevant. However, there is no explicit when-to-use/when-not-to-use guidance and no named alternative for cases where a single group or another listing is needed.

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 usefully discloses the return fields and the no_cache refresh behavior, but does not state that this is a read-only, side-effect-free operation nor any permission/rate constraints. Partial disclosure above the (absent) annotation baseline.

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?

Front-loads purpose and return fields before the parameter block, which is good ordering. However, the trailing :param lines simply duplicate what the schema already documents, adding mild redundancy without new 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?

With no output schema and no annotations, the enumerated return fields provide genuinely needed context about what the call yields. The three params are all accounted for; only permission/environment prerequisites are absent, which keeps it from a 5.

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 every param (group_id, user_id, no_cache) already carries its own description identical to the docstring. The description adds no syntax or format 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?

States a specific verb+resource (get group member info for a specified member) and even enumerates the returned fields (card, nickname, role, join time, last-speak time, title), which implicitly separates it from list-oriented siblings like get_group_member_list. It stops short of naming an alternative tool directly, but the scope of 'specified member' 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?

There is no when-to-use/when-not guidance and no prerequisites (e.g., that the bot must be in the group). The contrast with get_group_member_list or get_stranger_info is left entirely to inference, so the agent must guess the correct sibling 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?

No annotations are provided, so the description carries the full burden. It implies a read operation, but never states whether the bot must be a group member/admin, whether there are rate limits for large groups, how the response is paginated or ordered, or what no_cache actually costs (a forced refresh re-querying the server). For a tool whose result can be large and whose cache flag has real side-effect cost, these omissions matter.

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 short purpose sentence followed by two param lines — appropriately sized and front-loaded, with no filler. It loses a point only because the param lines restate the schema rather than earning their 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 two-parameter read tool with full schema coverage and no output schema, the definition is minimally adequate — the agent knows what it returns (a member list). However, with no annotations and no output schema, nothing describes the structure of returned members or the behavioral cost of no_cache, leaving a real 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%, and the description's param lines ('群号', '是否强制刷新缓存') are verbatim duplicates of the schema descriptions, adding no meaning beyond it. The baseline of 3 applies when the schema already documents all 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 states a specific verb and resource in Chinese: fetching the full member list of a specified QQ group, with the OneBot 11 action name as a reference. This is clear, but it does not differentiate itself from the nearby sibling get_group_member_info, which retrieves a single member — the agent must infer the distinction from the tool names alone.

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_member_info or get_group_honor_info, nor any stated prerequisites (e.g. bot must be in the group) or exclusions. Usage must be inferred 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?

With no annotations, the description carries the full behavioral burden. It does disclose meaningful behavior: default count of 20, that omitting message_seq returns the newest records, and that reverse_order changes paging direction. It omits read-only/safety framing and any rate-limit or permission context, so it is partial but not misleading.

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?

Front-loads purpose followed by cursor/paging semantics, which is the right order. Slightly padded by restating parameters already documented verbatim in the schema, and the trailing mixed-language sentence about True/False is a bit awkward.

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?

No output schema exists, yet for a read-only history fetch the description covers the essentials an agent needs: group target, page size, cursor semantics, and paging direction. Return shape and message ordering when paging are left unstated, but nothing critical to invoking it correctly 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 coverage is 100%, so the baseline is 3, but the description actually resolves a genuine trap: message_seq must be the earlier page's message_id, not the returned record's message_seq field. That is real semantic value beyond the schema text for a paging cursor.

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 concrete verb+resource (获取指定群聊的历史聊天记录) and names the backing action (NapCat OneBot 11: get_group_msg_history). Scoping to 群聊 implicitly separates it from get_friend_msg_history, 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?

Implied when-to-use: fetching history of a specific group. It adds useful pagination guidance (reverse_order=True 向更旧的记录翻页, message_seq as cursor, default = latest), which is effectively usage guidance for this tool. However, it never says when to prefer this over get_recent_messages, get_recent_contact, or get_msg.

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. '获取' implies a read-only listing, but the description says nothing about return format, pagination, item counts, or permission requirements, which matters for a folder/file listing.

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 is front-loaded, but the trailing ':param group_id: 群号' is pure duplication of the schema field and the parenthetical '(NapCat OneBot 11: ...)' is an implementation reference rather than agent-useful context. Adequately sized but with redundant 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 one-parameter read tool with no output schema and no annotations, the description covers what it does but omits the shape of the result (file/folder entries) and any behavioral caveats. It is minimally adequate but not complete given the absence of structured fields.

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% for the single group_id parameter, so the schema fully documents it. The description merely repeats ':param group_id: 群号', adding no format or semantic meaning beyond the schema. 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 (获取/get) and resource (QQ 群文件根目录下的所有文件与文件夹列表), with the 'root directory' scope distinguishing it implicitly from the sibling get_group_files_by_folder. It does not explicitly name the sibling, but the resource and scope 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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The word '根目录' (root directory) weakly implies it contrasts with get_group_files_by_folder, but this is inference, not stated 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 of behavioral disclosure. It mentions that results are 'current' and that this is a NapCat extension interface, but does not state read-only safety, required permissions, rate limits, or return format, leaving meaningful behavioral gaps.

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 short and front-loads the purpose. The trailing ':param group_id: 群号' is redundant with the schema, but overall the text remains compact and readable.

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 read tool with no output schema or annotations, the description covers the essential call information. However, it does not describe the return shape or fields, which would help an agent understand what comes back given the lack of an 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 description coverage is 100%, and the single parameter group_id is fully documented in the schema as '群号'. The description merely repeats that same label, adding no extra 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 states a specific verb and resource: retrieving the list of currently muted members in a given group chat. It clearly distinguishes this from general member listing siblings like get_group_member_list by specifying the '被禁言状态' filter.

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 the tool by describing its output, but gives no explicit when-to-use vs alternatives or any exclusions. For a simple read query this is adequate but leaves routing to inference.

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, and it does not say whether the call is read-only, whether fetching consumes/acknowledges the messages, whether results are paginated or bounded, or what shape the response takes. For a queue-like notification feed those behaviors matter.

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 with the resource first and the parenthetical examples immediately after; the OneBot 11 API reference is appended compactly. No padding, though it is a little thin for the amount of behavior left unstated.

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-parameter read tool with no output schema, the description covers what kind of records come back, which is the minimum an agent needs. It omits the safety profile, result bounding/pagination, and any hint about how the returned system messages relate to the approval siblings, 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?

The tool takes zero parameters and the schema declares an empty object, so there is no parameter semantics for the description to add. Baseline 4 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 (获取群系统消息列表) and enumerates the content types covered (pending join approvals, group-invite notices), which lets an agent tell it apart from generic history tools like get_group_msg_history. It does not name any sibling explicitly, so it stops short of full 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?

Usage is only implied: the mention of '待审批的入群申请' suggests this is the read step before acting via set_group_add_request, but there is no explicit when-to-use statement, no exclusion, and no disambiguation against the closely related sibling get_recent_notices_and_requests.

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 burden. It does disclose the return fields (user_id, nickname), which is real behavioral value since there is no output schema, but it says nothing about failure modes (e.g. not logged in) or permissions. Adequate for a zero-parameter read, but 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?

A single front-loaded sentence with the return fields called out early. The trailing parenthetical endpoint reference is mildly redundant but short and informative.

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, the description compensates by naming the returned fields, and it maps to the OneBot 11 API for traceability. Only the error/not-logged-in case is left unspecified, which is a minor gap for this simple read.

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 per the baseline a 4 applies. There is nothing for the description to clarify beyond confirming no input 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 resource ('获取当前登录的 QQ 账号信息') and even names the underlying OneBot 11 endpoint. The word '当前' (current) implicitly distinguishes it from list_qq_accounts, 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?

No when-to-use or when-not-to-use guidance, and no alternatives are mentioned. The agent must infer on its own that this is the single-account read vs. list_qq_accounts or get_napcat_status.

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 that the image viewer opens only if the file exists and that the action is optional, which is useful behavioral context. However, it omits key details such as the return shape (e.g., a path string or error message), permission requirements, and what happens when the file is missing.

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-loads the core action before mentioning the optional parameter. The trailing ':param open_image' line is somewhat redundant given the schema, but overall it is appropriately sized with no wasted prose.

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 one-parameter tool with no output schema, the description covers the basic operation but leaves gaps around the return value and error behavior when the QR file is absent. It is minimally adequate but not complete enough to let an agent call it with full confidence.

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 single parameter is fully documented in the schema. The description repeats the same parameter explanation with no additional meaning, format details, or examples. Baseline 3 is appropriate when the schema already 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 states a specific verb and resource: it retrieves the local latest NapCat login QR code image path and optionally opens it on screen. It clearly distinguishes the tool's immediate scope (viewing a local file), but does not explicitly differentiate itself from sibling tools like login_new_qq_by_qrcode or get_login_info, which could be confused with it.

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 says what the tool does but gives no guidance on when to use it versus alternatives such as login_new_qq_by_qrcode or get_login_info. There are no prerequisites or exclusions stated, 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?

No annotations are provided, so the description carries the full behavioral burden. It hints at return content (sender, time, raw segments) but says nothing about failure modes when the message_id is invalid, permission scope, or whether this only works for recent messages, which matters for a single-message fetch.

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 main sentence is efficient and front-loaded, but the trailing ':param message_id: 目标消息 ID' line is pure duplication of the schema and adds no value, slightly cluttering the definition.

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 annotations and no output schema, the description does useful work by naming the returned fields. However, for a message-fetch tool it omits error handling and scope constraints, leaving the definition only minimally 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 a single, self-documented parameter. The description merely restates the schema ('目标消息 ID') without adding format, range, or example guidance, 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 (获取/get) and resource (单条消息/single message) and enumerates what it returns: sender, send time, raw message segments. This is clearly distinct from siblings like get_forward_msg or get_group_msg_history, though it doesn't explicitly name those alternatives.

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 and no alternatives referenced. It doesn't say how this differs from get_group_msg_history, get_recent_messages, or get_forward_msg, leaving the agent to infer selection from tool names 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 disclosure burden. The 'get' framing implies a safe read, and noting it wraps two API calls adds useful context about scope, but it says nothing about behavior when the service is down, latency, or what fields the status payload contains.

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 with the core purpose front-loaded and the composition detail in parentheses. Nothing is wasted, though the parenthetical implementation note is secondary 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 zero-parameter read-only status tool, the description adequately covers scope (running status + version) and implementation. It is slightly thin on return-value expectations, but the purpose statement itself indicates what the agent will get back.

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 of 4 applies. There is no parameter information needed and nothing in the description misrepresents the input contract.

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 (获取 NapCat OneBot 11 协议端运行状态与版本信息) and discloses that it is a composite of get_status and get_version_info. It is clear what the tool returns, but it does not explicitly differentiate itself from the neighboring check_napcat_environment 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?

Usage is implied by the nature of a status/version query, so an agent can infer it is a health-check tool. However, there is no explicit statement of when to prefer this over check_napcat_environment, start_napcat_service, or the underlying get_status/get_version_info calls.

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 usefully discloses that the return may be either a direct download URL or a local cache path, but it omits prerequisites, authentication needs, caching behavior, and whether the operation has 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?

The description is short and front-loads the core behavior. The trailing :param line is redundant with the schema, but overall it is not bloated.

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 one-parameter read, the description states the purpose and somewhat describes the return. However, it lacks usage routing against related file tools and provides no annotation or output schema context, leaving gaps for correct selection.

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 single file_id parameter is already documented in the schema. The description repeats the same meaning without adding format, constraints, or examples.

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: obtains a direct download link or local cache path for a private-chat file. The private-file scope is clear and implicitly distinguishes it from the group-file sibling, but it does not explicitly name that 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?

There is no guidance on when to use this tool versus get_group_file_url, upload_private_file, download_file, or other file-related siblings. The 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?

With no annotations, the description must carry the full behavioral burden. It does convey that this is a read operation and that results include message summaries, but it says nothing about ordering, freshness, whether results come from a buffer (a clear_recent_messages_buffer sibling exists), or any auth/rate-limit constraints.

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?

Front-loaded with the purpose and appropriately short for a one-parameter read tool. The trailing ':param count:' docstring-style line is slightly awkward leakage but adds no bloat.

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?

No output schema exists, so the description should explain the return shape; it partially does by naming the categories of data returned (friends, groups, message summaries). It still omits list structure, ordering, and error/empty cases, leaving meaningful gaps for a tool with no output schema and no annotations.

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 'count' parameter is fully documented in the schema; the description merely restates '返回的最近会话数量，默认 20'. Baseline 3 applies since the schema already does the work and no additional semantics (e.g. max value, ordering effect) are 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?

States a concrete verb+resource pair ('获取...最近联系列表 / 最近会话列表') and even enumerates what the list contains (recent friends, groups, latest message summaries). It does not, however, differentiate itself from similar siblings such as get_recent_messages or get_friend_list, so an agent must infer the boundary.

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 or when-not-to-use guidance is given. The description never mentions the closely related get_recent_messages or get_recent_notices_and_requests, nor any prerequisite (e.g. being logged in), so the agent gets no routing signal beyond 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?

With no annotations, the description carries full burden and does disclose a meaningful trait: the data is a cached, real-time-monitored buffer rather than a server-side history pull, which implies freshness and retention limits. It does not state that this is a read-only operation, how large/old the cache is, or how it relates to clear_recent_messages_buffer, so key behavioral context is missing.

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 opening sentences are front-loaded and describe the data source before the parameter list, which reads cleanly. However, the five ':param' lines duplicate already-complete schema descriptions, so a substantial portion of the text does not earn 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 5-parameter read tool with no output schema and no annotations, the description covers the data source and all filters but omits the shape of returned messages, any cache-size or recency bound, and the relationship to clear_recent_messages_buffer. 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 coverage is 100% and the ':param' lines restate the schema descriptions verbatim, adding no syntax, format, or interaction detail beyond them. Baseline 3 applies since the schema already does all the work.

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 ('获取...缓存的近期 QQ 消息列表') and adds real scope: messages are captured live via WebSocket and cached by the MCP backend. That scope implicitly separates it from the history siblings get_friend_msg_history/get_group_msg_history, but it never names an alternative, 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?

It states what can be filtered (私聊/群聊, target QQ/群, keyword) which implies retrieval scenarios, but gives no explicit when-to-use or when-not-to-use guidance and never contrasts itself with get_friend_msg_history, get_group_msg_history, or get_recent_contact. Usage must be inferred from the filter 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?

With no annotations, the description carries the full burden and does disclose behavior: events are captured in real-time by the backend, and the response includes a flag field enabling downstream approval. It leaves rate limits and exact return shape unstated, but the approval-path behavior is genuinely useful.

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?

Purpose and the flag/approval workflow are front-loaded in two efficient sentences. The embedded ':param count:' fragment is a minor redundant artifact that duplicates the schema, but overall the text is tight.

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, the description does the necessary work of naming the categories of returned events and singling out the flag field used for approval. It is largely complete, though it could say more about how notices vs. requests are combined in the response.

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 single count parameter is already fully documented. The description merely repeats 'count = max results, default 20' from the schema, adding no syntax or edge-case detail beyond it.

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 (get recent group notification events and friend/group add requests) and enumerates concrete event types (file upload, recall, mute, member changes). An agent can distinguish this from siblings like get_group_system_msg or the set_*_add_request tools without opening 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?

Explicitly connects the tool to its follow-up workflow: the returned flag can be passed directly to set_friend_add_request or set_group_add_request for approval. This tells the agent when the output is meant to be used, but it doesn't state exclusions or contrast with other retrieval 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?

With no annotations, the description carries full behavioral burden. It does disclose the output content (nickname, gender, age, level, signature) in the absence of an output schema, which is useful, but says nothing about permissions, rate limits, or error behavior. The no_cache parameter is schema-documented rather than explained further here.

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?

Purpose is front-loaded in a single clear sentence, followed by a compact param recap. Slightly redundant to repeat parameters already in the schema, but overall efficient 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 two-parameter read tool with no output schema, the description compensates by listing the returned profile fields, which is exactly what the missing output schema would otherwise require. Required parameter and optional cache flag are both covered.

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 in the schema, and the description merely restates them (':' param user_id' 目标 QQ 号, no_cache 是否不使用缓存). Baseline 3 applies when 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?

States a specific verb (获取) and resource (指定 QQ 用户的公开个人资料) and even enumerates the returned fields (昵称、性别、年龄、等级、个性签名等). It scopes to 好友或陌生人, which implicitly separates it from group-scoped siblings like get_group_member_info, but it never names an alternative to sharpen the distinction.

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 guidance, no exclusions, and no alternative tool named. The '好友或陌生人' phrasing hints at broad applicability but does not tell the agent when to pick this over get_friend_list or get_group_member_info.

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 and does disclose the data source (local sandbox, saved credentials) and the returned information categories (saved accounts, default active account, online account). It remains implicit that this is a read-only operation (via 查看) and adds no detail on pagination, ordering, or failure modes when no accounts exist.

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 compact sentences with no filler; the enumerations of what the list contains come first and the follow-up switch hint is placed last. 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?

There is no output schema, so the description must convey return content, and it does describe the three categories of account information returned. It is largely complete for a simple list tool, though it does not state whether the result is paginated or what happens when no credentials exist.

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 baseline for a parameterless tool is 4. No argument syntax or options need describing.

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 (查看/list) and resource (QQ 账号 with saved login credentials), and further specifies exactly what is enumerated: the saved-credential account list, the current default active account, and the currently online account. This clearly separates it from siblings like get_login_info, which reports the single logged-in identity.

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 second sentence routes the agent to the sibling tool switch_qq_account and explains the condition (listed accounts can be switched online without re-scanning a QR code). This gives usable context for follow-up actions, but there are no explicit exclusions or when-not-to-use guidance relative to other account tools such as login_new_qq_by_qrcode.

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 burden. It discloses the scale (140+ actions) and that the result is an Action-name directory, implying a read-only lookup, but does not state explicitly that it is side-effect free, whether it hits the network, or how results are grouped/ordered.

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 sentence is front-loaded and efficient, but the trailing ':param category:' line is a leaked docstring artifact that merely duplicates the schema and adds visual noise. Roughly a third of the text 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 single-optional-parameter catalog tool with no output schema, the description is nearly complete: it explains the purpose, the lookup workflow, and the filtering dimension. It could say more about the shape of the returned directory (names only vs. names plus descriptions), which is the one remaining 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 already 100%, so the category parameter and all six allowed values are fully documented in the schema. The description repeats the same category list verbatim rather than adding meaning (e.g., what counts as 'ai_and_system'), so baseline 3 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 and resource (list of all 140+ underlying Action names supported by the NapCatQQ engine) and gives the reason it exists: to look up exact interface names. It is clearly distinguished from the sibling call_napcat_api, which it feeds into.

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?

Explicitly says to consult it before using call_napcat_api to find the precise interface name, which names the sibling and the triggering condition. It lacks a negative case (when this lookup is unnecessary), so it falls just short of a 5.

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 delivers: it discloses destructive side effects (stops the running NapCat process and clears the auto-login config), the artifacts produced (qrcode.png on screen), the waiting semantics (blocks until scan or timeout), and the end state (auto-generates OneBot 11 config on ports 3000/3001 and switches to background daemon mode). This is a genuinely informative behavioral contract.

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 usage condition are front-loaded, followed by a clean numbered flow that earns its space. The trailing restatement of the two parameters is redundant given 100% schema coverage, which keeps it from a 5.

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-annotation, no-output-schema, 2-parameter orchestration tool, the description explains the full lifecycle from process teardown to re-launch, which is what an agent needs to decide and act. It omits failure behavior (what the caller gets if the user never scans) and mention that the sandbox/temp config is cleaned up, leaving a small 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?

Both parameters are documented at 100% schema coverage, so the schema already does the work. The description restates the same open_image and wait_scan_seconds text verbatim, adding no new format, units, or interaction semantics (e.g. what happens on timeout). 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 action and resource (启动新 QQ 账号扫码登录流程) and even states the two triggering conditions (binding a new QQ number, or re-scanning when old credentials expire). It does not explicitly distinguish itself from the closely related sibling get_login_qrcode_image or switch_qq_account, which is why 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?

It gives an explicit when-to-use clause: '绑定新 QQ 号或当旧账号凭证过期需要重新扫码时使用'. However, it never names alternatives (e.g. get_login_qrcode_image, switch_qq_account) or states when NOT to use it, so the agent must infer the boundary from sibling names 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the NapCat extension API mapping and the three operational modes, but says nothing about permissions required, whether the read state is reversible, or what happens when multiple parameters 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?

Purpose is front-loaded in a single clear sentence, followed by terse per-parameter notes. The param lines duplicate schema content, which is slightly wasteful, but overall it is compact and easy to scan.

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 mutation tool with no annotations and no output schema, the description explains what each parameter targets but omits behavioral essentials: parameter mutual exclusivity/precedence, permission requirements, and any indication of success/failure behavior. 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%, so the schema already documents all three parameters. The description's :param lines merely repeat the schema descriptions verbatim, adding no extra syntax, interaction, or defaulting information, 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+resource ('将...标记为已读' = mark ... as read) and covers all three target scopes: a single message, a private chat, or a group chat. It also names the underlying NapCat API variants, making it unambiguous which sibling tool performs this 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?

The param annotations imply which mode to select (message_id vs user_id vs group_id), giving implied usage guidance, but there is no explicit when-to-use/when-not-to-use statement and no reference to alternatives such as delete_msg or get_msg. Guidance 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, the description carries the full burden, and it partially meets it by naming the underlying engine (QQ built-in OCR) and API action, which hints at a runtime dependency on NapCat. However, it says nothing about whether the image is mutated or read-only, what the returned text format looks like, size limits, or failure modes for unsupported formats.

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 compact lines with the purpose front-loaded and no wasted prose. The ':param image' line restates the schema verbatim, which is mild redundancy but not harmful.

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-output-schema tool this is nearly sufficient, but it omits any hint of the return shape (recognized text string), which is the primary thing a caller needs to know. Bilingual framing (Chinese description with the OneBot action name) is helpful 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 repeats the schema's parameter text verbatim ('图片文件 ID、本地绝对路径或 HTTP URL') without adding syntax, precedence, or constraints. It does not compensate for or extend 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?

States a specific verb and resource: OCR-based recognition of text in an image using the QQ built-in engine, plus the underlying NapCat OneBot action name. No sibling tool overlaps this function, so differentiation is not a real concern. Clear and 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?

No when-to-use or when-not-to-use guidance is given; it only implies usage by describing the mechanism. There are no alternatives named and no conditions for selecting this tool over, say, a generic file-download or msg tool. The agent must infer that this is the tool for extracting text from an image.

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 hints at forcefulness (强制) and explains that the tool waits for the port to be listening, but says nothing about permissions, whether active sessions/QQ logins are dropped, reversibility, or side effects on running state.

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 core sentence is efficient and front-loaded, but the :param lines duplicate content already present in the input schema, adding length without new 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?

The action and both parameters are covered, but for a service-restart tool with no annotations and no output schema, the description omits enough — consequences of the forced restart, prerequisites, expected result — that it is only minimally 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?

Schema description coverage is 100% and the description merely repeats the two parameter docs verbatim rather than adding syntax or behavioral detail. Baseline 3 is correct when the schema fully documents 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?

The description names a specific verb+resource: forcibly restart the local NapCat background service process, with the optional scope of a target QQ account. The action is inherently distinguishable from the start_napcat_service/stop_napcat_service siblings, though 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?

No when-to-use guidance is given, and no alternatives are mentioned. With start_napcat_service, stop_napcat_service and get_napcat_status present in the sibling set, an agent gets no help deciding between a restart and a stop-then-start sequence.

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, yet it says nothing about required permissions, rate limits, failure behavior, or what the call returns. The node-format example is invocation detail rather than behavioral disclosure, so this is a significant gap 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?

Front-loads the purpose, then the critical node format, then params. It is well-sized, though the trailing :param lines largely repeat the schema descriptions and add little.

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 annotations and no output schema, the description covers purpose and the key payload format, which is the minimum viable for a 2-param send tool. It omits success/failure semantics and any return info an agent might need.

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 by giving a concrete node example showing the required {type, data{name, uin, content}} structure that the schema's bare 'list of node dicts' does not convey.

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 ('向指定群聊发送合并转发消息') plus the underlying NapCat action name, so an agent can tell it apart from send_group_msg or send_private_forward_msg by name. It does not explicitly name those siblings as alternatives, 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 / when-not-to-use guidance and no mention of the sibling tools (send_group_msg, send_private_forward_msg, get_forward_msg) that could be confused with it. Usage is only inferable from the tool name itself.

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 genuinely useful behavioral caveat — that a plain-text @全体成员 will not produce a real mention — and explains auto_escape's CQ-parsing effect. However, it says nothing about permission requirements, rate limits, failure modes, or what the call returns on success.

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?

Purpose is front-loaded in the first sentence, followed by the supported content formats and the @全体成员 caveat, then per-parameter notes. Efficient overall, though the trailing :param lines duplicate schema wording and add little.

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 definition should at least hint at success/failure behavior or required preconditions. It covers message format well but leaves the safety and response profile entirely undocumented.

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 three parameters and the baseline is 3. The description largely repeats the same parameter text verbatim, adding only the clarification that message may be CQ code or an OneBot message-segment array, which is a marginal gain over the schema's anyOf string/array typing.

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 ('向指定 QQ 群发送群聊消息') plus the underlying OneBot action name send_group_msg, so its function is unmistakable. It does not explicitly name sibling alternatives such as send_private_msg or send_msg, so the agent must infer the group-vs-private routing from the name alone.

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 scope (target a QQ group), but there is no explicit statement of when to prefer this over send_msg or send_group_forward_msg, nor any prerequisite such as the target group requiring membership or the bot being online.

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 times range and default, but says nothing about whether the target must be a friend, whether likes are idempotent or rate-limited, or what happens on an invalid/unknown QQ number.

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 first sentence is front-loaded and efficient, but the two ':param' lines are pure duplication of the schema and earn no place in the description. Nothing is actively misleading, just 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 action with no output schema, the description covers the essentials, but with no annotations and no return documentation it leaves the agent guessing about prerequisites (friend status) and failure behavior.

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 two params are already fully documented in the schema; the description's ':param' lines restate the schema verbatim rather than adding format or constraint detail. Baseline 3 applies when the schema does all the work.

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: liking a designated friend's profile card (OneBot 11: send_like). The action is unambiguous and distinguishable from near neighbors like send_poke or set_msg_emoji_like, though no sibling is named.

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 case for when not to use it, and no alternatives named. The only usage cue is the implicit '(1~10, default 10)' constraint on the repeat count.

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 documents parameter meanings but discloses nothing about failure modes, whether login/connection state is required, rate limits, or return behavior — significant gaps for a mutation tool with zero annotation coverage.

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 sentence is stated first, which is good, but the trailing :param: block duplicates the input schema field-for-field and consumes most of the text. Roughly half the content earns little beyond what structured fields already convey.

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?

Parameters are fully covered, but with no annotations and no output schema the description should still say something about the result of a send or the conditions under which it fails. For a simple 4-param write tool it is 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%, and the :param: block repeats the schema descriptions for message_type, target_id, message, and auto_escape almost verbatim. It confirms required/conditional semantics (target_id meaning flips with message_type) but adds no format or syntax detail beyond 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?

The description states a specific verb+resource ('通用消息发送接口', send_msg) and explains it routes to private or group delivery based on message_type. It is clear, but it never distinguishes itself from the obvious siblings send_private_msg and send_group_msg, which an agent must choose between.

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: the tool is a generic interface that picks private vs group via message_type. There is no explicit guidance on when to use this over the specialized send_private_msg / send_group_msg siblings, so the agent must infer the tradeoff.

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. Beyond restating the group/private branch, it says nothing about permissions, whether the target must be a friend or group member, rate limits, or what happens on failure, which is a real gap for a mutating interaction call.

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 scope statement is front-loaded in the first two sentences and the rest is a compact parameter recap. It is appropriately short, though the param lines duplicate the schema verbatim and thus do not fully earn their space.

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?

Wait — for a simple two-parameter interaction tool with a 100%-covered schema and no output schema, the description covers the essential branch and required parameter. It omits failure/permission behavior, but nothing structurally required to call it correctly 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% and both properties are documented identically in the schema, so the description adds no meaning beyond it. Per the baseline for high coverage, a 3 is appropriate; no format, constraint, or edge-case detail is supplied.

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 ('发送戳一戳互动提醒') and identifies it as a NapCat extension API, so the agent knows exactly what action fires. It does not, however, distinguish this tool from adjacent interaction siblings such as send_like or set_msg_emoji_like, leaving the agent to infer the difference.

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 one conditional routing rule: supply group_id for a group poke, omit it for a private poke. That is implied usage rather than explicit guidance about when to prefer poke over other interaction tools, and there are no stated prerequisites such as friendship or group membership.

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 exist, so the description bears the full disclosure burden. It does add real value by specifying the required node-object shape, but it says nothing about what the call returns, whether login/permission is required, or how failures are surfaced for what is clearly a mutating send 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?

Purpose is front-loaded in the first clause, followed by the format example and parameter notes. The :param lines duplicate the schema descriptions and are mild redundancy, but nothing is bloated or 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 two-required-parameter send tool with no output schema and no annotations, the description covers the hard part (node structure) but omits return values, error behavior, and the relationship to sibling send tools. 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 coverage is 100% and the :param lines merely repeat the schema text, which alone would be a baseline 3. However the schema declares messages as an untyped array (items: {}), and the description supplies the concrete node dict structure and an example, filling a genuine gap the schema leaves open.

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 ('向指定好友发送合并转发消息' – send a merged forward message to a specified friend) and cites the underlying NapCat OneBot 11 action. The word '好友' distinguishes it from the group counterpart, but it never names send_private_msg or send_group_forward_msg to sharpen the boundary.

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 conditions, and no reference to the closely related siblings (send_private_msg, send_group_forward_msg). The agent must infer that this is the private/forward variant purely 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 burden. It usefully discloses supported message formats (plain text, CQ code, message-segment array) and the meaning of auto_escape, but says nothing about failure/error behavior, whether the target must already be a friend, rate limits, or what the call returns.

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?

Front-loads the purpose in the first sentence and keeps the format/parameter notes compact and scannable. There is minor redundancy restating parameter descriptions already present in the schema.

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 send tool with no output schema and no annotations, the definition covers formats and escaping but omits return value, error/failure behavior, and any permission or friend-relationship prerequisite, leaving meaningful 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 coverage is 100%, so the schema already documents all three parameters and the description mostly restates them. It adds a concrete message-segment example that is marginally helpful, but no syntax or format detail beyond the schema 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?

States a specific verb (发送) and resource (私聊消息) with a clear target (指定好友或用户) and names the OneBot 11 action. It is clearly a private-message send, distinguishable in concept from send_group_msg, though it does not explicitly contrast itself with the generic send_msg 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 usage (private messaging) but gives no explicit when-to-use or when-not guidance, and no routing against alternatives like send_msg, send_private_forward_msg, or send_poke that an agent must choose between.

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 implies a mutation (making a message an essence message) but does not disclose required permissions, reversibility, idempotency, or error behavior. Calling it an 'NapCat 扩展接口' hints at non-standard API support but adds little operational detail.

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 short and front-loads the action, which is good. However, the third line is a docstring-style restatement of the already-documented parameter, which is redundant and adds noise without value.

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 mutation with no output schema, the description covers the basic 'what' but omits permission requirements, failure modes, and the distinction from sibling essence-message tools. It is minimally adequate rather than 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% for the single parameter, so the baseline is 3. The description merely restates the schema's own text ('要设为精华的消息 ID'), adding no format, range, or sourcing guidance beyond it.

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 in both Chinese and English ('将指定群消息设为群精华消息', 'set_essence_msg'), so the operation is unambiguous. It does not explicitly distinguish itself from close siblings like delete_essence_msg or get_essence_msg_list, which are the tools an agent could 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 statement of when to use this tool versus alternatives, no prerequisites (e.g. group admin/owner rights), and no note about what happens if the message is already an essence message. The closest thing to guidance is the parenthetical calling it a NapCat extension interface.

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 bears the full behavioral burden. It does disclose that approve=true accepts and approve=false rejects, but it never says whether the flag expires, whether a rejection is reversible, what permissions are needed, or what the caller receives — significant gaps for a mutation tool with zero annotation coverage.

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 one-line purpose is front-loaded and the parameter block is terse; total length is small. The only waste is that the param lines duplicate the schema word-for-word rather than adding value.

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 three-parameter mutation tool with no annotations and no output schema, the description covers what the tool does and what the parameters mean but omits how to obtain the flag, the effect of approving/rejecting on the target's friend list, and any error conditions — leaving an agent without enough context to invoke it safely.

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 flag, approve, and remark. The :param block in the description merely restates those identical texts verbatim, adding no format hints, flag provenance, or constraint details beyond the structured data.

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 pair — approving/handling an incoming friend-add request — and cites the underlying OneBot 11 action. That resource (friend add request) is implicitly distinct from the sibling set_group_add_request, though the description never names that sibling to sharpen the distinction.

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 subject ('someone sent you a friend request'), but there is no explicit when-to-use guidance, no indication of where the required 'flag' comes from, and no mention of the obvious alternative (set_group_add_request) or the retrieval tool (get_recent_notices_and_requests).

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 only says the remark is set or modified and does not disclose permissions, whether an existing remark is overwritten, error behavior, or reversibility. 'NapCat 扩展接口' adds provenance, not 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 compact and front-loaded with the purpose before the parameter lines. The two ':param' lines duplicate the schema descriptions and do not earn their place, but the overall text is not bloated.

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 setter with full schema coverage and no output schema, the description states the essential action. It omits relevant mutation details such as whether the target friend must already exist or whether an existing remark is overwritten, which matters given there are no annotations.

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. The description repeats the same explanations for user_id and remark verbatim and adds no format, constraint, or usage meaning 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 (设置或修改) and resource (指定好友的备注名), and the word 好友 distinguishes it from group-scoped siblings such as set_group_card or self-scoped siblings such as set_qq_profile. It does not explicitly name alternatives or exclusions, so it stops 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives. The purpose implies it is used for friend remarks, but the description gives no condition that selects it over related setters like set_group_card or set_qq_profile.

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 discloses that 'reason' only takes effect when approve=False, but for an admin mutation it says nothing about the required group-admin/owner privileges, whether the action is reversible, or what the result is. Significant 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?

The purpose is front-loaded in the first sentence, but the ':param' block duplicates the schema almost word-for-word, adding length without new information. Structure is adequate but includes redundant 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 permission-gated mutation tool with no annotations and no output schema, the description should convey auth requirements and outcome. It does not, leaving key operational context missing even though parameter definitions are fully covered by the 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 description coverage is 100%, so the baseline is 3. The description's per-parameter text is essentially verbatim from the schema (flag, sub_type, approve, reason), adding no meaning beyond what the schema already documents.

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 ('审批处理加群请求或邀请入群请求' - approve a group join request or invitation) and cites the OneBot 11 action name. This clearly distinguishes it from set_friend_add_request, a sibling handling friend requests, though it doesn't call that sibling out 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?

It explains what sub_type 'add' vs 'invite' mean, which helps the agent choose the right call shape, but there is no guidance on when to use this tool versus alternatives, where the required 'flag' comes from, or any permission prerequisites. Usage context is left to inference.

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 disclose the group-owner permission requirement, which is real behavioral context beyond the schema. However, it says nothing about reversibility, what happens on permission failure, rate limits, or whether the bot itself must hold a role, leaving a mutation tool only partially characterized.

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?

Purpose and permission requirement are front-loaded in a single tight sentence, and the whole thing is short. The trailing ':param' block is pure duplication of a fully-covered schema and adds no information, which costs it the top score.

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 three-parameter toggle with no output schema and no annotations, the description covers purpose, prerequisite, and parameter meanings. It stops short of describing failure behavior or the result of the operation, which an agent calling a privileged mutation would benefit from knowing.

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 three ':param' lines are verbatim duplicates of the schema descriptions rather than additions. The baseline of 3 applies when the schema already documents every parameter.

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 gives a specific verb pair and resource ('设置或取消群管理员') and even names the underlying OneBot 11 action, so the agent knows exactly what operation is performed. It is distinguishable from siblings like set_group_special_title or set_group_kick, but it never explicitly contrasts itself with them.

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 only usage guidance is the prerequisite '需群主权限' (requires group owner permission), which is genuinely useful for deciding whether a call will succeed. There is no guidance on alternatives (e.g. set_group_special_title for titles) or on when to prefer this over other admin-related tools, so it remains implied usage rather than explicit routing.

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 does disclose meaningful semantics (duration=0 means unban, default 1800s), but omits whether the bot must be a group admin, whether the target can be an owner/admin, and what happens on permission failure — significant gaps for a restrictive 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?

Front-loaded single sentence stating the action, followed by three compact param notes. The param list largely duplicates the schema, which is mild redundancy but not verbosity.

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-param mutation tool with no annotations and no output schema, the description covers enough to invoke it correctly (required ids plus duration semantics) but leaves authorization requirements and error/return behavior undocumented.

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 repeats the schema text for user_id and duration verbatim, adding no syntax or edge-case detail beyond the default and the 0-means-unban rule. Baseline 3 is appropriate when 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?

States a specific verb pair and resource: '群聊单人禁言或解禁' (mute/unmute a single group member), with the 'OneBot 11: set_group_ban' mapping. The word '单人' (single member) implicitly separates it from sibling set_group_whole_ban, though 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 only implied: the description notes duration=0 lifts the ban and the default is 1800s, which hints at the mute/unmute duality. It never states when to prefer this over set_group_kick, set_group_whole_ban, or get_group_shut_list, nor any prerequisites.

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 disclosure burden. It does note that an empty card string clears the card, which is useful, but it says nothing about the mutation's permission requirements (typically admin/owner), failure modes (target not in group), or reversibility.

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 short, front-loads the purpose, and the parameter lines are compact. The :param block is largely redundant with the schema, but it costs little and does not obscure the primary statement.

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 three-parameter mutation tool with no annotations and no output schema, the description covers what each parameter means and one edge case (clearing), which is enough to invoke it. It falls short on the operational context an agent would want — required permissions and behavior when the target is not a group member.

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 group_id, user_id, and card are already fully documented in the schema. The description restates the same three meanings plus the empty-string semantics, adding no syntax or format detail beyond what the schema provides; 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 and resource: modify a group member's group card/nickname, and even names the underlying OneBot 11 action (set_group_card). It does not differentiate from near-siblings such as set_group_special_title, set_group_name, or set_friend_remark, which an agent could plausibly 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 mention of prerequisites (e.g., bot admin rights, target must be a group member), and no reference to alternative sibling tools for related profile edits. The agent must infer the appropriate 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, but it does disclose the key behavioral fact that admin or owner permission is required. It does not state whether the kick is reversible, what happens on failure, or whether reject_add_request permanently blacklists the user, which leaves meaningful gaps for a destructive 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?

Purpose is front-loaded and the text is short. But the trailing :param block duplicates the schema descriptions word-for-word, so several lines do not earn their place beyond restating structured data.

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 three-parameter mutation with no annotations and no output schema, the description covers the essentials (action, permission requirement, params). It omits failure behavior and the permanence implication of the blacklist flag, so it is 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 the schema already documents all three parameters with the same text the description repeats verbatim. The description adds no syntax, format, or default semantics beyond what the schema provides, 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 gives a specific verb+resource ('将指定成员移出群聊'), names the underlying OneBot 11 action (set_group_kick), and identifies the acting resource (a group). An agent can tell this apart from read/listing siblings without opening the schema, though it doesn't explicitly contrast with set_group_ban or set_group_leave.

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 a real prerequisite ('需具备管理员或群主权限'), which is useful operational guidance. However it gives no when-to-use/when-not guidance and never contrasts with close siblings like set_group_ban (temporary mute) or set_group_leave, leaving the agent to infer the distinction.

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 of behavioral disclosure. It does disclose the owner-only constraint for is_dismiss, but says nothing about irreversibility, what happens to the agent's membership or messages on leaving, or any permission/auth requirements for the leave path.

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 short and front-loads the purpose, but roughly half its content is a verbatim restatement of the input schema's parameter descriptions, which earns no additional value. The OneBot 11 action reference is the only extra signal.

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 destructive group-membership tool with no annotations and no output schema, the description covers the basics and the owner-only caveat but omits consequences of the call and the effect of omitting is_dismiss beyond its default. 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 are verbatim duplicates of the schema text, adding no format, range, or edge-case meaning. Baseline 3 applies when the schema does all the work.

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 pair, naming both modes (leave the group / dissolve the group) and citing the underlying OneBot 11 action. It is clearly distinct from sibling mutation tools like set_group_kick or set_group_ban, but it does not explicitly call out that 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?

Usage is implied by naming the two modes, and one precondition is given for the dismiss mode ('仅当自己是群主时有效'). However, there is no guidance on when to prefer this over set_group_kick or other group-membership tools, and no stated when-not conditions.

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, yet it says nothing about required permissions, whether the rename is reversible, rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap.

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 is front-loaded in the first line, but the two ':param' lines duplicate the input schema without adding value, so the text is not fully earning its place. It is short, but partly redundant rather than dense.

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 permission requirements and expected outcome; the description covers neither. An agent cannot tell from this text whether the call will succeed or what it returns.

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 two ':param' lines simply restate the schema descriptions verbatim ('群号', '新群名称'), adding no format, constraint, or length-limit information. Baseline 3 is appropriate since the schema already documents both 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 states a specific verb and resource ('修改 QQ 群名称' / modify QQ group name) and cites the OneBot 11 action name, so the agent knows exactly what changes. It does not explicitly contrast itself with similar siblings such as set_group_card or set_group_special_title, 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?

There is no guidance on when to use this tool, no prerequisites (e.g. bot must be owner/admin), and no mention of alternatives among the many sibling set_group_* tools. Usage must be entirely inferred 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?

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?

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?

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?

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?

With no annotations, the description carries the full behavioral burden. It does disclose two important traits: the operation requires group-owner permission and an empty special_title cancels the title. Beyond that it says nothing about failure behavior, length limits on titles, or whether duration interacts with cancellation, so the disclosure is partial.

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?

Purpose and the permission prerequisite are front-loaded in the first sentence, with parameter notes following in a compact list. It is efficient, though the per-parameter lines duplicate the schema rather than adding 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 no-annotation, no-output-schema mutation tool, the definition covers the core facts (permission requirement, cancel-via-empty-string, duration default). It still omits title constraints and error/return behavior, so it is adequate but not 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 all four parameters are already documented in the schema, and the description merely restates those same strings (群号, 目标成员 QQ 号, etc.). Baseline 3 is appropriate — the description adds no syntax or format detail beyond the structured fields.

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: 设置群成员专属头衔 (set a group member's exclusive title), and ties it to the OneBot 11 action name. This is distinguishable from neighboring tools like set_group_card (群名片) by the '专属头衔' wording, though it does not explicitly call out the difference.

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 one prerequisite — '需群主权限' (requires group owner permission) — which is genuine usage context. However, it offers no when-to-use vs when-not guidance and no comparison to the closely related set_group_card sibling, leaving routing to inference.

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