PushPlus MCP Server

Official

by pushplus

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.9
Disambiguation2/5
Multiple tools have unclear boundaries: send_push_message, send_text_message, and the format-specific send_*_message tools overlap significantly, and open_user_image_upload_token vs open_file_upload_image are easy to confuse. Deprecated settings tools and similar names like open_topic_detail vs open_topic_join_detail or open_qqbot_list vs open_qqbot_group_list add further ambiguity.
Naming Consistency4/5
Most tools follow an open_<resource>_<action> snake_case convention, with clear CRUD patterns like open_webhook_add/list/detail/delete/edit. Minor deviations exist (e.g., open_setting_get_user_settings, open_topic_is_open, send_push_message vs send_text_message), but the overall pattern is predictable.
Tool Count1/5
With 85 tools, this is far beyond the 50+ threshold and constitutes an extreme count for an MCP server. Even though the underlying API is broad, this many individual endpoints overwhelm an agent's selection surface and are better grouped or reduced.
Completeness4/5
The tool surface covers message sending, token management, topics, friends, webhooks, settings, preprocessing, channels, bot bindings, and image upload with solid CRUD coverage. Minor gaps exist: mail/MP/CP channels only have list/detail without mutation, and two deprecated settings tools remain.
Average 3.8/5 across 85 of 85 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on August 26, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description 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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, but it discloses only that a JSON push message is sent. It does not state whether content must be valid JSON, whether authentication or tokens are required, whether the send is synchronous, or what failure behavior looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with a parenthetical implementation note. No filler; the key operation and format are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an action-style send tool with no annotations and no output schema, the description is too thin. It lacks usage guidance relative to many send_* siblings and does not explain the JSON template behavior well enough for an agent to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds no parameter-level meaning beyond confirming the JSON template usage, which matches the baseline expectation for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: '发送JSON格式的推送消息' (send JSON-format push message), and adds the concrete implementation detail 'template=json'. It is distinguishable from sibling send_text_message, send_html_message, and send_markdown_message by format, though it does not explicitly name a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to prefer this tool over send_push_message, send_text_message, send_html_message, send_markdown_message, or batch_send_message. The only implied signal is the word 'JSON', and no prerequisites or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the endpoint and the pushId requirement, but it does not disclose side effects, authentication needs, rate limits, failure behavior, or what happens after the push is sent. For an external side-effect tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the core action and endpoint, then adds the key conditional requirement. There is no filler or redundancy, so every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters, no annotations, no output schema, and a large set of sibling messaging tools, the description is too sparse. It does not explain the return value, error behavior, or when to choose this over alternatives, leaving the agent under-informed for correct and confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 13 parameters. The description's pushId note essentially repeats what the schema already says for pushId. It adds no meaningful semantic value beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('发送推送消息') and the specific API endpoint ('pushplus /send 接口'), plus a relevant constraint. However, it does not differentiate this tool from sibling send tools like send_text_message, send_html_message, or send_markdown_message, so it stays at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling message-sending tools. The only conditional note about pushId applies to specific templates, but it does not explain selection context, exclusions, or alternatives. The agent is left to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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 unified response envelope and enumerates the business data fields, including the meaning of topicType values, which is useful. However, it does not mention authentication requirements, error conditions, or any caveats about the joined-group view.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description packs endpoint, purpose, required parameter, response envelope, and data field definitions into a few sentences with useful details front-loaded. It is dense but not padded; the field list could be better structured, but it remains readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter GET-style detail tool with no output schema, the description provides a complete response contract and the key business data fields. Missing pieces are minor: no explicit error semantics or authentication notes, but the operation is simple and the response contract is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both schema and description document topicId as the required group number. The description adds only the required marker and URL placement, which is marginal because the schema already carries the core meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-object pair ('获取我加入的群详情') and includes the exact endpoint path, so an agent can recognize this as a read operation for group details that the current user has joined. It does not explicitly contrast with siblings like open_topic_detail, but the '我加入的' qualifier provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives such as open_topic_detail or open_topic_list. The description only restates the operation; it lacks explicit conditions, exclusions, or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose that the operation is high-risk and provides the unified response shape including the expected data value '退订成功'. However, it does not explain irreversibility, permissions, or side effects beyond the warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: endpoint, risk warning, action, required parameter, and response format. Every element earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no annotations and no output schema, the description covers the request and response adequately. However, the high-risk warning is vague and no alternative operations or consequences are mentioned, so some contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents topicId fully. The description repeats 'topicId(群组编号,必填)' but adds no additional semantic details beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action '退出/退订群组' (exit/unsubscribe from group) and identifies the resource as a group. It is specific enough to distinguish from delete-related siblings, though it does not explicitly name the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as open_topic_delete or open_topic_user_delete. It only labels the operation as high-risk and gives the required parameter, leaving usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does disclose the HTTP method, endpoint, required parameters, and the unified response envelope, which is useful. However, it does not state side effects such as overwriting an existing remark, permission requirements, or failure/error behavior beyond a generic code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: purpose/endpoint, request fields, and response format. Each sentence earns its place with no fluff or repetition, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation with full schema coverage and no output schema, the description covers the invocation essentials: endpoint, required fields, constraints, and response envelope. It lacks sibling differentiation and deeper behavioral context, but it is not severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both id and remark already described by types and constraints. The description largely restates the schema (required fields, 20-character limit) and adds no new semantic meaning for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '修改订阅人备注' (modify subscriber remark), and gives the endpoint path. It is clearly distinguishable from the sibling open_friend_edit_remark by the 'subscription person' scope, though it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus open_friend_edit_remark or other topic-user management tools. It only lists request fields, leaving an agent to infer the appropriate context from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 does state '高风险：主动删除图片' (high risk: actively delete image), which flags destructive action, and the HTTP DELETE method reinforces this. However, it does not disclose whether deletion is permanent, irreversible, or whether related data is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the HTTP method, path, and risk warning, followed by the required parameter and response format. The unified response note is somewhat boilerplate but still useful; overall there is little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description covers the endpoint, required id, risk, and response shape. Missing context includes whether deletion is irreversible, how to obtain a valid image id, and error-specific behavior, which would be valuable for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the 'id' parameter as '图片 id' and marks it required. The description merely repeats 'id(图片id,必填)', adding no extra meaning about value range, source, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb and resource: 'DELETE /open/userImage/delete' and '主动删除图片' (actively delete image). It is unambiguous and distinct from sibling tools like open_user_image_list or open_user_image_upload_token, which handle listing and upload tokens, not deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, or when not to use it. The high-risk label implies caution, but there is no explicit mention of sibling tools or conditions under which another tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the action and format; it does not disclose side effects, delivery behavior, recipient handling, authentication requirements, or whether the message is actually sent immediately. This is a significant gap for a sending tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the key information: the action, the format, and the template identifier.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling set of send_* tools, no output schema, and no annotations, the description is too sparse to fully orient an agent. It lacks guidance on expected results, channel behavior, or distinctions from closely related message-sending tools, so an agent cannot confidently decide when this tool is the right choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds the template=html detail, which is useful context, but it does not clarify parameter semantics beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (发送/send), the resource (推送消息/push message), and the distinguishing format (HTML格式), explicitly noting template=html. This differentiates it from sibling tools like send_text_message and send_markdown_message based on the message format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to send an HTML-formatted push message. However, it does not explicitly state when to prefer this over send_text_message, send_markdown_message, send_json_message, or send_push_message, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, but it only says 'send push message' and template=markdown. It does not disclose side effects, permissions, failure/error behavior, or what happens when optional recipient/channel fields are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, immediately states the action and format, and contains no wasted words. It is front-loaded and appropriately sized for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema fully documents the six parameters and required field, which covers invocation details. However, with no output schema and no annotations, the description leaves out when to prefer this over sibling message-sending tools and what behavior/return to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-level detail beyond the schema; template=markdown is an API implementation detail rather than a clarification of the six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('发送' / send), a resource (push message), and a format (Markdown), and adds template=markdown. This distinguishes it from sibling tools such as send_text_message and send_html_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Markdown-format qualifier implies this tool should be chosen when the content is Markdown, but the description gives no explicit when-to-use/when-not-to-use guidance and does not mention alternatives like send_text_message or send_push_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only reveals the message type and a vague 'quick' claim; it does not mention recipient defaults, channel behavior, member-only pre-processing, or side effects of sending.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word adds value, and the template=txt detail is an efficient discriminator.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the one-line description leaves several gaps: result behavior, default recipient resolution, channel defaults, and authorization requirements are not addressed. The complete parameter schema partially compensates, making this minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter semantics baseline is 3. The description adds little beyond template=txt and 'plain text'; it does not meaningfully extend the parameter explanations already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (send), a concrete resource (plain text push message), and an identifying template value (template=txt). This directly distinguishes it from siblings like send_html_message, send_markdown_message, and send_json_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied by the phrase '纯文本' and the template=txt identifier. There is no explicit guidance about when to choose this tool over alternatives such as send_push_message or batch_send_message, nor any when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
没有任何注解，描述承担了主要行为披露责任。它至少明确标出'高风险'并指出会删除 webhook，还包含统一响应格式，是有价值的信息。但未说明删除是否可逆、是否需要权限、删除后对消息接收等下游功能的影响，行为透明性仍不完整。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
描述非常精炼，先给出接口路径和风险提示，再说明请求参数，最后提供统一响应，信息密度高且没有冗余。每部分都有实际用途，整体结构利于快速阅读。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具只有一个必填参数且无输出 schema，描述覆盖了端点、参数和响应格式，已满足调用所需的主要信息。虽然缺少错误情况和删除后果的说明，但针对这种简单删除接口，整体已经足够完整，不足以评 5 分。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入 schema 已完整描述 webhookId 的类型和含义，覆盖率达 100%，描述只是重复了参数名、'webhook编号'和'必填'信息，没有在 schema 之外增加新的语义或格式说明，因此维持中等基线分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
描述明确指出了具体动作（删除）和资源（webhook），并给出了接口路径，能够与同组的 open_webhook_add/list/detail/edit 明显区分。'删除 webhook' 虽与标题重复，但结合高风险说明，目的清晰无误。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
没有说明何时使用该工具、何时避免使用，也没有提供与 open_webhook_edit 或 open_webhook_detail 等替代工具的对比。仅通过动词'删除'隐含使用场景，缺少明确的触发条件和前提要求。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and clearly indicates a read-only query via 'GET' and '查询'. It also discloses the response shape, including the sendLimit enum values and userLimitTime string, which is behaviorally useful. Auth requirements and error cases are not mentioned, but for a zero-parameter read endpoint this is a smaller gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, starting with the HTTP verb and endpoint, then covering request and response details. Each sentence contributes useful information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameter-less query, the description provides enough information to call the endpoint and interpret the result, including the meaning of sendLimit values and the userLimitTime field. It omits auth and failure-code details, but the core call-and-interpret flow is complete without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and the description explicitly confirms '请求参数: 无'. Since there are no parameters to document, the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as '查询发送限制与解封时间' (query send limits and unban time) and gives the specific GET endpoint. However, it does not explicitly differentiate itself from sibling tools such as open_user_send_count or open_user_my_info, so it stops short of the highest clarity rating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when this tool should be used instead of other open_user_* tools. The intended use must be inferred entirely from the operation name and the description text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden. It does disclose the HTTP method (POST), the mutating nature ('修改'), and the unified response envelope (code 200/msg/data with an example '修改成功'), which is genuinely useful beyond the schema. But it does not state whether omited optional fields (httpMethod/headers/body) are overwritten or preserved on update, nor how errors for non-existent ids behave — material 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the operation and endpoint, then req/response in logical order. The only wase is duplicating the full webhookType enum list verbatim from the schema, which is redundant but aids quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with 8 flat parameters and no output schema, the description is largely complete: it covers the request contract, required vs optional grouping, conditional custom-type fields, and the response format with a success example, compensating for the absent output schema. The remaining gap is edge-case behavior (update semantics for untouched fields, error responses), which keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's parameter content — required set and the custom-type-only conditionals — largely restates what the schema already says per-param (e.g., '仅自定义类型需要'). It adds organizational value but no new meaning beyond condensing the requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: '修改 webhook 配置' (modify webhook configuration) with the exact endpoint 'POST /open/webhook/edit'. This clearly distinguishes it from the sibling webhook tools (open_webhook_add/list/detail/delete) by verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: the required 'id' parameter and the verb '修改' signal an existing-record edit, and the sibling set makes the create/read/delete alternatives inferable. However, the description never explicitly says when to choose this over open_webhook_add, nor states conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description 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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It clearly states this is a modify operation and documents the unified response format, including code/msg/data and a sample success value. However, it does not mention side effects, permission requirements, or what happens if the topic does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it opens with the endpoint and action, then lists required and optional parameters, then gives the response contract. Every sentence contributes useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the request shape, required versus optional fields, and the unified response format, which is important because there is no output schema. It could be more complete with usage conditions or failure behavior, but for a straightforward edit operation it covers the essential calling context adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents each parameter with Chinese labels like 群组编号 and 群组名称. The description merely restates the required/optional grouping without adding meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: '修改群组信息' (modify group information), backed by the endpoint POST /open/topic/editTopic. This clearly distinguishes it from sibling tools like open_topic_add, open_topic_delete, and open_topic_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for modifying existing group information, but it never explicitly states when to use it versus alternatives such as open_topic_add or open_topic_delete. No when-not-to-use conditions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and mostly succeeds. It documents the unified response envelope (code/msg/data), pagination response fields, list item fields, and the 30-day auto-cleanup behavior. It does not mention authentication or rate limits, but the read-only query nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized with labeled fields, and it front-loads the endpoint and purpose. However, the pageSize default/max information is repeated with contradictory values, adding noise and reducing structural clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 covers endpoint, pagination parameters, response envelope, data fields, and lifecycle caveat. An agent has enough to invoke it correctly, aside from the unresolved pageSize default ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds a maximum pageSize of 50 and restates defaults, but it also introduces confusion by saying '默认 pageSize 可为10' after earlier stating '默认20,最大50', so the added semantics are inconsistent rather than clarifying.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the endpoint and the specific operation: 'POST /open/userImage/list - 查询已上传图片列表' (query uploaded image list). This distinguishes it from sibling image-related tools such as open_user_image_delete and open_user_image_upload_token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the list/query counterpart to upload/delete siblings, and it explains pagination usage. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose and endpoint are front-loaded, and the response field enumeration is useful because there is no output schema. The description is dense and partly redundant with the schema's parameter documentation, but every piece contributes to understanding the response contract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter detail GET with no output schema, the description provides a full response contract including field meanings and enum values. Minor gaps remain around non-200 error semantics and authentication expectations, but the tool is otherwise callable with the information provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's parameter line ('topicId(群组编号,必填)') largely repeats what the schema already provides in the required field and its description. It adds no format, constraints, or behavioral nuance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the exact HTTP verb and endpoint and states a specific operation: retrieving details of a group the caller created. The '我创建的' scope helps distinguish it from list and join-detail sibling tools, even though no sibling is explicitly named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the title and the phrase '我创建的群组详情', but there is no explicit guidance about when to choose this tool over alternatives like open_topic_list or open_topic_join_detail, nor any mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it delivers: it documents the HTTP method, the points-group limitation, the unified response envelope (code/msg/data with 200 meaning success), the paginated data shape (pageNum/pageSize/total/pages/list), and the operational meaning of the id field ('解除黑名单时使用'). The only gap is that it does not say what actually happens for points groups—error code, empty list, or rejection—which would fully close the loop.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph but follows a logical order: endpoint → purpose → caveat → request params → response envelope → pagination fields → list item fields. Everything earns its place, and the most decision-relevant facts are front-loaded. Minor redundancy exists because the parameter details duplicate the input schema, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter list operation with no output schema, the description is thorough: it covers the full request, the full response envelope, pagination metadata, and every list-item field including the purpose of id. Remaining gaps are minor—no explicit error behavior for points groups, no auth or rate-limit note—but nothing an agent needs to successfully invoke and parse this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's parameter notes (current defaults to 1, pageSize defaults to 20 max 50, topicId is required) essentially restate what the schema already declares. It adds no new semantics beyond framing them as pagination parameters, so it neither compensates for a gap nor adds genuine value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the endpoint and a specific verb-resource pair: '获取群组订阅人黑名单列表' (get group subscriber blacklist list). This is unambiguously distinct from siblings like open_topic_user_subscriber_list (subscriber list), open_topic_user_add_blacklist / remove_blacklist (mutations), and open_friend_blacklist_list (friend scope). An agent can select this tool based on the first line alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a meaningful usage constraint—'积分群组不支持黑名单' (points groups do not support blacklists)—which helps an agent know when the tool will not work. However, it never names sibling alternatives or states when to prefer this over open_friend_blacklist_list or open_topic_user_subscriber_list. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: it discloses pagination defaults, the unified response envelope, and the meaning of list item fields including enums for userSex, havePhone, isFollow, and emailStatus. It does not explicitly mention authentication needs or error behavior beyond '200成功', but the read-only nature is implied by '获取' and no contradictory behavior is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and parameters, then presents structured response details. The length is justified because there is no output schema, so the field enumeration is necessary, but the prose could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter list operation with no annotations and no output schema, the description is near-complete: it covers endpoint, required and optional parameters, pagination behavior, response envelope, and field semantics. The main gaps are omitted auth requirements and explicit error-handling guidance, though these are not essential for a basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with descriptions, defaults, and max values, so schema coverage is 100% and the baseline is 3. The description only restates these facts in prose, adding minimal 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact POST endpoint and clearly identifies the operation as '获取群组订阅人列表' (retrieve group subscriber list), a specific verb+resource. The endpoint path 'subscriberList' and the term '订阅人' naturally distinguish it from sibling tools like blacklist lists or topic-level operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the resource name and provides operational context such as pagination and required topicId, but it does not explicitly state when to use this tool versus alternative sibling tools like open_topic_user_blacklist_list or open_topic_list. No exclusions or explicit alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses that this is a GET/read operation with no side effects, and it details the unified response envelope and data fields. It also clarifies that httpMethod/headers/body are only returned for custom webhook types, which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: endpoint, required parameter, response envelope, then data fields. The enum list for webhookType is dense but informative and earns its place given there is no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter detail endpoint with no output schema and no annotations, the description is largely complete: it covers the request parameter and fully describes the response data. It could add more about error handling or auth, but nothing essential for selecting or invoking the tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for webhookId with type and description, so the baseline is 3. The description restates webhookId as required but adds little new parameter-level meaning beyond the schema. The extra enum detail about webhookType is about the response, not the request parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'GET /open/webhook/detail - 查看 webhook 详情' with a specific verb and resource. The endpoint and field list clearly distinguish it from sibling tools like open_webhook_list, open_webhook_add, and open_webhook_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for viewing a single webhook's details and requires a webhookId. However, it does not explicitly contrast with open_webhook_list or state when the detail view is preferable to other webhook operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It usefully documents the unified response shape (code,msg,data) and the meaning of data fields, but it does not mention authentication requirements, potential errors, or whether the operation has any side effects. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it gives the endpoint, states that there are no parameters, explains the unified response, and maps each data field to its channel. Every sentence carries useful information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter query tool, the description covers the endpoint, request requirements, and the response data semantics clearly. The main gap is the lack of authentication or error-handling context, but given the simplicity of the tool, the description is almost complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is fully covered. The description explicitly states '请求参数: 无', confirming there are no inputs. With no parameters, the baseline is 4, and the description adds nothing unnecessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as a GET query for today's message request counts, broken down by channel (wechat, cp, webhook, mail). This is specific and distinct from any sibling tool, so the agent can tell what this tool does without opening other schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when today's per-channel send counts are needed, but it does not explicitly state when to choose this tool over alternatives or when not to use it. There is no direct sibling with similar purpose, so no alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the HTTP method (GET), the absence of request parameters, and the unified response structure, but it does not state whether the operation has side effects (e.g., token rotation), what error responses look like besides a non-200 code, or any authentication requirements. This leaves some ambiguity for a token endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it opens with the endpoint and purpose, then states the lack of parameters, and finally the response format. Every sentence adds necessary information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, simple string response), the description is nearly complete: it explains the purpose, the request shape, and the response data type. It falls slightly short by omitting details about non-success codes or token validity, but the 'unified response' convention partially covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema description coverage is 100%. The description explicitly confirms '请求参数: 无' (no request parameters), which matches the empty schema. With zero parameters, the baseline is 4 and there is little more to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'GET /open/user/token - 获取当前用户 token' (get current user token). This clearly differentiates it from sibling tools like open_token_list and open_get_access_key by specifying it returns the current user's token.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it retrieves the current user token, but it provides no explicit guidance on when to prefer this over siblings such as open_token_list or open_token_add. There are no alternatives or exclusions mentioned, leaving the routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully carries the behavioral disclosure burden. It discloses the unified response envelope (code/msg/data), data fields (qrCodeImgUrl, forever), and parameter constraints (second default/max, scanCount range/default). Side effects and auth are not mentioned, but as a GET retrieval operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: endpoint, purpose, parameters, and response format all appear in a single efficient block. Every sentence carries distinct, useful information with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there is no output schema, the description fully specifies the response shape and data fields (qrCodeImgUrl, forever) plus all parameter behaviors and defaults. Nothing essential for calling this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the schema's parameter details (default 604800 seconds, max 30 days, scanCount 1-999 or -1) without adding significant new meaning beyond labeling topicId as required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'GET /open/topic/qrCode - 获取群组二维码' (get group QR code). It clearly differentiates from sibling tools like open_friend_get_qr_code and open_clawbot_get_bot_qrcode by scope (topic/group vs friend/bot).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the tool name and description ('获取群组二维码'), but there is no explicit when-to-use guidance or mention of alternatives. Given the large sibling list containing several QR-code tools, explicit routing would have improved clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly warns '高风险' and states the destructive effect (deleting a group subscription), and it documents the unified response shape. Permission requirements and side effects beyond deletion are not detailed, but the destructive nature is unmistakable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: endpoint and risk warning first, then the single required parameter, then the response format. It includes a little redundancy with the schema, but it remains tight and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description covers the endpoint, parameter source, success code (200), and data example ('删除成功'). It omits explicit alternative routing and side-effect caveats, but these are not critical for invoking this simple deletion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description mostly restates what the schema already says: topicRelationId is required and comes from the subscriber list id field. No additional parameter semantics such as constraints or format are added, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('删除群组订阅用户') with a concrete resource and endpoint (deleteTopicUser), and flags it as high-risk. This clearly distinguishes it from sibling operations like exiting a group or blacklisting a user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use context: it deletes a group subscriber, and the required topicRelationId comes from the subscriber list ('来自订阅人列表的 id'), which tells the agent where to obtain input. It does not explicitly name alternatives or state when not to use it, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does a solid job: it gives the exact verb/resource, required versus conditional parameters, the unified response shape, and clarifies that data contains the new webhook ID. It does not disclose authentication needs or duplicate/error behavior, but the main side effect and response contract are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but compact, front-loading the endpoint and creation intent, then covering request parameters and response in a logical order. It could be improved with clearer bullet/list formatting, but every piece of information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 7 parameters, no annotations, and no output schema, the description is largely complete: endpoint, required fields, type enum, conditional custom-type fields, and unified response/data format are all present. It lacks explicit guidance on authentication or when to use edit instead, but these are minor for invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 meaningful value by marking the four required fields explicitly, enumerating the webhookType values, and adding the conditional detail that httpMethod/headers/body are needed only for type 12 (custom), which is more specific than the schema's '仅自定义类型需要'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the HTTP endpoint and an explicit verb+resource: 'POST /open/webhook/add - 新增 webhook 配置' (add webhook configuration). This clearly states the operation and distinguishes it from sibling tools like open_webhook_edit, open_webhook_delete, and open_webhook_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by '新增 webhook 配置' and the list of required fields, so an agent can infer this is for creating a new webhook. However, the description does not explicitly say when to choose this over open_webhook_edit/open_webhook_delete, nor does it provide exclusions or prerequisites such as token/auth requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does well: it reveals pagination defaults, max page size, the unified response envelope, and the exact list item fields including webhookType enum values. It does not discuss authentication or error handling, but the disclosed behavior is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose and endpoint, then efficiently covers pagination, response format, and list item fields. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description fully compensates by documenting request parameters, response envelope, pagination structure, and list item schema including webhookType mappings. An agent has enough information to call the tool and interpret its result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents current and pageSize. The description repeats the defaults and max value without adding new semantic meaning beyond the schema input, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: '获取 webhook 列表' (retrieve webhook list), and includes the exact endpoint. This clearly separates it from sibling webhook operations like detail, add, edit, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for paged webhook listing, but it does not explicitly say when to prefer it over open_webhook_detail or other webhook siblings. Usage is inferable from the purpose but not directly contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to carry the behavior burden, the description discloses the POST endpoint, the required mutation (1上架/0下架), and the unified response contract (code/msg/data with a sample data value). It does not discuss permissions or broader side effects, but the core behavioral effect is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: operation first, then the two required parameters, then the unified response. Every sentence provides necessary information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter state-toggle operation with no output schema, the description is largely complete: it specifies request, required fields, state semantics, and response shape. It could go further with error behavior or permissions, but those are not critical for invoking this simple endpoint correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage, and the description merely repeats the same meanings ('群组编号', '1上架/0下架') plus '必填', which duplicates the required constraint already in the schema. No additional parameter semantics are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation, '积分群组上下架' (put a points group on/off shelf), names the exact endpoint, and clarifies the semantic of isOpen (1上架/0下架). This is unique among the open_topic_* siblings, which handle listing, adding, editing, deleting, or subscriber management, so the agent can reliably distinguish this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The operation is unambiguously scoped: use this tool to toggle the on/off-shelf state of a points group via topicId and isOpen. It does not explicitly name alternative tools or exclusions, but no sibling performs this toggle, so the usage 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it delivers: it specifies the HTTP method/endpoint, request pagination bounds, the unified response envelope (code/msg/data), the pagination shape (pageNum/pageSize/total/pages/list), and the meaning of all list-item fields including enum-like values for topicType, isApproved, firstIsApproved, and isOpen. This goes well beyond the request-only schema and gives the agent a complete mental model of the call's behavior, including error semantics via code 200成功.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense block with no wasted sentences — endpoint, pagination, filter, response envelope, and item fields each earn their place. Minor redundancy is that pagination and topicType defaults duplicate the schema, and the wall-of-text format reduces scanability, but the field dictionary is unusually information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so full return-value documentation is essential — and the description provides it end-to-end, from envelope to pagination wrapper to every list-item field with value meanings. Combined with parameter defaults and filter semantics, an agent has everything needed to call and interpret the tool correctly; auth or rate-limit caveats are the only niche omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters at 100% coverage, so the baseline is 3. The description's contribution is modest — restating the same defaults and max pageSize, plus the semantic nuance that topicType is 必填 in meaning though it defaults to 0. It adds no format or edge-case detail that is absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'POST /open/topic/list - 获取群组列表', an explicit verb (get) plus resource (群组列表) plus the HTTP endpoint, making the operation unambiguous. Against siblings like open_topic_detail, open_topic_add, open_topic_edit, open_topic_delete, 'list' is clearly the collection operation, so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to paginate and filter (current/pageSize/topicType default and max values, 0我创建的/1我加入的), which tells an agent what parameters to set. However, it never states when to choose this tool over alternatives such as open_topic_detail or open_qqbot_group_list, nor gives exclusions. Usage is therefore implied by the filter semantics rather than explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the HTTP method (GET), the unified response envelope (code/msg/data), and the complete data field list including enum meanings for userSex and emailStatus. It doesn't mention error cases or authentication requirements, a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the endpoint and purpose. Every listed field adds useful information, though the long inline field list could be visually structured more cleanly. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only endpoint with no output schema and no annotations, this description is complete: it specifies the request (none), the response envelope, and every data field with type and enum semantics. Only non-200 error behavior is unspecified, which is a minor omission for a simple profile getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description explicitly states '请求参数: 无', matching the schema and leaving no ambiguity. Per the zero-parameter baseline, this is fully adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'GET /open/user/myInfo - 获取个人资料', giving a specific HTTP method, resource path, and clear verb-object purpose. It then enumerates the profile fields returned, which clearly distinguishes it from sibling user/token/message tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the name and description: retrieve the current user's personal profile. However, there is no explicit guidance about when to choose this tool over alternatives like open_user_token or open_user_limit_time, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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 explicitly warns '高风险' (high risk), states that removal does not automatically restore group subscription, and notes that the person may rejoin the group. This goes beyond the raw action and gives the agent meaningful expectations about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it begins with the HTTP method and endpoint, then the risk warning, the behavioral consequence, the parameter, and the unified response format. Every sentence contributes useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 is complete: it explains the purpose, the input provenance, the high-risk consequence, and the response envelope. An agent has enough context to invoke the tool correctly and anticipate the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description repeats that id is required and clarifies it comes from the blacklist list id, but this largely duplicates the schema's own description ('黑名单列表的 id 字段'). No additional format, range, or semantic nuance is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (解除, remove) and resource (订阅人黑名单, subscriber blacklist), and the endpoint POST /open/topicUser/removeBlacklist makes the operation concrete. This clearly distinguishes it from the sibling open_topic_user_add_blacklist and open_friend_remove_blacklist even without needing the input schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational context: the tool removes a subscriber from the blacklist, requires an id from the blacklist list, and warns that the action does not restore the group subscription. It does not explicitly name alternatives or exclusion conditions, but the context is sufficient for an agent to decide when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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 so well. It discloses the high-risk nature, the post-condition of removing the user from the group, the inability to rejoin, and unsupported group types. This exceeds what structured fields would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and structured: endpoint, risk level, effect, parameter source, and response format. Every sentence earns its place, and the critical behavioral details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 is fully sufficient. It covers the parameter source, success criteria, side effects, and limitations, enabling correct invocation without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description essentially restates the same parameter meaning already found in the schema: topicRelationId is the user ID from the subscriber list. No additional format, constraints, or examples are added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: adding a subscriber to the blacklist via a specific POST endpoint. It distinguishes itself from sibling tools by specifying the target resource (订阅人/topic subscriber) and the topicRelationId source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context and important usage restrictions: points groups do not support blacklists and the user cannot blacklist themselves. It does not explicitly name alternative tools like remove_blacklist, but the action is unambiguous enough that an agent can select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses 30-day validity, the unified code/msg/data response envelope, all data fields, and that no access-key is needed for the subsequent form upload. It does not mention auth requirements or rate limits, but these are not central for a credential-issuing GET.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the core purpose and endpoint, then compactly lists parameters, response envelope, data fields, and follow-up usage. Every sentence earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully documents the response shape (code/msg/data and each data field) and tells the caller the next action. It is complete enough for a no-parameter credential operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no request parameters, so the empty schema already covers semantics; the description adds explicit confirmation ('请求参数: 无') and clarifies that the later upload needs only token+file, no access-key. Baseline 4 for a 0-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific endpoint and resource ('GET /open/userImage/uploadToken - 获取七牛云表单上传凭证') plus scope ('图片服务') and validity ('30天有效'). It is immediately distinguishable from sibling image tools like open_user_image_list/delete and open_file_upload_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear workflow context: no request parameters, and after obtaining the token the caller submits token+file to uploadUrl using Qiniu form rules. It does not explicitly name alternatives or when-not conditions, so it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

pushplus-MCP-Server-TypeScript MCP server

Copy to your README.md:

[![pushplus-MCP-Server-TypeScript MCP server](https://glama.ai/mcp/servers/pushplus/pushplus-MCP-Server-TypeScript/badges/card.svg)](https://glama.ai/mcp/servers/pushplus/pushplus-MCP-Server-TypeScript)

Score Badge

Copy to your README.md:

[![pushplus-MCP-Server-TypeScript MCP server](https://glama.ai/mcp/servers/pushplus/pushplus-MCP-Server-TypeScript/badges/score.svg)](https://glama.ai/mcp/servers/pushplus/pushplus-MCP-Server-TypeScript)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/pushplus/pushplus-MCP-Server-TypeScript'

If you have feedback or need assistance with the MCP directory API, please join our Discord server