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

With no annotations, the description carries the full burden. It adds useful behavioral details: batch semantics, comma-separated channels, the 5-channel maximum, one-to-one option mapping, and pushId requirements. But it does not disclose failure behavior, partial-send outcomes, return value shape, or any authorization/rate-limit considerations.

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 three short sentences with no filler. The primary action is front-loaded, and the key constraints are stated directly and compactly.

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?

This is a 12-parameter tool with no annotations and no output schema, yet the description only elaborates channel, option, and pushId. It omits guidance around result/error responses, how content interacts with templates, timestamp/callback behavior, and prerequisites for successful batch sending—leaving a significant completeness gap for an agent invoking it correctly.

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 adds value beyond the schema by clarifying the 5-channel maximum, the strict one-to-one matching between channel and option, and the pushId requirement for specific templates—details not fully captured in the input 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 clearly states the action: using the pushplus /batchSend interface to send messages to multiple channels at once. This distinguishes it from the single-message sibling tools (send_text_message, send_push_message, etc.) by emphasizing multi-channel batch behavior, though it does not explicitly name the 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?

Usage context is implied: it is for multi-channel batch sends, with concrete constraints such as a 5-channel limit, comma-separated channels, option-to-channel pairing, and mandatory pushId for certain templates. However, it never explicitly says when to prefer this tool over the single-send siblings or when not to use it.

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 behavioral burden. It clarifies that the operation is a GET with no request parameters and describes the unified response shape, which implies a read-only info lookup. However, it does not explicitly state side-effect safety, preconditions, or error behavior beyond the generic code field.

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 resource and action. Every sentence adds meaningful information: endpoint, purpose, parameter absence, and response structure, with no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description appropriately documents the unified response and the two data fields. It is sufficient for a zero-parameter, simple info query, though it could be slightly stronger by stating the expected data types for createTime and haveContextToken.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is an empty object, so there are no parameters to document. The description reinforces this with '请求参数: 无' (no request parameters), which removes any ambiguity for the agent.

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 the HTTP method and exact endpoint, then gives a clear verb-resource pair: '获取已绑定机器人详情' (get bound bot details). This is specific enough to distinguish it from sibling ClawBot tools like qrcode, message, or unbind operations.

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 about when to choose this tool over alternatives. It does not mention related sibling tools such as open_clawbot_get_msg or open_qqbot_bot_info, nor any conditions that would make this the right 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?

With no annotations, the description carries the burden of behavior disclosure. It discloses the HTTP method, the fact that no parameters are needed, the unified response envelope, and the semantic difference between url and qrcode. However, it does not mention authentication requirements, failure modes, or whether any side effects occur, which leaves some behavioral uncertainty.

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, well-structured, and front-loaded with the endpoint and purpose. Every sentence adds useful information: endpoint, purpose, parameter count, unified response format, and data field meanings. There is no redundancy or 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 zero-parameter GET tool with no output schema and no annotations, the description adequately covers the endpoint, request expectations, and response structure including the meaning of the data fields. It stops short of documenting error cases beyond the generic code/msg envelope, but this is a minor gap for such a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the description explicitly confirms this with '请求参数: 无.' Since there are no parameters to document, the explicit no-parameter statement adds clarity beyond the empty schema and earns above the baseline for a schema-covered case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: '获取微信 ClawBot 绑定二维码' via GET /open/clawBot/getBotQrcode. This clearly distinguishes the tool's role from sibling tools like open_clawbot_get_qrcode_status, and the mention that qrcode is for querying scan status reinforces the distinction without ambiguity.

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 provides no explicit guidance about when to use this tool versus alternatives such as open_clawbot_get_qrcode_status or open_friend_get_qr_code. It states that there are no request parameters and describes the response, but it never says 'use this when you need the binding QR code' or 'use the status tool to check after scanning.'

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 itself carries the burden. It explicitly warns that the call '可能耗时较长' (may take a long time), and it describes the unified response envelope and data item shape. This covers the main non-obvious behavior for a no-parameter GET 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?

The description is compact and logically ordered: endpoint, behavior warning, parameters, and response format. Every clause conveys useful information and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple parameter-free retrieval tool with no output schema, the description is complete: it states the resource, latency risk, and the exact response structure including success code and item type/text fields. No additional context is necessary to invoke it correctly.

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 has zero parameters and the schema already reflects that. The description confirms '请求参数: 无' and adds no misleading parameter expectations, which satisfies the baseline for a parameter-free tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('获取' / get) and resource ('ClawBot 侧消息'), and names the exact HTTP endpoint. This is distinct from sibling tools such as open_clawbot_get_bot_qrcode or open_clawbot_unbind, so an agent can tell what it operates on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no when-to-use guidance and does not mention alternatives or exclusions. With many sibling message/message-list tools (e.g. open_message_list), an agent gets no explicit help choosing this tool over them.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses an HTTP GET operation, a non-mutating query intent, and gives the unified response envelope with code, msg, and data. This is useful transparency, though it stops short of explaining specific status values or error behaviors.

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 well structured: operation first, then parameter explanation, then response format. Every sentence adds information, with no filler or repetition of schema details beyond the necessary connection to getBotQrcode.

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 GET query, the description covers the required input, its source, and a generic response envelope. However, without an output schema, the core value—what the binding status data actually contains or what possible values appear—is left to the vague 'data(业务数据)', so an agent cannot fully interpret the result.

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 qrcode as '二维码编号（getBotQrcode 返回的 qrcode）'. The description mostly restates this and adds that it is required, which is already encoded in the schema. The value-add is minimal but consistent.

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 clearly states the operation: '查询扫码绑定状态' (query scan-binding status) on a specific ClawBot resource, and includes the exact HTTP path. It also references getBotQrcode as the source of the qrcode parameter, which indirectly distinguishes it from the QR-code generation sibling, though it does not explicitly name the 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?

The description implies when to use the tool by noting that qrcode comes from getBotQrcode's data.qrcode, suggesting this status-check call follows QR-code generation. However, it does not explicitly state when to choose this over sibling tools such as open_clawbot_unbind or open_clawbot_get_msg, nor does it provide when-not-to-use 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?

With no annotations, the description carries the full burden. It does flag the operation as high-risk and states the response envelope (code, msg, data), but it does not disclose the actual consequences of unbinding, such as whether it is irreversible, whether the bot disconnects immediately, or what side effects occur.

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, covering endpoint, risk level, absence of parameters, and response format in a few clauses. No filler or redundant explanation is present.

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 0-parameter tool, the description is mostly adequate: it gives the endpoint, risk flag, and unified response shape. However, given that this is a high-risk unbind operation with no annotations, it should explain what 'unbind' actually does and what the agent should expect afterward.

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 has zero parameters, and the schema confirms this. The description explicitly states '请求参数: 无', so there is no parameter semantics burden beyond confirming the absence of inputs.

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 ('解绑' / unbind), an explicit HTTP endpoint, and the target resource ('微信 ClawBot'). This clearly distinguishes it from sibling tools like open_qqbot_unbind or other ClawBot utilities.

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 provides no when-to-use guidance or exclusions. It warns '高风险' but does not explain under what circumstances unbinding is appropriate, nor does it mention alternatives such as open_qqbot_unbind for the QQBot equivalent.

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

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

No annotations are provided, so the description carries the full burden. It discloses the HTTP method, pagination defaults and limits, the unified response envelope, and the paginated data shape with list item fields. It does not explicitly state that the operation is read-only or describe auth requirements, but the list semantics imply a non-mutating 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 description is compact and well organized into endpoint, request pagination, unified response, pagination response, and item fields. Every sentence adds operational detail such as defaults, maximum page size, or response structure, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter list tool with no output schema and no annotations, the description covers pagination request fields, the standard response envelope, the paginated data structure, and the fields inside each list item. It lacks only broader context like authentication or placement of parameters in the request body, but nothing essential to invoking the call 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?

The input schema already documents both current and pageSize with descriptions, and schema coverage is 100%. The description restates these parameters and adds default/max values, but those are already in the schema, so the description adds little beyond what the structured data 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 and resource: '获取企业微信应用列表' and the exact endpoint 'POST /open/cp/list'. The phrase '企业微信应用列表' clearly distinguishes this from sibling list tools like open_mp_list or open_mail_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes it clear this is the tool for paginated enterprise WeChat application list retrieval. It does not explicitly name alternatives or exclusions, but the resource scope is specific enough for an agent to infer when to select it among many sibling list 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 the behavioral burden. It discloses the HTTP method, the fact that MCP assembles the multipart body, the unified response envelope (code/msg/data), and the typical success payload (image URL string). It does not mention side effects beyond creating an uploaded image, but it is substantially transparent.

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: endpoint and invocation first, then parameters, then the alternative flow, then the response format. Every sentence contributes information relevant to calling the tool correctly, with no padding.

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?

Given two simple parameters and no output schema, the description is complete: it documents auth method, multipart assembly, the alternative sibling, and the full response envelope including success code and data meaning. An agent has enough to invoke and interpret the result.

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 meaningful context: 'filename + contentBase64，由 MCP 组装 multipart' tells the agent it does not need to build multipart encoding itself. It also reinforces that contentBase64 should exclude the data: prefix, though the schema already states this.

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 'POST /open/file/uploadImage - 使用 access-key 直接上传图片（multipart file）'. It also names the sibling flow it is not (七牛直传流程/open_user_image_upload_token), making selection 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?

It gives a clear context: this tool directly uploads with access-key and MCP assembles the multipart request. It explicitly routes to open_user_image_upload_token when the official Qiniu flow is needed, but does not cover other exclusions such as file size limits or unsupported image formats.

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 transparency burden. It explicitly discloses high risk, the fact that both sides of the friendship are dissolved, the other person can no longer add you, and that self-blacklisting is impossible. This fully informs the agent about the destructive 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 compact and well-structured: risk is front-loaded first, followed by behavioral consequences, eligibility constraints, request parameter, and response format. Every sentence contributes useful information without fluff.

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 mutation tool with no output schema, the description covers the endpoint, risk level, side effects, eligibility rules, request parameter, and unified response fields. Nothing essential is missing for an agent to invoke it correctly.

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 friendId and its source from the friend list. The description repeats this information without adding materially new semantics, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: adding an existing friend to the blacklist via the POST endpoint. It also differentiates itself from siblings like open_friend_remove_blacklist and open_friend_blacklist_list by specifying the exact scope and effect.

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 provides strong usage context: use it to blacklist an existing friend, not yourself, and only for people already in your friend list. It does not explicitly name alternatives such as open_friend_remove_blacklist for undoing the action, but the conditions are clear enough for correct selection.

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 covers behavior well: it documents pagination defaults, max page size, the uniform response envelope (code/msg/data), and the exact fields in each blacklist entry. It doesn't mention auth or rate limits, but the read-only nature is clear from '获取' and there are no mutation hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and well organized: purpose first, then request parameters, response envelope, pagination structure, and list item fields. Every sentence carries useful information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with two optional parameters and no output schema, the description provides enough to invoke it and interpret results, including list item semantics and the note that id is used for解除黑名单. It omits error handling and authentication details, but those are not critical for a paginated read-only 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 schema already documents current's default and pageSize's default/maximum. The description repeats these constraints without adding new semantic meaning, so it meets the baseline but contributes no extra parameter insight.

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 clearly states the operation and resource: '获取好友黑名单列表' via POST /open/friend/blacklistList. This distinguishes it from sibling tools such as open_friend_list (regular friend list) and open_friend_add_blacklist/remove_blacklist (mutating blacklist operations).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving a paginated list of blacklisted friends, which is enough for basic selection. However, it gives no explicit when-to-use guidance and does not contrast it with similar siblings like open_topic_user_blacklist_list, so the agent must infer the right choice largely 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 behavioral disclosure burden. It does label the operation '高风险' (high risk), exposing its destructive nature, and it documents the unified response format (code/msg/data). It does not go further to state irreversibility, authorization requirements, or consequences beyond deleting the friendship, so it is 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?

The description is compact and front-loaded: endpoint, risk label, required parameter, and response contract each in logical order. It avoids fluff, though the response-format sentence is generic and could be considered unnecessary; overall this is efficient and well structured.

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?

This is a low-complexity, two-parameter destructive tool with no output schema. The description compensates for the missing output schema by defining the unified response contract and flags high risk. It could mention irreversibility or require additional confirmation, but for a simple delete-friend call the provided context is sufficient to invoke correctly.

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 friendId and appId. The description adds the '必填' (required) marker and says friendId comes from the friend list, which repeats the schema's meaning rather than adding new semantics. The baseline of 3 is appropriate because the schema carries the parameter load.

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 combination: '删除好友' (delete friend), preceded by the exact endpoint. Even without opening the schema, an agent can distinguish it from sibling friend-management tools like open_friend_list, open_friend_edit_remark, and open_friend_add_blacklist. The endpoint and risk label add no ambiguity.

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 by requiring friendId '来自好友列表 friendId', which points the agent to fetch a valid friendId from a friend-list source first. However, it does not explicitly say when to choose this tool over related friend operations or when not to use it, so the guidance remains implicit rather than explicit.

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

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

With no annotations provided, the description carries the full burden. It discloses the HTTP method (POST), required parameters, and the unified response format (code, msg, data), which provides some behavioral context. However, it does not detail side effects, idempotency, error conditions, or prerequisites beyond the id originating from a list. The description adequately conveys it is a write operation but lacks deeper behavioral transparency.

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 a compact, front-loaded statement: endpoint and purpose first, then parameters, then response format. Every sentence earns its place with no filler. It is appropriately sized for a simple two-parameter edit operation.

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?

Given a simple operation with two fully documented parameters and no output schema, the description covers the essentials: endpoint, purpose, required fields, and response envelope. It lacks a detailed data shape for the response, but for an edit-remark action the success/failure code is likely sufficient. The context is complete enough for correct 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 schema already documents both parameters. The description essentially repeats the schema: id is the friend number from the list, remark is the note. It adds no new semantic meaning beyond what's already in the input schema, meriting the baseline score.

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 clearly states the operation '修改好友备注' (modify friend remark) with the specific resource '好友备注'. It names the endpoint and explicitly identifies the target as '好友', distinguishing it from sibling tools like open_topic_user_edit_remark. An agent can immediately understand what this tool does 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?

Usage is implied by the description: it is for editing a friend's remark, and the mention '列表 id 字段' hints that the id comes from a friend list operation. However, there is no explicit when/when-not guidance or reference to alternative tools such as open_friend_list or open_topic_user_edit_remark. The description leaves the agent to infer the context.

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 a solid job: it reveals the operation is a GET request, documents the unified response shape (code/msg/data), and names the returned data field qrCodeImgUrl. It could add more detail about auth requirements or error cases, but the core behavior is transparent.

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 organized: endpoint, purpose, parameter list, unified response, and data field. It front-loads the key purpose and does not include filler, though it reads as a dense paragraph rather than structured bullets.

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 correctly compensates by explaining the unified response and the qrCodeImgUrl field. All four optional parameters are covered with defaults and ranges, and the endpoint and purpose are clear. Nothing essential is missing for an agent to invoke this tool correctly.

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 adds defaults and ranges (604800, 30 days, -1, 1-999) which mostly mirror the schema descriptions; it does not materially expand semantics beyond the structured definitions. 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 HTTP method and resource (GET /open/friend/getQrCode) and states the exact purpose: 获取个人二维码（用于添加好友）. The explicit '个人' scope distinguishes it from sibling QR-code tools like open_topic_qr_code and open_clawbot_get_bot_qrcode, so an agent can tell them apart.

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 saying it is for adding friends, but it does not explicitly state when to use it over alternatives, nor does it mention any exclusions or prerequisites. The usage context is inferable, not spelled out.

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 burden of explaining behavior, and it does so by documenting pagination behavior, the unified response envelope, paginated data shape, and each list item's fields including the token's purpose. It does not explicitly mention authentication or confirm there are no side effects, but '获取' strongly implies a read operation and the response contract is well detailed.

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 front-loaded with endpoint and purpose, then moves into pagination, response envelope, paginated data, and list item fields in a logical order. It is dense but not bloated; the field enumeration is justified because no output schema exists.

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?

Given the tool's simplicity (two optional parameters, no output schema, no annotations), the description is complete: it specifies request parameters, defaults, limits, the uniform response envelope, pagination fields, and the full set of list item fields. An agent has enough information to invoke the tool and interpret its response correctly.

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%: both current and pageSize already have meaningful descriptions with defaults and the 50 maximum. The tool description mostly repeats this information rather than adding new semantic context beyond the schema, 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 opens with the exact HTTP method and path plus the Chinese action '获取好友列表' (get friend list), making the verb and resource explicit. It distinguishes itself from sibling friend-related tools like open_friend_delete and open_friend_edit_remark by clearly naming the list operation.

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 explains pagination usage (current, pageSize, defaults, max) but never states when to prefer this tool over alternatives or when not to use it. However, the name and purpose make the intended use obvious, and no sibling tool appears to be a competing friend-list endpoint.

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 of behavioral disclosure. It explicitly warns that the operation is high-risk and that removing the blacklist entry will not automatically restore the friend relationship, requiring a new QR-code scan. This is valuable behavior beyond the schema and adequately prepares the agent for the side effect.

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 endpoint and risk warning. Each sentence earns its place: risk, side effect, parameter explanation, and response format. It conveys the necessary information without fluff.

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 tool with no output schema, the description covers the critical aspects: the operation, its risk, the parameter source, and the unified response format. It does not describe the exact content of 'data', but this is not essential for invoking a simple removal operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: the schema already documents 'id' as the blacklist record ID from the blacklist list's id field. The description largely restates this and adds the 'required' flag, which is already in the schema. No significant new parameter meaning is 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?

The description states a specific action ('解除好友黑名单' / remove friend blacklist) and the exact REST endpoint, making the resource and verb unambiguous. It is clearly distinct from sibling tools like open_friend_add_blacklist or open_friend_blacklist_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly indicates when the tool is appropriate: to remove a friend from the blacklist. It also provides important cautionary context by warning that removal is high-risk and does not restore the friend relationship automatically. It does not explicitly name alternatives or exclusions, but the use case is clear.

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 takes the full burden and does so thoroughly: it discloses the ~7200-second validity, notes that repeated acquisition invalidates the previous key, warns of 403 when prerequisites aren't met, and documents the unified response fields including accessKey and expiresIn. This is rich behavioral disclosure beyond a bare 'get credential' statement.

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 yet dense, starting with the endpoint and purpose, then covering prerequisites, behavior, and response format. Each sentence contributes essential operational information and there is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, no-output-schema tool with no annotations, this description is fully self-sufficient. It covers prerequisites, authentication variables, token lifecycle, response structure, and how to use the result, so an agent has everything needed to call and consume it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4; the description exceeds it by explaining how authentication is supplied via environment variables PUSHPLUS_TOKEN and PUSHPLUS_SECRET_KEY, and how the returned accessKey should be placed in the 'access-key' header. This adds meaning that the empty schema cannot 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?

The description states a specific verb and resource: '获取开放接口调用凭证' (obtain open interface access credential), and names the exact endpoint POST /common/openApi/getAccessKey. It clearly distinguishes this from the many sibling open_* tools by framing it as the credential-issuing 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?

The description gives clear context: which environment variables are required, that the open interface must be enabled, that a security IP must be configured, and that other open_* tools automatically exchange and cache the key. It stops short of an explicit when-to-use/when-not-to-use rule, but the guidance is strong enough for an agent to decide correctly.

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 discloses the HTTP method (GET), the unified response shape (code/msg/data), and the returned data fields, including smtpSsl semantics. However, it does not mention authentication requirements, error behavior, or whether the password field is sensitive/redacted.

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 endpoint and purpose, then lists the request parameter and response fields in a structured way. Every sentence adds necessary information 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 simple single-parameter GET detail tool with no output schema, the description covers the request, required parameter, and response data fields. It is sufficiently complete to call correctly, though it lacks explicit usage guidance and auth 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?

The input schema already fully documents mailId with a description and required flag. The description restates mailId as '必填' and mentions it in the URL, but adds no additional 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 clearly states this is a GET endpoint for mail channel details ('邮箱渠道详情') and specifies the resource via mailId. It is easily distinguishable from the sibling open_mail_list, since this is the detail variant.

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 '详情' (detail) wording and the requirement of a mailId, but the description does not explicitly say when to use this tool versus open_mail_list or other detail tools. No exclusions or alternatives are named.

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 disclosure burden and does well by documenting the unified response envelope, pagination fields, and list item fields. The only minor omission is auth requirements and error-code behavior beyond the generic 200 success case.

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 well-structured and front-loaded with the endpoint and resource, followed by compact request and response sections. It is detailed rather than verbose, and every sentence carries functional information. A short example would be a minor improvement.

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 2-parameter list endpoint with no output schema and no annotations, the description is unusually complete: it covers request parameters, pagination behavior, the response envelope, and list item fields. It lacks only optional extras like authentication prerequisites and non-success error variants.

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 defines current and pageSize. The description adds useful context around defaults and maximums, but mostly repeats schema information and contributes no new parameter-level semantics.

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 clearly states the endpoint, HTTP method, and resource: 'POST /open/mail/list - 获取邮箱渠道列表'. It is immediately distinguishable from sibling tools like open_mail_detail and open_message_list because it explicitly names the resource (mail channel list) and the list operation.

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 purpose of retrieving a paginated mail channel list is clearly conveyed, so an agent can infer when to use this tool. It does not explicitly name alternatives or when-not-to-use conditions, but no exclusions are needed given the straightforward list semantics.

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 responsibility for disclosing behavior. It explicitly states the high-risk nature, that all recipients lose access after deletion, and that the action cannot be undone. It also discloses the unified response structure. This goes beyond what the raw schea or endpoint alone would convey.

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?

Every sentence carries meaningful information: the endpoint, the high-risk/irreversibility warning, the required parameter, and the response format. It is compact, well-organized, and front-loads the most critical safety information before procedural details.

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 delete operation with no output schema, the description covers the essential behavioral details: what gets deleted, the consequences, irreversibility, how to supply the parameter, and the shape of the response. No critical knowledge needed to invoke or understand the tool 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?

The input schema has 100% parameter description coverage for shortCode, and the description simply repeats the parameter name and required flag. While it confirms the field is mandatory, it adds no format, length, origin, or relationship to other messages beyond what the schema already 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+resource via the HTTP method and endpoint ('DELETE /open/message/deleteMessage') and clearly communicates the destructive intent: deleting a message so all recipients can no longer see it. This distinguishes it from non-delete sibling tools such as open_message_list and open_message_send_result, and from delete tools targeting other resourcesses like topics or friends.

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 makes the usage context unmistakable: use this when you need to permanently remove a message from all recipients. It does not nae alternative tools or exclusions, but given that no sibling tool offers message deletion, the context is clear enough. The high-risk warning also advises againt casual use.

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 behavioral burden. It discloses the HTTP method, the unified response envelope (code/msg/data), pagination fields, and list-item semantics. It omits explicit auth or read-only/no-side-effect statements, but '查询' and the detailed response shape make the behavior clear.

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 a dense, well-structured paragraph: purpose first, then request parameters, then response fields. Every sentence adds useful information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so describing return values is essential; the description fully documents the response envelope, pagination metadata, and list item fields, while also covering request constraints. An agent has enough information to call the tool correctly.

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 baseline is 3. The description adds meaning beyond the schema by giving defaults for current and pageSize, a maximum pageSize of 50, example channel values, and the messageType mapping. Only isRead is left to the schema, so this is above 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 (消息列表) and includes the HTTP endpoint. This clearly separates it from siblings like open_message_send_result or open_message_delete even without inspecting their schemas.

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?

Clearly establishes this tool as the paginated message-list query and the note that shortCode can be used to query send results implicitly points toward the result tool. It does not explicitly name alternatives or when-not-to-use, 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, the description carries the full burden. It discloses the HTTP method, unified response shape, data fields, and the status enum with meanings, which is substantial. It does not discuss authentication or rate limits, but for a simple GET-style query the provided behavioral detail is strong.

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?

Concise and front-loaded: endpoint and purpose first, then a compact response spec. Every sentence carries useful information and there is no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, low-complexity query tool with no output schema, the description covers the necessary operational details: endpoint, status meanings, error field, and update time. It could slightly improve by explicitly routing the agent to use this after send-message calls, but the parameter schema already supplies that 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%; the schema already defines shortCode as the short link code returned by the send-message interface. The description adds no new param semantics beyond confirming the lookup key, 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, resource, and scope: 'GET /open/message/sendMessageResult - 按 shortCode 查询投递结果'. This clearly distinguishes it from message-sending, message-listing, and message-deleting 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?

Usage is implied rather than explicit: querying by shortCode after a send operation. The schema parameter adds that the shortCode is returned synchronously by the send-message interface, but the description does not state when to use this tool instead of alternatives or provide exclusions.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses the HTTP method, the unified response envelope, and the relationship between detail fields and list fields, which is useful. It does not mention authentication, error behavior, rate limits, or explicitly guarantee non-destructiveness.

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, front-loaded with the endpoint and purpose, and then covers request, response, and data semantics in three concise clauses. No filler or redundant 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 read endpoint with no output schema, the description gives the response envelope and hints at field completeness relative to the list. It lacks exact detail fields and error handling, which leaves some ambiguity but is adequate for basic 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%, and the schema already explains id as 微信公众号编号. The description repeats the parameter name and required status but adds little semantic value 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 clearly identifies the resource as 公众号详情 and the operation as GET /open/mp/detail, implying retrieval of official account details by id. It is semantically distinguishable from sibling open_mp_list, though it does not explicitly call out 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?

The usage context is implied: this is a detail endpoint keyed by an id, so it should be used when a specific 公众号's details are needed. However, it does not explicitly state when to prefer it over open_mp_list or provide exclusion criteria.

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 discloses the response envelope (code/msg/data), pagination semantics, and detailed list item fields with enum meanings. It does not mention authentication, error cases beyond code 200, or whether the operation has side effects, but for a list operation the provided detail is strong.

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 dense and every clause adds useful information: endpoint, purpose, request parameters, response envelope, pagination fields, and list item fields. It is somewhat long and could benefit from line breaks, but it avoids filler and is appropriately front-loaded with purpose and usage.

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?

Given there is no output schema, the description compensates well by explaining the full response shape, pagination fields, and list item attributes including enum values. It is complete enough for an agent to call the tool and interpret results, though it omits non-200 error handling and authentication prerequisites.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters with defaults and max values, giving 100% schema coverage. The description repeats this information and adds response-level pagination details, but does not add meaning to the parameters themselves beyond what the schema already states.

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 clearly states the action ('获取') and resource ('微信公众号渠道列表'), and specifies the HTTP method and endpoint. It is distinct from siblings like open_mp_detail because it explicitly describes a paginated listing operation, though it does not explicitly name or contrast sibling 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?

The intended use is implied by the description: retrieve the WeChat official account channel list with pagination. It provides concrete pagination usage (current, pageSize defaults and max), but gives no explicit guidance about when to choose this tool over alternatives such as open_mp_detail or open_cp_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. It discloses that this is a mutating, high-risk operation and describes the unified response format. However, it does not mention side effects such as irreversible point deduction, authorization/permission needs, or failure behavior beyond a 200 success code.

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 efficient: it front-loads the endpoint and risk level, then covers request parameters and response structure in two sentences. No unnecessary words; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool, the description includes both request and response contracts, which is reasonable. However, 'data: 提现业务结果对象' is vague, and there is no elaboration on error cases or the consequences of the withdrawal. A high-risk operation would benefit from more detail about what could go wrong and what the agent should communicate to the user.

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 schema already provides descriptions for both parameters ('收款账户ID' and '提现积分'), and the description simply restates them without adding new constraints or context. There is no mention of value ranges, positivity requirements, or interactions between accountId and points, so the description adds little 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 clearly identifies the action and resource: '发起积分提现' (initiate points withdrawal) with the endpoint POST /open/pay/transferOrder. The high-risk warning immediately signals the nature of the operation, and no sibling tool appears to perform a similar function, so distinction is inherent.

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 does not explicitly state when to use this tool versus alternatives or provide exclusions. The '高风险' (high-risk) label implies caution, but there is no guidance on prerequisites, confirmation requirements, or scenarios where this tool should be avoided. Given the long sibling list, an explicit usage note would be valuable.

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 discloses important behavioral details: the HTTP method is POST, membership is required, the unified response format is described, and the data returned is the newly created preprocessing ID. It could add more about possible failures or side effects, but it covers the essential 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?

The description is compact and front-loaded: it opens with the endpoint and purpose, then lists required parameters, then closes with the unified response shape. Every sentence earns its place without redundant fluff.

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 create endpoint with four required scalar parameters and no output schema, the description is complete: it states the action, the membership prerequisite, all required inputs, and the response structure including the data field. An agent has enough information to invoke the tool correctly.

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 parameter meanings already present in the schema and adds only the '必填' markers and the contentType enum value, which are also inferable from the schema. It does not meaningfully expand parameter semantics.

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 clearly states the action '新增预处理' with the specific resource and endpoint 'POST /open/pre/add'. It is immediately distinguishable from sibling tools like open_pre_list, open_pre_detail, open_pre_edit, and open_pre_delete because it uniquely identifies the create operation.

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 provides clear usage context: this tool is for adding new preprocessing information and requires membership ('需会员'). It does not explicitly mention alternatives or when not to use it, but the '新增' verb and the sibling tool names make the intended use obvious.

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 burden of disclosing behavior. It explicitly flags the operation as high risk, states that membership is required, and documents the unified response format. It does not detail irreversibility or side effects, but the high-risk warning partially covers 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 description is compact and structured: endpoint, risk level, membership requirement, request parameter, and response format are all included with no filler. Each sentence carries useful 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 simple single-parameter delete operation with no output schema, the description covers the essential invocation details: endpoint, required parameter, risk, membership, and response shape. It could add error cases or authentication specifics, but nothing critical is missing for basic use.

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 schema already describes preId as the preprocessing information ID. The description adds that it is required and labels it as 预处理编号, but this largely repeats the schema rather than providing deeper semantic meaning.

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 ('删除' / DELETE), a clear resource ('预处理'), and the endpoint path. It also adds high-risk and membership context, making it easy to distinguish from sibling operations like open_pre_add, open_pre_edit, open_pre_list, and open_pre_detail.

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 makes clear this tool is for deleting preprocessing information and that membership is required. It does not explicitly name alternatives or when-not-to-use scenarios, but the usage context is unambiguous given the DELETE verb and resource.

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 of behavioral disclosure. It reveals that this is a GET request, requires membership, and documents the unified response shape including code, msg, data, and the data fields. It does not describe non-200 errors or authorization details, but for a simple detail-read tool this is reasonably transparent.

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, starting with the endpoint and membership requirement, then giving the request parameter and response structure. Every sentence contributes useful information without redundancy or fluff.

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 tool with a single parameter and no output schema, the description is complete: it covers the endpoint, required auth, the input, and the full response data shape including contentType mapping. An agent has enough context to call the tool and interpret its result.

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 schema already covers 100% of the parameter with type, required status, and a Chinese description. The tool description essentially repeats the same preId meaning without adding new format, constraints, or usage detail, so it provides no additional semantic value 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 clearly identifies a GET endpoint that retrieves the detail of a preprocessing (预处理) record by preId, and lists the fields contained in the response. This differentiates it from sibling tools such as open_pre_list, open_pre_add, and open_pre_delete because it is specifically about retrieving one record's detail.

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 states that membership is required and that preId is mandatory, providing some usage context. However, it does not explicitly explain when to use this tool instead of open_pre_list or other preprocessing tools, so the usage is implied rather than clearly directed.

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 discloses the HTTP method, membership requirement, required parameters, unified response format, and sample response data. However, it does not cover side effects like overwrite behavior or failure details.

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 endpoint and purpose. It packs necessary request and response details into one dense paragraph, though bullet-style structure could improve scannability.

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?

Since there is no output schema, the description compensates by explaining the unified response format and example data. It covers request requirements and the membership prerequisite, but lacks error-case details and field value examples.

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 parameters. The description repeats requiredness and content type mapping without adding new parameter-specific 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?

Description states a specific verb and resource: '修改预处理' via POST /open/pre/edit. This clearly distinguishes it from sibling CRUD tools like open_pre_add, open_pre_list, open_pre_detail, and open_pre_delete.

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 is given on when to use this tool versus alternatives. It mentions the membership requirement but does not explain when to prefer this over open_pre_add or other pre-processing 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 the full behavioral burden and largely meets it: it specifies POST, membership requirement, unified response envelope, pagination fields, and item fields. It does not address rate limits or explicitly state side-effect-free/read-only behavior, though '获取列表' strongly implies a read-only retrieval.

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, front-loaded with endpoint and purpose, then efficiently packs request and response details. Every clause contributes; minor density from semicolon-separated enumerations keeps it from 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 two-optional-param list tool with no output schema, the description explains the pagination request, unified response, paginated data envelope, and list item fields. It stops short of indicating whether the parameters are sent in the query string or body, and no auth-header details are given beyond '需会员'.

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 restates the defaults and max for current/pageSize. It adds no information beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific HTTP endpoint and a clear action (获取预处理列表, get pre-processing list), with pagination semantics. It is distinguishable from the sibling detail/add/edit tools via the 'list' resource, but it does not explicitly call out the contrast with open_pre_detail.

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 that membership is required and shows how to paginate, so the agent knows the basic precondition and request shape. However, it provides no when-not-to-use guidance or explicit pointer to alternatives such as open_pre_detail for a single item.

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

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

没有提供 annotations，因此描述承担了行为透明度的主要责任。描述披露了“需会员”的权限要求、请求参数、统一响应结构和返回的 data 为“预处理后的消息内容字符串”，让智能体知道调用后会得到处理结果。虽然没有明确说明该操作是否只读、是否执行用户代码，但“测试”和返回结果已经提供了足够的操作语义。

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

描述由三句话组成：第一句点明端点与用途，第二句罗列参数，第三句说明响应结构，信息组织清晰且没有冗余展开。请求参数部分与 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?

工具参数简单且无嵌套对象，没有输出 schema，但描述明确解释了 data 为“预处理后的消息内容字符串”，弥补了返回值的说明缺失。同时包含了“需会员”这一关键调用前提；虽然未给出错误码细节，但统一响应中的 code/msg 已提供了基本错误信息框架。

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 为 100%，因此按校准基线应打 3 分。描述只是重复了 content、contentType、message 的中文含义，几乎没有补充超出 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?

明确说明了该工具用于“测试预处理代码”，并给出了具体的 HTTP 端点“POST /open/pre/test”，属于“特定动词+资源”的清晰表述。虽然没有像“与 open_pre_add 等工具对比”那样显式区分兄弟工具，但“测试”这一动作与预处理的增删改查兄弟工具在语义上已经明显不同。

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?

描述点明了使用前提“需会员”，并说明该工具用于测试预处理代码，暗含了与预处理增删改查工具的区别。但没有明确说明何时应使用本工具而非 open_pre_add、open_pre_edit 等其他兄弟工具，也没有明确的排除条件。

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 present, the description carries the full behavioral burden and delivers: qqCode is immutable after creation ('创建后不可修改'), quota limits (normal users max 5, members max 30), a uniqueness rule (同一QQ群不可重复创建), a precondition (the group must allow bot active messages), and the response envelope (code/msg/data). This is thorough disclosure 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?

A single dense paragraph organized into logical sections: endpoint/purpose, parameter constraints, business limits, and response format. Almost every clause earns its place; the minor redundancy is repeating qqName/qqCode character limits and charset that the schema already documents.

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?

Since no output schema exists, documenting the unified response (code with 200 success, msg, data) is essential and is included. For a 3-param create tool, the description covers parameters, constraints, quotas, and preconditions well; the only gap is specific error codes and what 'data' contains on success.

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%, placing the baseline at 3, but the description adds real value beyond the schema: the immutability constraint on qqCode and the 'group must allow bot active messages' precondition on qqGroupId are behavioral facts absent from the property descriptions. Some duplication exists (character limits and charset rules repeat the schema), preventing a 5.

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 opens with the HTTP endpoint and a precise verb+resource: 'POST /open/qqBot/add - 新增 QQ 机器人群配置', clearly identifying a create operation for a QQ bot group delivery configuration. The scope note ('发到指定QQ群；发给自己无需配置') further distinguishes it from message-sending tools and other qqbot siblings like list/edit/delete.

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 provides a concrete usage condition: use this to deliver messages to a specified QQ group, and no configuration is needed when sending to oneself. It does not explicitly name the sibling management tools (open_qqbot_edit/list/delete) or state when those should be preferred, though the unambiguous 'add' verb plus the self-sending exclusion make the intended use clear.

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 disclosure burden. It states the HTTP method, that there are no request parameters, and details the unified response structure including meaningful enum values for isBind and receiveStatus. This gives an agent a reliable picture of what the operation returns without claiming unintended 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 compact but informative: endpoint, request parameters, response envelope, and all data fields are covered in a few sentences. It front-loads the core purpose before diving into the response schema, and every sentence contributes useful 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?

This is a simple zero-parameter GET tool with no output schema. The description fully specifies the response format and all nested fields, including botInfo details and the meaning of shareUrl. Nothing essential is missing for an agent to call this tool correctly and interpret its result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the description explicitly states '请求参数: 无'. The schema already covers this fully, so the description adds appropriate confirmation without inventing unnecessary details.

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?

Description begins with the HTTP verb and endpoint plus a specific action: 'GET /open/qqBot/botInfo - 查询 QQ 机器人绑定状态'. This clearly identifies what the tool does and distinguishes it from sibling tools like open_qqbot_get_bind_link and open_qqbot_unbind.

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 clearly frames the tool as a status query, so an agent can infer when to use it. It does not explicitly state when not to use it or name alternatives, but for a zero-parameter read-only status check the context is clear enough.

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 of behavioral disclosure. It explicitly flags the operation as high-risk ('高风险') and explains the concrete post-deletion effect: '使用该编码的 option 将失效'. It also describes the unified response envelope. It omits reversibility, permission requirements, and error behavior, but the provided behavioral context is strong.

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 high-risk warning. It efficiently includes the HTTP method, endpoint, required parameter, and response format. The response information is justified because there is no output schema, making this content useful rather than 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 single-parameter delete operation with no output schema, the description covers the essential elements: parameter, risk level, consequence of deletion, and response shape. It lacks explicit usage conditions and error-case detail, but these are relatively minor gaps for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already documents id as '配置编号'. The description repeats this as 'id(配置编号,必填)' without adding new meaning, such as format, range, or examples. Baseline 3 is appropriate when the schema already handles parameter documentation.

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 clearly states the action: '删除 QQ 机器人群配置' (delete QQ bot group configuration), and marks it as high-risk. This is a specific verb+resource pairing that distinguishes it from sibling tools like open_qqbot_add, open_qqbot_edit, open_qqbot_list, and open_qqbot_unbind.

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 explicit guidance is provided about when to use this tool versus alternatives such as open_qqbot_edit or open_qqbot_unbind. The description warns about high risk and the consequence of deletion, but does not state conditions for use, exclusions, or 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?

With no annotations provided, the description carries the behavioral disclosure burden. It discloses an important constraint: qqCode cannot be modified to avoid invalidating in-use options, and it describes the unified response format. However, it does not mention permissions, side effects, or what happens on failure beyond a generic response code.

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: endpoint and purpose first, followed by a key constraint, then the request fields and response format. It is slightly redundant with the schema by listing the parameters again, but the constraint and response information justify the length.

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 edit tool with no output schema, the description covers the purpose, the key immutability constraint, the required request fields, and the response envelope. It does not cover authorization requirements or detailed error behavior, but the included information is sufficient for basic correct 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 coverage is 100%, with each of the three parameters already having a type and description. The description repeats the parameters and required markers but adds no additional semantic detail beyond what the schema provides. The qqCode immutability note is behavioral context, not parameter semantics.

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 clearly identifies the action as modifying QQ bot group configuration, stating the endpoint and the resource. It is distinct from sibling tools like open_qqbot_add and open_qqbot_delete by its edit semantics, though it does not 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?

The description implies this tool is used when modifying an existing QQ bot group configuration, but provides no explicit guidance on when to choose it over related qqbot tools, nor any exclusions or prerequisites. There is no mention of when not to use it.

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?

Since no annotations are provided, the description carries the full behavioral burden. It does well by disclosing an important side effect: 'true 会使旧绑定码失效并重新生成', and a key edge case: '已绑定用户可能为空' for the returned URL. It also provides expiry defaults and response field semantics, going well beyond the tool name and 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 dense but well organized: endpoint and purpose first, then the request parameter, then the unified response and each data field. Every section earns its place, though the field-by-field response listing is more verbose than strictly necessary for a tool with only one optional parameter.

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?

Given the low complexity (one optional parameter, no required parameters) and the absence of an output schema, the description is complete. It covers request semantics, side effects, the unified response envelope, and every data field an agent needs to interpret the result, including the already-bound empty URL case and bindCode usage.

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 schema already documents refresh as an optional boolean defaulting to false, so schema coverage is 100%. The description adds meaningful beyond-schema detail by stating that true invalidates the old binding code and regenerates it, plus clarifying optionality. This genuinely enriches the parameter definition.

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 opens with the exact HTTP method and path, 'GET /open/qqBot/getBindLink', followed by a specific resource statement: '获取 QQ 机器人绑定链接与绑定码'. This clearly identifies a read-only, binding-related operation and distinguishes it from sibling tools like open_qqbot_bot_info or open_qqbot_unbind by naming the unique resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended usage is implied: you call this to obtain a QQ robot binding link and binding code. It also explains how bindCode is used ('已是好友时需私聊发给机器人,认领QQ群也用此码'), but it never names an alternative tool or states when not to use this tool, so the agent must infer routing from the purpose.

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

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

With no annotations provided, the description carries the behavioral disclosure burden and does so well by detailing the unified response format, the data array fields, status semantics, and the edge case where groupName is empty when unauthorized. It does not mention pagination or rate limits, but for a zero-parameter GET list the disclosed response contract is strong.

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 front-loaded with the verb and resource, then organized into request, response, and data-field sections. Every element earns its place, especially the practical note that the item id is reused as qqGroupId when adding group configuration.

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?

Since the tool has no parameters and no output schema, the description fully compensates by documenting the response envelope, data shape, field meanings, and status values. An agent has enough context to call the endpoint and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the baseline is 4. The description explicitly confirms '请求参数: 无', which removes any doubt about invocation requirements beyond the endpoint itself.

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 a clear resource ('机器人已加入的 QQ 群列表'), and the endpoint path makes the operation unambiguous. It does not explicitly compare itself with siblings like open_qqbot_list, so differentiation relies on the resource wording rather than an explicit 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?

The description gives no guidance on when to use this tool versus the many sibling QQ bot/list tools. It notes that there are no request parameters, but does not state when this list is needed or when another tool should be used instead.

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

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

With no annotations available, the description carries the full burden and does a good job: it discloses pagination defaults, the unified response envelope, the paginated data structure, and the meaning of key list fields like qqCode and sendType. It does not discuss authentication requirements or error handling beyond code 200, but it provides solid behavioral context for a read-only list 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?

The description is dense but well organized: endpoint first, then request parameters, response envelope, pagination fields, and list item fields. Every sentence earns its place, and the structure makes it easy for an agent to extract the needed information quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description compensates well by documenting the response structure, pagination shape, and list item semantics. It is slightly incomplete only in that it omits authentication/authorization context and does not mention any potential error cases beyond the success code.

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 input schema already fully documents current and pageSize. The description repeats these defaults without adding new semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('获取 QQ 机器人群配置列表') and identifies the HTTP endpoint, so an agent can tell this is a list/config-read operation. It does not explicitly differentiate itself from the similarly named sibling open_qqbot_group_list, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does and how pagination works, but gives no guidance about when to choose this tool over related siblings such as open_qqbot_group_list or open_qqbot_bot_info. There are no explicit usage conditions, exclusions, or alternatives mentioned.

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 present, so the description carries the full burden. It labels the operation '高风险' and says 'unbind', which signals a destructive effect, but it does not disclose whether authentication is needed, whether the action is reversible, or what consequences unbinding has. This is minimal beyond the endpoint and risk label.

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 concise and well-structured: endpoint and risk are front-loaded, followed by parameter and response information. Every sentence adds useful information 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?

This is a parameterless tool with no output schema, so the description's response envelope and high-risk warning are adequate for making the call. It could be more complete by noting what 'data' contains or when unbinding is appropriate, but given the low complexity, the essentials are 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?

There are zero parameters, and the description explicitly states '请求参数: 无', matching the empty input schema. No further parameter explanation is needed, so the description is appropriately complete for this dimension.

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?

Description clearly states the action: unbinding a QQ bot, with the specific endpoint and HTTP method. The 'QQ' qualifier distinguishes it from siblings like open_clawbot_unbind or open_qqbot_delete, so an agent can identify what this tool does immediately.

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 explicit when-to-use or when-not-to-use guidance is provided. It does not mention alternatives such as open_qqbot_get_bind_link for binding or open_qqbot_delete for deleting a bot, so the agent must infer context 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?

With no annotations, the description carries the full burden. It discloses the HTTP method, required parameters, and the unified response shape (code/msg/data), but does not state side effects such as whether adding a default config for an existing token/channel overwrites or errors, nor any authorization requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense line that front-loads the endpoint and purpose, then lists all params and the response. It is efficient, though slightly cluttered with semicolon-separated details that mirror 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 simple 4-parameter create operation with no output schema, the description covers the action, required inputs, and the unified response. It is missing edge-case behavior like duplicate handling, but is otherwise sufficient for an agent to invoke the tool correctly.

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 clear per-parameter descriptions, so the baseline is 3. The description largely restates the schema's field meanings (e.g., channel enum values, pre can be empty, tokenId 0 for user token) without adding new semantic information.

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 opens with the HTTP method and endpoint plus '新增默认推送配置' (add default push configuration), stating a specific verb and resource. This clearly distinguishes it from sibling CRUD operations like edit, delete, list, and detail for the same resource.

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 'add' verb and the CRUD family of sibling tools, but the description never explicitly says when to use this tool over open_setting_edit_user_default or open_setting_delete_user_default. No exclusions or alternative conditions are provided.

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

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

With no annotations, the description carries the full burden. It does disclose the HTTP method/endpoint, deprecation status, request fields, and unified response shape. However, it does not disclose side effects, whether the deprecated endpoint still functions, permissions needed, or what the business data in the response 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?

The description is compact and information-dense: endpoint, deprecation notice, replacement tool, parameter summary, and response format are all packed into one sentence. It could be slightly more structured, but it earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple deprecated tool with two parameters and no output schema, this description provides the essential routing information and response shape. It is missing clarity on what 'defaultChannel' refers to in the domain and what side effects/caveats remain for callers who ignore the deprecation, so it's 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 baseline is 3. The description merely restates the parameter names and marks defaultWebhook as optional, which adds no meaning beyond the schema's own descriptions of these 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?

The description clearly identifies the resource (default channel) and the action (change/modify), reinforced by the Chinese title '修改默认渠道'. It also immediately signals deprecated status and points to add/editUserDefault, helping distinguish it from the sibling add/edit tools. It doesn't further explain what the default channel semantically controls, but the core purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states '已废弃，请改用 add/editUserDefault' (deprecated, please use add/editUserDefault instead). This is a crisp when-not-to-use directive with a named alternative, which is exactly what an agent needs to route around this tool.

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 must carry the behavioral burden. It does disclose the mutation ('开启或禁用'), the required parameter values, and the unified response format (code/msg/data). However, it does not explain whether changes are reversible (beyond calling the opposite value), whether authentication is required, or whether this setting is scoped to a particular user, bot, or channel.

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: it names the endpoint and purpose first, then the single required parameter, then the response envelope. Every sentence earns its place, and there is no redundant or filler 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 simple one-parameter toggle with no output schema, the description covers the essential information: purpose, endpoint, parameter values, and a unified response format. It is slightly incomplete in that it omits authentication requirements and the precise scope of the 'send message function', but these are minor gaps given the tool's low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully documents isSend as an integer with 0=disabled and 1=enabled, so schema coverage is 100%. The description repeats this mapping but does not add new parameter-level meaning beyond the schema, which warrants the baseline score.

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 clearly states the specific action: '开启或禁用发送消息功能' (enable/disable the send-message function), tied to the endpoint 'GET /open/setting/changeIsSend'. This differentiates it from sibling settings tools like open_setting_change_open_message_type and open_setting_change_receive_limit, which concern different aspects of message settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended usage is implied by the action phrase: call this when you need to turn sending on or off, with isSend=0/1. However, there is no explicit guidance about when not to use it, no mention of alternatives, and no context about prerequisites such as authentication or the scope of the setting (e.g., per-user vs global).

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 the HTTP method (GET on a state-modifying operation), the mutation intent, and the unified response contract (code 200=success, msg, data), which compensates for the missing output schema. However, it does not disclose what the change affects (new messages? existing behavior?), reversibility, or any error semantics beyond the success code.

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 well-ordered: endpoint+purpose first, then parameter specification, then response specification. Each of the three short sentences earns its place with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a low-complexity tool — one fully documented parameter, no nested objects — the description covers purpose, parameter format, and response shape (compensating for the absent output schema). The remaining gaps are minor for this simplicity level: no usage scenario context and no note on side effects or behavior beyond 200=success.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the schema already documents openMessageType as integer with the 0:H5/1:小程序 mapping), so the baseline is 3. The description only repeats the schema's own parameter text and the '必填' flag that the required array already encodes; it adds no new meaning 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+resource: '修改消息打开类型' (modify message opening type) with concrete value semantics (0:H5, 1:小程序), so an agent can tell what target is being changed. It does not explicitly differentiate itself from the sibling change_* tools (e.g., open_setting_change_default_channel, open_setting_change_receive_limit), though the named resource is specific enough that confusion is limited.

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 is provided on when to use this tool versus the many sibling settings tools, including the three other open_setting_change_* mutations. There is no when-not-to-use, no alternative routing, and no scenario context that would help an agent decide between changing message-open type versus default channel or receive limit.

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 must carry the behavioral disclosure burden. It does reveal that this is a GET request that changes state and gives the unified response envelope, but it omits auth requirements, reversibility, and error semantics beyond stating that code 200 means 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?

The description is compact and front-loaded: endpoint and action first, then the parameter, then the response envelope. It contains a slight redundancy with the title, but no unnecessary 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 setter with no output schema, the description provides the endpoint, the required argument with domain values, and the generic response structure. It does not cover authentication or non-success handling, but the unified response description partially compensates for the missing 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%, so the schema already fully documents recevieLimit. The description only restates the same meaning ('0接收全部/1不接收消息') and required flag without adding extra semantic detail.

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 clearly states the specific action (修改/change) and the specific resource (接收消息限制/receive message limit). This distinguishes it from sibling settings tools even without naming 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 guidance is given about when to use this tool versus settings siblings such as open_setting_change_is_send or open_setting_change_open_message_type. It states what it does but not the decision context, prerequisites, or exclusions.

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 burden and explicitly labels the operation as '高风险' (high risk), signaling destructive behavior. It also discloses the response format with an example, but does not mention irreversibility or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: endpoint, risk warning, required parameter, and response format are each covered in a few short clauses with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter delete tool with no output schema, the description covers the request URL, required parameter, high-risk nature, and unified response example. Nothing essential for a correct call 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% for the single parameter id, which already includes type and description. The description simply repeats 'id(默认配置编号,必填)' without adding new semantic detail, 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?

Description states the HTTP method DELETE, the endpoint, and the resource '默认配置' (default configuration), making the tool's purpose unmistakable. The deletion action clearly distinguishes it from sibling CRUD tools like list/detail/add/edit.

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 '删除默认配置' and the sibling tool set, but there is no explicit when-to-use vs. alternative guidance, such as when to prefer edit over delete or any constraints on deleting defaults.

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 of disclosure. It explicitly presents the HTTP method GET, the unified response shape (code, msg, data), and the fields returned in data. This gives an agent a clear model of what happens when invoking the tool, though it does not discuss authentication, error codes beyond 200, or side effects—which are minor for a read-only detail endpoint.

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 dense but well-organized: endpoint, request parameters, response envelope, and data fields are all listed in a compact form. It avoids filler while including useful field-level details like channel enum values and tokenId semantics. It could be slightly more readable with line breaks, but it is appropriately sized for the information conveyed.

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 detail lookup with no output schema, the description fully compensates: it specifies the required id, the unified response structure, and the meaning of each data field, including the channel enum and tokenId behavior. An agent has enough information to call the tool and interpret the result without additional external knowledge.

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 id as the default configuration number. The description repeats this and marks it as required, but adds no deeper semantics such as id format, range, or examples. Baseline 3 is appropriate because the schema already handles parameter documentation.

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 clearly states a GET endpoint and that it retrieves the details of a default configuration by id. The tool name and title '默认配置详情' reinforce the read/detail purpose. It does not explicitly differentiate itself from sibling list/add/edit/delete tools, but 'detail' and the required id make the resource clear.

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 indicates that id is required and that the request URL is GET /open/setting/detailUserDefault, implying this is the single-record detail lookup. However, it does not explicitly state when to prefer this over open_setting_list_user_default or other setting tools, nor does it mention any exclusion or alternative 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 burden. It does disclose the modification nature and the unified response format, but it does not explain side effects, whether existing settings are replaced or merged, authentication or token prerequisites, idempotency, or any destructive consequences. For a mutation tool 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 description is compact and front-loaded with the endpoint and action. It efficiently covers request fields and the unified response in three sentences. Minor redundancy exists because required/optional status is already visible in the schema, but the overall structure 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?

For a 5-parameter CRUD mutation with no annotations and no output schema, the description covers the endpoint, parameter requiredness, and response shape, which is enough to attempt a call. However, it omits behavioral context and usage criteria, and does not clarify what 'modify' means relative to the existing configuration. 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 baseline is 3. The description only restates requiredness and the tokenId=0 convention, both of which already appear in the schema. It adds no genuinely new parameter meaning 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?

The description states a specific action, '修改默认推送配置' (modify default push configuration), paired with the explicit POST endpoint. Among the open_setting_* siblings it clearly reads as the edit/update operation, distinct from add, delete, list, and detail. It is not a tautology and names the resource being modified.

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 open_setting_add_user_default, open_setting_delete_user_default, or open_setting_change_default_channel. It lists required and optional fields but gives no decision context, prerequisites, or exclusions.

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?

There are no annotations, so the description bears full responsibility for behavior. It discloses the HTTP method and generic response envelope but does not clearly state that calling this endpoint performs a state-changing update; in fact, the GET verb and phras? –是否同步'' make it sound like a query, while the title says modify. Auth, side effects, and idempotency are not addressed.

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 endpoint and purpose, followed by the parameter and response format. There is little fluff, though the generic uniform-response sentence is somewhat boilerplate and the ambiguous GET/modify framing costs it a perfect 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 one-parameter endpoint with no output schema, the description provides the URL, required parameter, and response envelope, making the call technically invocable. However, it omits the state-change nature, what data actually contains, and any auth or side-effect context, which is a meaningful gap for an agent deciding whether calling is appropriate.

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%, with the schema already defining forward as required integer 0/1. The description merely restates 'forward(0否/1是,必填)' and adds that it appears in the URL, which adds no substantive 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 identifies the exact endpoint, the setting being modified (WeChat channel message sync to browser extension/desktop apps), and the control parameter. It is distinct from sibling setting tools by the extension-specific resource, though it never states an explicit action verb in the description itself and relies on the title for 'modify' semantics.

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 is given about when to use this tool versus related setting-change siblings such as open_setting_change_is_send, open_setting_change_receive_limit, or open_setting_change_default_chanel. An agent is left to infer applicability solely from the resource-specific 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 exist, so the description must carry behavioral disclosure. It discloses the deprecation status and the unified response envelope (code/msg/data), which is useful. It does not mention response data shape, failure behavior, or side effects, though GET semantics imply a read-only 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 description is a single dense sentence that packs endpoint, deprecation warning, replacement tools, and response format with no filler. The most actionable information—deprecation and alternatives—appears early.

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 deprecated zero-parameter GET whose alternatives are named, the description gives enough to route an agent away and interpret the basic response. It stops short of describing the business data inside 'data', but that gap is mitigated by the explicit recommendation to use another endpoint.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so there is nothing for the description to explain beyond the schema. The schema already covers all parameters vacuously. The response-envelope note adds useful context but parameter meaning is not a concern here.

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 identifies the operation via the endpoint 'GET /open/setting/getUserSettings' and the title '获取默认渠道' (get default channel), so the resource is clear. It also marks the tool as deprecated, which separates it from active siblings. However, the description itself never spells out the behavior in its own words—it relies on the endpoint and title.

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 states the tool is deprecated and tells the agent to use listUserDefault/detailUserDefault instead. This is an unambiguous when-not-to-use instruction with named alternatives.

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 does well: it discloses the pagination request contract, the unified code/msg/data response envelope, the paginated response fields, and the list item channel enum. It does not mention authentication side effects, but this is a read-only list operation and the response details are unusually complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence carries useful information: purpose, pagination settings, unified response, paginated data structure, and list item fields with channel enum. It is well-structured and front-loads the endpoint and resource before details.

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 tool is a simple paginated list call with no output schema and no annotations, and the description compensates by documenting the full response envelope, pagination fields, and list item semantics. It could additionally clarify error-code meanings or sorting behavior, but for this complexity level it is largely 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 both 'current' and 'pageSize'. The description repeats the default and maximum values but adds no new parameter meaning beyond what the schema provides, which warrants the baseline score 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?

The description clearly identifies the operation as listing default push-channel configurations associated with a message token, and the endpoint name 'listUserDefault' reinforces this. The plural '列表' and paginated response shape distinguish it from the sibling detail/add/edit/delete default-configuration 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?

The description makes the tool's purpose obvious but does not explicitly say when to prefer it over siblings such as open_setting_detail_user_default or open_setting_add_user_default. Usage context is implied through the 'list default channels' framing rather than stated with exclusions or alternatives.

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 disclosure burden. It does disclose that this creates a token, that expireTime defaults to '2999-12-31', and that the response follows a unified code/msg/data structure. However, it does not mention authentication requirements, error behavior, or side effects beyond creating a new token.

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 endpoint and action, then covers request parameters and the response format in three short sentences. Every sentence contributes useful information, with no repetition or 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 simple two-parameter creation tool with no output schema and no annotations, the description is largely complete: it specifies required parameters, defaults, and the unified response including the returned token string. Minor gaps remain around authentication context and error cases, but these do not block correct 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 schema already documents both parameters. The description mirrors the schema by stating name is required and expireTime is optional with a default, but it adds no meaning beyond what the structured 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?

The description opens with the HTTP method and endpoint and clearly states the action as '新增消息 token' (add message token). This specific verb+resource combination distinguishes it from sibling token tools such as open_token_list, open_token_edit, and open_token_delete without needing to inspect schemas.

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 explains what the tool does but gives no guidance on when to use it versus the many sibling token/message tools. There are no explicit alternatives, exclusion conditions, or scenarios that would make another tool more appropriate.

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 transparency burden. It discloses the DELETE method, labels the action as high risk, and provides the unified response shape including success data. However, it does not explain irreversibility, side effects on associated messages/tokens, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is compact and well-organized: endpoint, risk level, request parameter, and response format. It is front-loaded with method and high-risk warning, and every sentence contributes useful 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 single-parameter delete endpoint, the description covers the endpoint, required id, and response format. It lacks deeper context about what deletion affects or authorization needs, but the title and schema provide enough for a straightforward 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?

The schema already describes id as '消息 token 编号' and marks it required, so schema coverage is 100%. The description only repeats id with a 'required' label and ties it to the URL, adding no meaningful semantic value beyond the 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?

Description states explicit verb 'delete' and resource 'message token', plus the HTTP method and endpoint. This distinguishes it from siblings like open_message_delete (message deletion) and open_token_edit/list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance is provided. The 'high risk' warning implies caution, but there is no contrast with alternatives such as open_token_edit or open_message_delete, so usage context must be inferred.

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 present, so the description carries the full burden. It discloses that this is a modification operation, lists required/optional parameters, provides a default for expireTime, and explains the response structure. However, it does not mention permissions, side effects, or what happens when the token does not exist — limited for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: endpoint and purpose first, then request params, then response format. Every sentence carries relevant information with no fluff. The formatting is dense but clear.

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 tool with 3 flat parameters, full schema coverage, and no output schema, the description is adequate. It covers the operation, parameter details, and response format, including a data example. Missing annotation-driven safety context is offset by the clarity of the 'edit' verb.

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%, with all three parameters already documented in the schema. The description merely restates the same information (id, name, expireTime with default), adding no new 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?

The description states a specific verb and resource: '修改消息 token' (modify message token), with the HTTP endpoint included. This clearly identifies the action and the target resource, distinguishing it from sibling tools by the edit semantics. However, it does not explicitly contrast itself with the add/delete token 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?

Usage is implied by the verb '修改' (modify) — an agent can infer this is for updating an existing token's name or expiration. But there is no explicit guidance on when to choose this over open_token_add or open_token_delete, nor any stated conditions or exclusions.

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 must carry the behavioral disclosure burden. It does so well by documenting the unified response envelope (code/msg/data), the paginated data shape (pageNum/pageSize/total/pages/list), and the list item fields, plus constraints like default page size and a maximum of 50. It omits authentication and error-code specifics, but those are not essential for a basic read-only list 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 description is compact and front-loaded with the HTTP method, endpoint, and purpose, then systematically covers request parameters and response fields. Every sentence carries useful information with no repetition or 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 simple two-optional-parameter list operation with no output schema, the description fully explains how to invoke it and what the response will contain, including the envelope, pagination metadata, and item attributes. Nothing required to correctly call and interpret this tool 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 essentially restates the same parameter meanings: current defaults to 1 and pageSize defaults to 20 with a maximum of 50. While the response structure adds value, it does not add semantic information about the parameters beyond what the input schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with '分页获取消息 token 列表', a specific verb (分页获取) plus resource (消息 token 列表), and includes the exact HTTP endpoint. It clearly differentiates from sibling tools like open_token_add, open_token_delete, and open_token_edit, which are mutations rather than list operations.

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 clearly implies this tool is for paginated retrieval of message tokens, which is distinguishable from token creation/edit/delete siblings. It gives pagination request details and response structure, so an agent understands the context in which to use it, though it never explicitly states when not to use it or names an alternative.

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

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

With no annotations provided, the description carries the behavioral burden, and it partially fulfills it by exposing the HTTP method POST and the unified response format, including the success code and 'data' as the new group ID. It also surfaces key defaults such as topicType=0 and appId=pushplus公众号. However, it does not mention side effects beyond creation, idempotency, or permission requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph but wastes no words: it enumerates all 10 parameters with required/optional markers and closes with the response format. It could be improved with line breaks for readability, but the length is appropriate for the parameter count.

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 10-parameter creation tool with no output schema, the description covers required and optional fields, defaults, and the response data type, which is enough for an agent to construct a request and interpret the result. It omits error cases and auth prerequisites, but those are not critical for the primary call sequence.

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 every parameter is already documented in the schema. The description essentially restates the same meanings, required/optional flags, and defaults, adding no new syntactic or semantic detail beyond what the schema provides. The baseline of 3 applies because the description adds no real parameter insight.

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 the endpoint and operation in the first phrase, 'POST /open/topic/add - 新增群组', making the verb-resource pair explicit. This clearly identifies a creation action, and it is distinguishable from sibling tools such as open_topic_edit and open_topic_delete, though those alternatives are not 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?

The description gives no explicit guidance about when to use this tool over alternatives; it only states '新增群组' and lists parameters. There is no mention of prerequisites, such as authentication or required prior steps, and no exclusions that would route an agent to open_topic_edit or open_topic_delete. Usage is only implicit from the name and opening phrase.

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 of behavioral disclosure. It warns that the operation is high-risk and states the success message, but it does not mention whether deletion is permanent, what side effects occur (e.g., members removed, data lost), permission requirements, or reversibility. The '高风险' label is generic and lacks specifics.

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, immediately stating the endpoint and risk level, followed by the parameter and unified response format. Every segment adds necessary information with no filler, though it could be slightly better structured to separate metadata from usage instructions.

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 tool with no output schema and no annotations, the description covers the endpoint, required parameter, and response shape. However, it lacks critical side-effect information for a destructive operation, such as irreversibility and downstream impacts, which leaves the description only marginally 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 restates the single parameter 'topicId(群组编号,必填)' without adding new semantics. It does not explain value ranges, additional format requirements, or context beyond what the schema already provides, 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 clearly states the action with a specific verb and resource: '删除群组' (delete group), and includes the endpoint and a high-risk marker. This distinguishes it from siblings like open_topic_exit (exit group) and open_topic_user_delete (delete user from group), because the target is the group itself.

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 provides no explicit guidance on when to use this tool versus alternatives such as open_topic_exit or open_topic_edit. The only usage-related hint is the vague '高风险' warning; there are no exclusions, prerequisites, or conditions for choosing this over other topic operations.

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 of behavioral disclosure. It discloses the response envelope, a detailed data payload, enum meanings, and ownership scope via '我创建的'. It does omit auth requirements and error behavior for invalid or non-owned topicId values, but the GET method and detailed response contract cover the main behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.